On the path with git-flow

Read a lot about Vincent Driessen’s Git braching model, but couldn’t quite wrap my head around it. This video, which introduced git-flow — a collection of Git extensions to provide that branching model — to me, finally made it all clear.

Above that, the people who created Sourcetree, have implemented it in their app and have provided a nice write-up of all the branches used in the model.

  • Development branch (usually called develop)
    This is your main development branch where all the changes destined for the next release are placed, either by directly committing small changes or by merging other branches (e.g. feature branches) into this branch.
  • Production branch (usually called master)
    This branch represents the latest released / deployed codebase. Only updated by merging other branches into it.
  • Feature branches (usually prefixed with feature/)
    When you start work on anything non-trivial, you create a feature branch. When finished, you’ll merge this branch back into the development branch to queue it for the next release.
  • Release branches (usually prefixed with release/)
    When you’re about to package a new release, you create a release branch from the development branch. You can commit to it during your preparation for a release, and when it’s ready to be deployed, you merge it into both the development branch and the master branch (to indicate that the release has been deployed).
  • Hotfix branches (usually prefixed with hotfix/)
    If you need to patch the latest release without picking up new features from the development branch, you can create a hotfix branch from the latest deployed code in master. Once you’ve made your changes, the hotfix branch is then merged back into both the master branch (to update the released version) and the development branch (to make sure the fixes go into the next release too)

Would love to also see this appear in Tower

git-flow

Published by Bramus!

Bramus is a frontend web developer from Belgium, working as a Chrome Developer Relations Engineer at Google. From the moment he discovered view-source at the age of 14 (way back in 1997), he fell in love with the web and has been tinkering with it ever since (more …)

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.