Successful GitHub Development

Successful GitHub Development(rdegges.com)

63 points by b14ck 14 years ago | 9 comments

davvid 14 years ago |

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 14 years ago |

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

davvid 14 years ago | |

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.

Palomides 14 years ago |

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

andrewflnr 14 years ago |

Why is using the builtin wiki a bad idea?

b14ck 14 years ago | |

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 14 years ago | | |

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

emillon 14 years ago | |

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

cnbeuiwx 14 years ago |

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.