Sourcetree graph - master vs develop

I've only just started using git and I'm confused by the sourcetree graph

As a newcomer to git, this outline here seems to be very logical:

That would suggest I have a master branch with stable and deployable code, and a parallel develop branch where I can fix things/add features

Turns out that git flow in source tree supports the same type of layout. For example, if you choose to add a new feature, it gets added to the develop branch instead of the master branch

This all makes sense to me, but this isn't really reflected in how the graph is displayed

I've spent the last few hours trying to figure out why the graph in sourcetree is straight/linear despite using git flow to create a develop branch, as well as features off of that branch

It turns out that even if I add features to develop, no branching will occur in the graph unless I make a commit to master that does not exist in develop/any other branch

This seems backwards to me and doesn't fit with the layout in the site listed above, or the layout adopted by git flow. In order to get branching in the graph, I need to make changes to master that are different from develop. Doesn't it make more sense that I should make commits to develop that don't exist in master? (i.e. the other way around?)

Am I just fundamentally misunderstanding git? In my mind I should be making constant commits, features additions in the develop branch, and then merging back into master. But it seems the only way to get graph branching is to make those constant commits in master instead (and then merge into develop?...)

3 answers

1 accepted

To follow up on what the others have said:


Yes, you should commit to the develop branch and then merge to the master branch.  Actually, if you're following full Git Flow, you should commit to feature branches, merge to the develop branch, do integration testing and making any necessary integration fixes, and then merge to the master branch (or maybe to a release branch and then the master branch).

But that's all part of "Git Flow" and not enforced by Git.  It's just a work flow (and only one of several out there - see for instance GitHub Flow which is probably beginning to surpass it in popularity).


SourceTree doesn't show a divergence when you commit to a branch because the two lines of development haven't really branched off - one has just gone ahead.  Unless a commit is made on the master branch - either directly or by merging another branch in the meanwhile - the repo's history is still linear, with every commit having only one parent commit.  In fact, if that's still the case when you go to merge, Git/SourceTree will by default perform a "fast forward" merge in which the "master" branch label is just moved to the tip of the develop branch, and the history will still look linear. It's common in Git Flow to turn that feature off so that merge commits are always created (even though they're technically unnecessary).

Basically GitFlow diagrams are designed to show a conceptual understanding that is useful conceptually but the SourceTree diagram is a little closer to showing what is actually happening in Git.

From the point of view of the directed acyclic graph (dag) that is at the heart of Git's data structure, there is no difference between 

Screen Shot 2016-04-04 at 12.34.46 PM.png


Screen Shot 2016-04-04 at 12.36.11 PM.png

and git shows it the first way



The graphs in git flow are expressly designed to make the workflow it is describing perfectly clear. While SourceTree supports git flow, it doesn't require it. Furthermore, attempting to maintain a permanent horizontal position for each branch becomes a huge space waster (and probably nightmarish to implement) in larger, older projects. Here is a screenshot of part of my repository's graph (from months ago):

image2016-4-4 7:52:20.png

Suggest an answer

Log in or Join to answer
Community showcase
Brian Ganninger
Published Jan 23, 2018 in Sourcetree

Tip from the team: workflow and keyboard shortcuts

Supported Platforms macOS Sourcetree has a lot to offer and, like many developer tools, finding and using it all can be a challenge, especially for a new user. Everyone might not love ...

241 views 0 3
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot