We have an ongoing conversation about the best way to manage our code-base and repository in Git and have found the best solution is by using this branching structure:
https://nvie.com/posts/a-successful-git-branching-model/
- ‘develop’ should always be in a compiling/working state, containing the most current completed features
- ‘master’ should contain only releases (e.g. build from here for app store submission)
- ‘release/some_release_name’ should contain releases in-progress (bugfixes only)
- ‘feature/some_feature_name’ is where most work should take place
- ‘hotfix/some_hotfix_name is where we fix critical bugs on code that has been released (in master)
Feature branches are the only branches that can be in an indeterminate state, though I avoid intentionally checking in code that doesn’t build. All other branches should build and run cleanly.
You can help enforce this practice through good discipline and by using Git-Flow. If you’re on a Mac you can use MacPorts or Homebrew. There’s also a pretty decent screencast showing you how.
Some comments from our developers and friends:
Yes. Basically, we should be checking in only code that works to ‘develop’. If you need to save your latest progress, you should just create your local git branches as many as you like and when you are ready, merge with your local ‘develop’ branch and then push the changes to the remote ‘develop’ repo.
We’ve been using git-flow at ShortForm for about a year now an we love it. The gitflow extensions are also very nice, save a lot of manual branching and tagging as per the process :
https://github.com/nvie/gitflow
There have also been a few moments where the process has broken down for us, but with git it’s so easy to do things manually as well that it has not held us back in any way.
