SourceTree

Smart branching with SourceTree and Git-flow

By on August 1, 2012

Note: for brevity this article refers to Git and git-flow, but SourceTree supports exactly the same concepts in Mercurial via Hg Flow too.

In early 2010, Vincent Driessen wrote an article called “A successful Git branching model” which recommended an approach called git-flow to use git branches in your development cycle. The idea was to standardise branching and merging when developing features, handling releases and managing hot fixes, in order to be consistent and gain the advantages of git’s ‘branchy’ development model. Using many separate branches in Git gives you lots of flexibility, but it can get complex. Adopting a standardised approach has many advantages:

SourceTree 1.5 now integrates with git-flow and presents it to you in a friendly and intuitive way.

Summary of the concept

The general idea of git-flow is to use the following branch structure in your repository:

SourceTree helps you utilise these branches via git-flow actions which we will describe below.

Getting started with git-flow

There’s a handy new addition to the toolbar in SourceTree 1.5 (keyboard shortcut Cmd-Alt-F):

Based on the current state of the repository, the Git-flow button will bring up a dialog with the most likely action you’d want to perform next. So if you haven’t set up git-flow on this repo yet, it’ll help you do that by default. If you’re on the development branch, it will default to starting a new feature. If you’re already on a feature branch, it will offer to finish your current feature and merge it back into the development branch, and so on. You can always get to all the other git-flow actions via this button as well, but most of the time the default option will be the action you’ll want SourceTree to perform.

If you haven’t used git-flow already on this repository, the first thing SourceTree will do is initialise your repository to use it. You’ll probably just want to use the defaults in the initialisation window so that’s not covered here. For more details please see the Help section included in SourceTree. Next up, we’ll concentrate on the actions we can perform with Git-flow and SourceTree.

Starting a feature

You can commit trivial changes directly to the development branch (‘develop’) if you like, but any time you start on something non-trivial you should explicitly start a new feature. This ‘Start Feature’ action will be the default action when you click the Git-flow button if you are currently on the dev branch.

The first thing to note is the ‘Preview’ window, which is present on all of the action dialogs and shows you what will actually happen when you confirm the dialog. In this case, a new feature branch called ‘feature/my-new-feature’ will be created (I used the default prefix when I initialised this repository). You commit your feature implementations to this branch. If you want, you can push the feature branch to your remote while you work on it (your team can decide on whether that’s normal practice or not).

If at any time you want to switch branches, either to another feature branch or to somewhere else, just use the normal mechanisms in SourceTree to do that, such as double-clicking a log entry or a branch in the sidebar. Git-flow determines your context simply from the branch you currently have checked out, so it’s fine to jump around if you like.

Finishing a feature

Eventually when you’re done implementing a feature, use the ‘Finish Feature’ action (again, this will be the default action from the toolbar button if you’re on a feature branch):

Again, the Preview shows you what will happen — the feature branch will merge into the main development branch, essentially queueing it for inclusion in the next release. Feature branches are deleted by default but you can opt to retain them if you like.

Starting a release

You start a release branch when you want to start preparing a new release, which probably coincides with a feature freeze. Accessing the Start Release option –either from the menu or from the toolbar action selection window — brings up the following dialog:

The preview shows that a new release branch will be created. Most of the time, you want to start the release from the latest commit in the development branch, but you can choose to base it on another commit if you wish. This essentially freezes the release, so it’s not affected by subsequent development. You can also perform preparatory tasks for the release process on this branch, such as updating the version number in source files, updating changelogs, or committing other tweaks. Once these tweaks are done, you can finish the release as described below.

Finishing a release

Once all the adjustments required for the release are done and committed, you can conclude the release process.If you’re on the release branch already, the git-flow button will show you the following dialog:

The preview illustrates that the release branch will be merged into the production branch (‘master’ or ‘default’ normally) to indicate an update to the deployed version. Sourcetree will also create a tag here for the release. The release branch changes will also merge back into the development branch to make sure the develop branch is kept up to date.

Starting a hotfix

What if you need to just fix a bug on the latest release? You don’t want to create a new release, because that will pick up the recent changes from the development branch. So instead, you can start a hot fix:

Hot fixes always start from the latest production code from the ‘master’ or ‘default’ branch. Other than that, they’re basically the same as release branches. Moreover, when you’re finished with the hot-fix, they behave the same way as finishing a release branch. The changes are merged back into both the production branch and the development branch, and a tag is created on the production branch for the hot fix release.

Wrapping up

Git-flow is a great way to automate your handling of branch-based development in Git, and SourceTree now provides a simple and clear way to use it with an easy-to-use and intuitive GUI. Big thanks to Vincent Driessen for coming up with git-flow in the first place!

Try the Git-flow workflow yourself with Sourcetree 1.5!

  • http://twitter.com/E_8 Wolfgang Keller

    A real pity that you only offer Git-flow for Mac OS X and neither for Windows nor for Linux.

    • Jeffrey J. Hoover

      an interesting reversal of the common practice of releasing for windows first and mac later (maybe)…

    • asdf

      No real developers use Windows anymore.  This is why.  There’s no “GitHub for Linux” or “GitHub for Windblows” either.

      • http://www.atwix.com/ Alexander Turiak

        You are wrong, there is GitHub for Windows http://windows.github.com/

      • http://otac0n.com/ John Gietzen

        Your hideous neckbeard is showing.

    • asdf

      git itself wasn’t available for windows for _years_ after it was introduced.  Nobody cared.  Windows is for old people and big slow stagnant corporations.

  • Joel Parker Henderson

    I will pay money for this on Linux.

    • http://twitter.com/psluaces psantosl

      How much money?

    • A

      This is already made for linux and windows and osx.. the git flow is set of scripts that you can get and install.. then use via command line like git flow feature start alabala.. sourcetree is a git gui that will issue those command for you.

  • Torger Wuellner

    For Hg, the main branch for development is typically “default.” Is there a reason the GUI is setting production to “default” or “master” when initializing the flow?

    • Anonymous

      When using hg-flow, ‘default’ is the production branch, not the development branch, just like the production branch is ‘master’ on git-flow. In both the recommended style is to use a new branch called ‘develop’ for development. SourceTree defaults to these conventions because git-flow and hg-flow use them.

  • Pingback: Oh the path with git-flow | Bram.us

  • Pingback: The problem with Git « cartesian product

  • Pingback: Merge or Rebase? – SourceTree by Atlassian

  • infotexture

    Git Flow and Subversion

    Any chance SourceTree might be able to support a git-flow workflow for Git clones of Subversion repositories?

    Git-flow uses the `–no-ff` flag to ensure that a merge commit is always created to preserve the information about the historical existence of a feature branch, but this approach conflicts with the recommendation for git-svn to avoid such merge commits by rebasing.

    Could SourceTree include some logic that would enforce the use of the `–no-ff` flag when starting and finishing features, yet still default to rebasing whenever a feature or release branch is pushed upstream to the `git-svn` remote?

    • Anonymous

      You could make this work for features by selecting the ‘rebase’ option when finishing a feature, but in general git-flow and git-svn are just not very compatible, because hotfixes always need to use merging, and as you know git merges can’t be sent to Subversion.

      Maybe you could track your git-svn branch in a completely different local branch, called ‘svn-upstream- or similar, then work with git-flow in the usual branches, then when you want to send things upstream do a git merge –squash (not exposed in SourceTree yet though) into the svn-upstream branch, replicating the changes without needing the merge metadata.

      Generally though, I think I’d have to consider git-svn to be fundamentally incompatible with git-flow. Another reason to encourage the masters of the upstream repo to switch to DVCS ;)

  • Brian Clear

    spent two day cramming hg/hg flow and sourcetree… so far so good. one problem I have though is when I finish a release the TAG WITH THIS MESSAGE is greyed out. in the screenshot above theyre enabled. I thought one of the tenet so Hg/git Flow was to tag the default/master when you finish a release or do I finish then tag default. I presume its the tagged default branch is where I ultimately package up my code for the App Store say?
    I’ve tested on two separate repos.

    • Anonymous

      This is actually because hg-flow doesn’t support messages on tags right now. The same UI is used for git-flow and hg-flow but some options are disabled where they’re not available.

      • Brian Clear

        ok cheers. One other thing I noticed while using it is that it would be nice to assign a color to branches ourselves. the light blue and light pink swap when you switch branch. Not a problem when you are on the main screen as I only switch branches using the toolbar on the left. But when you click on merge youre only shown the revisions table and asked to pick a branch to merge in. The graph lines on the left also move around so can be confusing. Is there a bug site/wishlist site? cheers. Also adding support for DeltaWalker for diff would be good too.

        • Anonymous

          Yes, this has been requested once before, you can add your 2c and/or upvote the feature request here (backlog priorities are very much influenced by the number of user requests): https://jira.atlassian.com/browse/SRCTREE-1191

          I did try to support Deltawalker once before but found it to be very unreliable and buggy, such that I didn’t want to officially stand behind it as fully supported. This was a while ago now though. You can actually add it yourself by using the ‘Other’ option and providing the settings yourself – any diff/merge tool can be configured that way.

          • Mark

            You can actually add it yourself by using the ‘Other’ option and providing the settings yourself – any diff/merge tool can be configured that way.

            a very good thought, +100500
            more

  • Pingback: Getting started with Git | Kerstin Huppenbauer

  • Pingback: » Using git and gitflow

  • Pingback: SourceTree for Windows adds Git Flow support | SourceTree Blog

  • Pingback: SourceTree – Git & Mercurial client for Windows and Mac updates | Bitbucket Blog

  • Muhammad Ishaq

    has a small issue. am using 1.0.5.0 on windows.

    when finishing a feature (merging back to develop) it always goes for fast-forward if possible even if you have disabled it in the preferences, this has the adverse affect of losing branch history. may be it’s just me. am doing Git Flow manually for now.

    • Anonymous

      Yeah, it’s in the git-flow code to fast-forward on feature finish if there have been no changes in the destination branch, there’s no option to turn that off in the git-flow script hence why the ST option doesn’t affect it.

      • Muhammad Ishaq

        Thank you for reply Steve, that explains it. so should I file this as an issue with gitflow script on GitHub? no idea why Vincent said “no fast forwards” in the blog post and didn’t do it in the script :-)

  • Sivakumar Kailasam

    Is it possible to finish a feature/release/hot-fix with a pull request instead of directly merging it?

    • Ciprian Diaconasu

      Yes, we would need this too, because how are we able to do code reviews if the code is merged on develop with no pull request from the feature branch to develop?

      • Anonymous

        You can do this with SourceTree for Mac 1.7 and SourceTree for Windows 1.2. Just submit a pull request from within SourceTree and when the pull request is accepted, your fetch will bring that merge in to your local copy, effectively finishing the feature.

        • Ciprian Diaconasu

          Thanks for the tip!

  • Joost van der Drift

    I have an existing HG repository with several feature branches and the ‘default’ branch for production and a ‘Test’ branch which contains several features that are in test but are not ready to go to production yet.
    If I want to start using HG Flow on this repo, how do I deal with the existing branches? I do not want to loose the features included in my ‘Test’ branch.

    • Anonymous

      You won’t lose any existing branches, it would only be an issue if one of your existing branches had the same name as one of the hgflow ‘special’ branches like develop. Any other branches will remain as normal and you’re free to manually manage those if you want.

      • Joost van der Drift

        Well I took the plunge…
        and not all went well. The ‘develop’ branch was not created and another branch had many changes, as if SourceTree tried to make that branch the ‘develop’ branch. I could not discard these changes, so I had to commit them.
        After that I was able to create the ‘development’ branch manually from the ‘default’ branch