Git branch strategy for small dev team

Question

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:

1. Works well for teams of 2 to 3 developers
2. Lightweight, and not too much process
3. Allows devs to isolate work on bug fixes and larger features with ease
4. 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

Answer 1

1. Run unit tests before checking in code.
2. Make a release branch each time you release (but develop on the main line).

Answer 2

In a VCS, having just a "master" branch shows quickly its limits because you cannot pursue all the development effort at the same time on one branch.
That means you need to know when to branch.

But in a DVCS (as in "Decentralized" VCS), you also have a publication issue, with branches you keep local to your repositories, and branches you are pushing to or pulling from.

In this context, start by identifying your concurrent development effort, and decide on a publication (push/pull) process. For instance (and this is not the only way):

• prod is a read-only public branch with the code in production. Everyone could pull from it in order to:
  • rebase its current development on top of it (for local testing, or for integrating on the local dev repo a hotfix done in the prod repo on the prod branch)
  • branch to do new features (from a known stable code)
  • branch to start the next release branch (the one which is to be in production)
    no one should push directly to prod (hence the read-only)
• release is a read-write consolidation branch, where the relevant commits are cherry-picked to be part of the next release.
  Everyone can push to release to update the next release.
  Everyone can pull from said release in order to update his/her local consolidation process.
• featureX is a private read-write branch (in that it does not need to be push to the central prod repo), and can be pushed/pulled between dev repos. It represents middle to long term effort, different from the daily dev
• master represents the current dev, and is pushed/pulled between the dev repos.

Other release management processes exist, as this SO question attests.

Answer 3

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:

1. You need to fix a bug.
2. Create a branch called myfix that is based on the develop branch.
3. Work on the bug in this topic branch until it is fixed.
4. Merge myfix into develop. Run tests.
5. You discover your fix conflicts with another topic branch hisfix that your coworker merged into develop while you were working on your fix.
6. Make more changes in the myfix branch to deal with these conflicts.
7. Merge myfix into develop and run tests again.
8. Everything works fine. Merge develop into master.
9. Deploy to production from master any time, because you know it's stable.

For more details on this workflow, check out the Branching Workflows chapter in Pro Git.

Answer 4

Read through ReinH's Git Workflow for Agile teams here: http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

This works very well for small teams. The goal here is to make sure everything that might be potentially unstable goes in to a branch of some kind. Only merge back to master when you are ready for everyone working outside of the feature branch to use it.

Note: this strategy is hardly git specific, but git makes implementing this strategy pretty easy.