

Successful GitHub Development - b14ck
http://rdegges.com/successful-github-development

======
davvid
Another interesting thing I've found is that packagers really prefer tarballs.
They can checksum them. They don't need to download your full history, etc.

The tarballs automatically produced by github have names that are annoying and
makes things harder for packagers, so I find myself creating "make dist"
targets and uploading the result to github. Is there an API for file uploads?
(that would be sweet!)

I do wish there was a way to provide a format string that would tell github
the basename to use for tarballs.

If you are jquery and your project is jquery your tarballs look like jquery-
jquery-v1.2.3-g654321.tar.gz and the directory basename is the same.

If they added the ability to configure it per-repo and used "{{ user }}-{{
repo }}-{{ tag }}-{{ sha1 }}" as the default then they could keep backwards
compat and let folks configure it to their liking. It's one of my very few
github peeves.

------
emillon
git-flow is not needed, especially for small projects. For most repositories,
developing on and sending pull requests to master is acceptable.

~~~
davvid
Agreed. The branching model used by the git project itself is quite effective.
Introducing an additional tool isn't always needed.

[http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/...](http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/howto/maintain-
git.txt;h=d527b307707c676e82a08f18cb9fdd7d3abcb228;hb=HEAD)

If there existed a git-next tool to document that workflow then it might be
more widely known, I guess. There probably is no tool because it's all just
normal git stuff.

The document mentions:

    
    
      - The tip of 'master' is meant to be more stable than any
        tagged releases, and the users are encouraged to follow it.

------
Palomides
rather more extensive and general, but somewhat related book (Producing Open
Source Software): <http://producingoss.com/a>

------
andrewflnr
Why is using the builtin wiki a bad idea?

~~~
b14ck
To me, wikis just seem 'lazy'. Projects that use wikis as a primary form of
documentation make users feel like the project is un-cared for, and not worth
documenting.

I have absolutely no stats to back this up--but having officially written
documentation gives projects a really good 'feel', and makes it a lot simpler
for users to get started (IMO).

~~~
andrewflnr
That seems strange to me. It's possible to do a really nice job with it, as
evidenced by (at least) the Blueprints project:
<https://github.com/tinkerpop/blueprints/wiki>

------
cnbeuiwx
So like...

1\. Write Official Documentation (booooring)

2\. Use Git Flow (version management, boooooring)

3\. Publish Test Runs (oh, testing.. thats fun right? no...ok...)

4\. Use GitHub Issues (....)

5\. Have fun. (yes!!)

Ill take one number 5 please. And 1-4 is why Im not a professional programmer.

