Git: SourceTree and git flow


SourceTree is a free Git and Mercurial client for Windows or Mac. If you use DCVS in such a “classical” way (with develop branch, deployable / release branches) you can use, directly from the interface, git-flow from Vincent Driessen. More information about various Git flows can be found here. Questions and answers about SourceTree can be found here. SourceTree features:

  • Manage all your repositories, hosted or local
  • Create, clone, commit, push, pull, merge, and more
  • Use git flow with ease


SourceTree and git flow

SourceTree’s git flow integration is context aware. For example, when you are checked out on the develop branch, SourceTree’s git flow dialog only gives you the option of starting a new release or a new feature. When you are working on a feature branch, the dialog guides you in the right direction by suggesting that you finish your feature (which merges it back into the develop branch), and so on.

Git can use four major network protocols to transfer data: Local, Secure Shell (SSH), Git, and HTTP. For these examples we will work with a local repository. To local reposity exists in /opt/git/test. Type git init –bare project.git to create a new remote (shared) repository in this folder.

Git Clone

After installation you start SourceTree and choose Clone / New. Paste the repo’s clone URL and map it to the local folder of your choice.


Because this is an empty repository there are no files, no branches etc.


Master branch

Git flow requires a master branch to exist, but git only creates a master branch after committing at least one file. In git flow, development takes place in the develop branch it is recommended that each developer starts with a solid base. I.e. if you are going to build a Symfony (or Drupal etc.) based website you can add a basic installation to your master branch. When a developer starts off with the develop branch, they don’t have to wait until a fellow developer has pushed a basic Symfony or Drupal installation from his or hers local develop branch to the remote develop branch.

Install Symfony

For this article we are going to install Symfony in our local project map by typing:

curl -s | php
php composer.phar create-project symfony/framework-standard-edition symfony "2.5.*"

Commit to local master

After installation you will notice that SourceTree shows you a list off all Unstaged files.

Click on Unstaged to stage all these files.


Click on the Commit button to commit you’re staged files to the local master branch.

Under Branches you’ll find your local branches. Any commits made on these branches will be kept locally, until you push to your origin.

Under Remotes you’ll find your remote branches. Here, we only have the origin remote: this is your copy of the remote (shared) repository hosted on our local server.

Sidenote: you never commit directly on a remote branch; they are typically “read-only” and used solely as a staging area when fetching new changes from the server or when pushing your changes back to origin.

When you clone a repository, two copies of the server’s branches are made locally: one (under Branches) for your working branches and another (under Remotes) to track and push changes to/from the local server-hosted repository.



Checking out a new remote branch will automatically create a new ‘special’ type of local branch, called tracking, under your Branches. When you Push from a remote-tracking branch, git automatically know which remote branch to update and which server to upload to. In other words, a tracking branch is a local branch which has a special relationship with a specific remote branch.

Working directory status

You will also notice that your working directory is clean (bottom right icon). Never attempt to Checkout, Branch, Merge, Pull or Push when your working copy is not clean. The icon next to the ‘Clean’  icon indicates which branch you have currently checked out. Unless you checkout another branch, your next commit will be applied on master.

Git flow

Git flow provides a series of high-level commands that help standardize branch management on large projects. SourceTree gives us a nifty integration with git flow to steer our workflow in the right direction. Before applying any changes click the Git Flow button and initialize git flow in your repository.


The develop branch will be created and checked out automatically. Note that Git flow must always be set up on your local copy (even if your origin already has the proper branches already created) – these settings are kept locally with each clone.

Push to remote develop branch

Now it’s time to push our Symfony installation to the remote develop branch:


Your fellow developer can now do a checkout or pull in the changes from the develop branch:


Let’s change a file

We are currently on the newly-created develop branch and we make a change to the file. Note that the file status tab in SourceTree is automatically refreshed to indicate that your working copy is not clean anymore.


Click on the File Status tab to make the visual diff of this file’s changes appear on the right.


You can now stage this file and once your changes are staged, you can Commit. Note how only the local develop branch points to your new commit. All other branches are now ‘behind’ the develop branch, so to speak.

Create a release

Code pushed to the master branch should be considered ready for release. You start a release branch when you want to start preparing a new release. These steps will:

  • Create a release branch from the develop branch
  • Update the version
  • Merge it all to the master branch
  • Create a tag
  • Merge back to the develop branch
  • Delete the release branch

To create a new release branch click the Git Flow button and click the Start New Release button.

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.


You’ll notice a new branch under Branches called 1.0 in a folder called 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:


Press the Finish Release button. 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.


After finishing the release the log / history may look like this:


Hotfix the release

Hotfixing should be done to fix issues with a release. The process is almost identical to the release process although the hotfix branch is created from the master branch to reflect a change to the last release. You don’t want to create a new release, because that will pick up the recent changes from the development branch. The changes are merged back into both the production (master) branch and the development branch, and a tag is created on the production (master) branch for the hot fix release.

To create a new hotfix branch click the Git Flow button and click the Start New Hotfix button. The preview shows that a new hotfix branch will be created.


You’ll notice a new branch under Branches called Fix_user_login in a folder called hotfix. Once all the adjustments required for the hotfix are done and committed, you can conclude the hotfix process.This is identical to the Finish Release proces, the changes are merged back into both the production (master) branch and the development branch, and a tag is created on the production (master) branch for the hot fix release.


After finishing the release the log / history may look like this:


Sharing a branch

If you want to share a branch, let’s say a hotfix branch you have to push it to the remote repository. When you push you’re local branch to repository the dialog with repository and branch selections have checkboxes that are named Track and have 3 states:

  • checked: set the remote branch to be the one the local branch should track, i.e. your local branch Fix_database_corruption will automatically push to and pull from origin/Fix_database_coruption
  • unchecked: stop the local branch tracking anything
  • mixed (-): don’t change any tracking on this branch, leave it as-is


The mixed setting is the default so that you can push ad-hoc to different remotes / branches from a local branch and not change the tracking setup (neither setting it to a new branch, or unsetting it to stop tracking).

SourceTree uses the tracked branch to know what state you are in locally. If you switch the ‘tracked’ branch, SourceTree will show that new branch by default next time you open the push/pull dialogs. SourceTree will also change how it displays the notifications of how many commits ahead/behind your local branch is.

To start working on this shared branch you have to checkout this branch as explained somewhere in this article.


Leave a Reply