The folks at GitHub have taken the pain out of centralized Git hosting. Even better, they’ve built in tools that make distributed version control easy to use for group projects. But how to set up your repositories and branches to avoid merge pain? Here are two good options.
Making Merge Manageable
Setting up your Git repositories for open source projects at github has great tips for getting started – and for structuring your branches for group work. There are a couple of take-aways here:
- Encourage contributors to track established branch names, like “master” and “edge”. At the office we use “master”, “staging” and “dev”.
- This makes it much easier for developers to pull in changes from the official repository in a simple, fast-forward way
- Develop on a separate branch (or branches). You might want to name that branch with your github id, to help folks keep it straight.
Michael also provides a solid how-to, so if “pull request” sounds weird to you, start here.
Another Way: Branch away and let github-gem straighten it out
The folks at GitHub have a Ruby command-line tool to manage this without the fancy branch naming conventions. You fork, and the tool helps keep everybody’s master branches separate. It also speeds merging from these masters.
See defunkt’s Github-gem for the code and a README that explains the tool’s awesomeness.
Github-gem assumes that master is where you’ll want to pull from. This matches what most folks do – unless they’ve benefited from the foresight of the Inoshi folks.
Whichever strategy you choose, Github’s network diagram is your visual to-do list. It shows who committed stuff that’s different than what’s on your branch. Say hello to the Network graph visualizer has the details.