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:

Git Flow

Detailed description of the flow:

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:

SourceTree - Initialise repository for Git Flow SourceTree - Choose next flow action

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:

GitHub Flow

Detailed description of the 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:

GitHub Desktop - 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:

In any case

Whatever branching strategy you choose I think you should:

  • Use Pull Requests
  • Build all branches on your Continuous Integration server
  • Have multiple test environments and make it easy for testers to deploy the feature branches there
  • 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 Octopus Deploy Dashboard
    • Consider, in addition to the article above, to have the release notes file with the Git commit (SHA-1 hash) exposed ReleaseNotes.txt
  • Consider to use feature toggles over long-lived feature branches