Successful GitHub Development | Hacker News Reader

Successful GitHub Development

rdegges.com

63 pointsb14ck9 comments

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.

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

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/...

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.

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

Why is using the builtin wiki a bad idea?

I believe that the point is more against collaborative documentation than against the builtin wiki.

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).

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

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.

Reply on news.ycombinator.com