We have a web app that we update and release almost daily. We use git as our VCS, and our current branching strategy is very simple and broken: we have a master branch and we check changes that we ‘feel good about’ into it. This works, but only until we check in a breaking change.
Does anyone have a favorite git branch strategy for small teams which meets the following requirements:
- Works well for teams of 2 to 3 developers
- Lightweight, and not too much process
- Allows devs to isolate work on bug fixes and larger features with ease
- Allows us to keep a stable branch (for those ‘oh crap’ moments when we have to get our production servers working)
Ideally, I’d love to see your step-by-step process for a dev working on a new bug
You might benefit from the workflow Scott Chacon describes in Pro Git. In this workflow, you have two branches that always exist, master and develop.
master represents the most stable version of your project and you only ever deploy to production from this branch.
develop contains changes that are in progress and may not necessarily be ready for production.
From the develop branch, you create topic branches to work on individual features and fixes. Once your feature/fix is ready to go, you merge it into develop, at which point you can test how it interacts with other topic branches that your coworkers have merged in. Once develop is in a stable state, merge it into master. It should always be safe to deploy to production from master.
Scott describes these long-running branches as “silos” of code, where code in a less stable branch will eventually “graduate” to one considered more stable after testing and general approval by your team.
Step by step, your workflow under this model might look like this:
For more details on this workflow, check out the Branching Workflows chapter in Pro Git.