Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Successful GitHub Development

rdegges.com

Post reply on HN
Print view View original

1–10 of 10 posts

Re: Successful GitHub Development

#2

Post by 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.

Re: Successful GitHub Development

#7

Post by davvid »

emillon wrote: post #6

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.

Re: Successful GitHub Development

#8

Post by 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.

Re: Successful GitHub Development

#9

Post by b14ck »

andrewflnr wrote: post #3

Why is using the builtin wiki a bad idea?

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

Re: Successful GitHub Development

#10

Post by andrewflnr »

b14ck wrote: post #9
andrewflnr wrote: post #3

Why is using the builtin wiki a bad idea?

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
Post reply on HN