Sourcetree Compare Branches

The git diff command will allow you to view the differences in your workspace. This can be used in a number of ways to look at the differences in a file, in a branch or between two branches.

  1. Sourcetree Compare Branches Side By Side
  2. Sourcetree Compare Branches Philippines
  3. Sourcetree Compare Branch To Master

For example, you can view the differences in your current workspace by just running git diff on its own. By supplying a file you can look at the differences in just that file.

To compare the difference between one branch and another you use '..' to separate the branch names. For example, to look at the differences between the head of the 'main' branch and the head of a feature branch use this syntax.

Sourcetree calls blame 'Annotate' (deprecated term), and it opens in a new window (which could be handy)). Diff shows you the individual characters that have changed. (Sourcetree doesn't have this feature) Easy to copy text from the diff view (SourceTree only allows you to copy line-by-line). Hide/show individual local/remote branches.

git diff main..feature_branch
  1. From Sourcetree, click the Branch button. From the New Branch field, enter a name for your branch. Click Create Branch. You're now on your new branch. Make any updates to the repository that you want to make to your branch. Open the History view in SourceTree and notice that your repository now has uncommitted changes.
  2. Clicking on any of the remote branch will cause SourceTree navigate to the remote branch's latest commit in the graph log. Users can choose to display or not display the remote branches in the graph log by checking or unchecking the Show Remote Branches checkbox. By default, it is labelled as origin/branchname in the graph log.
  3. Once installed, SourceTree will automatically try to look for and set up repos that are worked on. SourceTree will also detect if git-flow is used and what is the current development state as long as default git-flow branch names are used. The software tracks all relevant repositories in the bookmark's window.
  4. Solved: After upgrading to Sourcetree 3.2.6 the push dialo, 6 version) I get my local branches listed and the remote tracking branch name (if they exist) or just a blank remote branch name for local only branches. Using version 3.2.6 in Windows, starting this morning my push dialog is empty.

This can often be quite noisy, especially on large projects, so to check just one directory between two branches you can add the directory path to the command.

git diff main..feature_branch directory/to/compare

The output produced from this difference can be used as a patch file. If you need to do this then just pipe the output into a file and you have a patch file you can use to apply the changes made against the feature branch to the main branch.

git diff main..feature_branch > feature.patch

You can use the same syntax to look at the commits that are different between two branches. This will show the commits that have been made to one branch, but not to another.

git log main..feature_branch

This will just show the individual commits, so to show some context to those commits you can use some flags on the log command to dive the commits some structure.

git log --oneline --graph --decorate --abbrev-commit main..feature_branch

One thing to note is that the use of 'main..feature' will compare the head of one branch with the head of another branch. To show the difference between the head of a feature branch and where it was branched off from the parent you need to use the triple dot (...) to separate the two branches.

For example, this will show all of the changes made to the feature_branch branch since it was branched off of the main branch.

git diff main...feature_branch

Finally, if you are using either the double or single dot comparison then make sure you get the order of the items correct. You generally want to use the main/parent branch as first item as this will show you any removals and additions made to the feature branch in comparison to the parent branch. This means that if you create a patch file from this diff you will be applying the correct changes.

If you get the branches the other way around then you are looking at the inverse of the changes. Essentially, is the changes that need to be made to the feature branch in order to get it to look like the parent branch. If you use the double dot comparison create, a patch from this difference, and apply it to your feature branch code you will essentially reset that branch to be the same as the parent.

Phil is the founder and administrator of #! code and is an IT professional working in the North West of the UK. Phil is currently a Developer at Code Enigma.

Add new comment

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:

  • Keep your repository tidier
  • Keep your procedures clearer
  • Move between projects more easily with familiar branch structures
  • Get new developers up to speed more quickly

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:

  • 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)

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

Sourcetree Compare Branches Side By Side

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

Sourcetree Compare Branches Philippines

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:

Sourcetree Compare Branch To Master

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!