Git Branching Model - iToto/developmentCycle GitHub Wiki
Our Git branching model is based on the model described here
This is a simple visualization of how we should try to work. (the arrows point to a commit’s ancestor(s)).
The important features of this branching model are
- separate bugs from features
- track release points
- group commits belonging to different features
- allow developers to freely move back and forth between fixing old code and creating new code
Let’s look at each of these points one by one.
Sometimes we make mistakes. For software developers this means bugs. Hopefully we find all of these during testing, but this isn’t always the case. When bugs are found by customers in production they expect those bugs to be fixed, quickly. If we keep all commits in a single branch then when we provide an install based on this branch, we are including not only the fixes to the bugs they found but also any other features or bug fixes that are in that branch!
We should maintain two primary branches. master and develop.
New features/functionality should always be merged into develop (once it’s ready to test by QA). None of these commits should end up in master until we are at a point where we’re ready to release.
Bug fixes should be merged into master and develop. This allows everyone working on new features to be working with the latest fixes and they can ensure that the features they develop don’t break any fixes or fixes don’t interrupt their work.
We use the master branch for all releases of Gocad Mining Suite. When we release, we create a tag with that release’s name. Then we can easily go back and create new branches from that point.
When we have a new feature or bug fix we should create a new branch starting from the last release.
When we’re done and ready to merge into the feature or bug fix branch, we should do so with the fast-forwarding turned off. Fast forwarding will have git attempt to place the commits from the merged branch placed into the regular history of our destination. This has the advantage of giving a ‘clean’ history, however, it also erases any knowledge of a branch! If someone had a very large feature/bug fix with many commits, this can make it a bit difficult to separate changes made for that specific feature/bug from other commits made in the same time period.
Committing frequently and working in numerous branches allows you to stop working on one task (say a new feature) and begin working on a bug fix for the last release in moments. Once you’ve finished your bug fix you can merge it into master, develop and your feature branch and continue where you left off.
Git Flow is a set of git extensions that makes this kind of git branch model really easy to use. It’s installed pretty easily and integrates with software like sourcetree.