Choosing a Git branching strategy

If you are using Git as your version control system, you may want to have a strategy to manage your branches.

Two popular strategies are:

• Git Flow
• GitHub Flow

At work we use these tools:

• .NET
• Bitbucket Server as on premise Git server
• SourceTree as Git client (most developers)
• TeamCity for continuous integration
• Octopus Deploy for automated deployment

Git Flow

Detailed description of the flow:

• http://nvie.com/posts/a-successful-git-branching-model/
• https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

In this flow you end up with the branches:

• master
• develop
• feature/*, for example feature/foo
• release/*, for example release/v1.0
• hotfix/*, for example hotfix/bar

SourceTree can help you to get started with Git Flow:

Who should use Git Flow?

For teams that have to do formal releases on a longer term interval (a few weeks to a few months between releases), and be able to do hot-fixes and maintenance branches and other things that arise from shipping so infrequently, git-flow makes sense and I would highly advocate it’s use.

– Scott Chacon

Criticism:

• http://endoflineblog.com/gitflow-considered-harmful

GitHub Flow

Detailed description of the flow:

• http://scottchacon.com/2011/08/31/github-flow.html
• https://guides.github.com/introduction/flow/

In this flow you end up with the branches:

• master that always should be deployable
• feature branches with descriptive names, for example refactor-foo-to-bar

GitHub Desktop can help you to get started with GitHub Flow:

Who should use GitHub Flow?

For teams that have set up a culture of shipping, who push to production every day, who are constantly testing and deploying, I would advocate picking something simpler like GitHub Flow.

– Scott Chacon

Criticism:

• http://doc.gitlab.com/ee/workflow/gitlab_flow.html#github-flow-as-a-simpler-alternative

In any case

Whatever branching strategy you choose I think you should:

• Use Pull Requests
  • GitHub, Bitbucket, GitLab supports it
• Build all branches on your Continuous Integration server
  • TeamCity has support for that
• Have multiple test environments and make it easy for testers to deploy the feature branches there
  • Octopus Deploy is good at that
• Know exactly what you’ve deployed with Git, TeamCity and Octopus
  • Give releases a name that includes the Git branch name and the CI build number
  • Consider, in addition to the article above, to have the release notes file with the Git commit (SHA-1 hash) exposed
• Consider to use feature toggles over long-lived feature branches