How to read the Graph in SourceTree?

Jirong Hu May 4, 2016

Is there any document explains how SourceTree draw the Graph? I have questions:

  1. Does each color has specific/dedicated meaning, or just use randomly?
  2. Is the graph represent the remote repo, local repo, or both?
  3. Is there a one to one mapping from the line to the branch?
  4. When a new line will be created?

e.g. for the graph below, how shall I interpret it?

st.png

2 answers

1 accepted

0 votes
Answer accepted
Tim Crall
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 4, 2016
  1. colors are random
  2. primarily the local repo - if you check the "Show Remote Branches" box (which is unchecked in your screenshot), it will also show branches on the remote (but only those that have been fetched so it know about them - but by default SourceTree does a fetch periodically).  Branches on the remote will be labeled as, for example, "origin/master"
  3. Not sure what you mean?  But I think yes.  Each line of a new color represents a branch.  
  4. Again, I'm not sure what you mean?  A new line is created when a new branch is created and diverges from the previous branch (i.e. both branches have a commit on them that is not on the other)

    It's important to understand that once a merge has been made, from git's point of view, each line of ancestry is equally a part of that merge commit's history.  While we tend to think of one set of changes as having been made on one branch and one set on the other, git doesn't really track that information.

    Do you have a specific question about the graph shown?  There does seem to be a little bit of weirdness to it.  I can't definitively tell between the blue branch and the yellow branch which was the original develop branch and which was the DEVOP-224 branch, because once a branch has been merged, both branches are just part of the merge commits history and git doesn't really care about how they got there.  

    It looks like commits were being made directly on the development branch until the point where the yellow branch branches off, which was probably the the DEVOP-224 branch.  It's not clear to me why there is a commit labeled "create a new branch" because you don't need to make a new commit to make a branch - you just create the branch and then start committing on it.  

    The DEVOP-224 branch was then merged back into commit.  

    Then a release branch was created, a commit was made onto the development branch, and then merged into release.  This could have been a fast-forward merge as the other branch had no commits, but that was apparently suppressed.

    About then, the release branch was probably merged into master with a fast-forward merge, so there's no specific commit recording it.  It (the release branch) was maybe merged into the development branch, too, bringing all three to the same commit (the highlighted commit), I'd guess.  Then an additional commit was made directly onto the development branch, from the look of it - the commit message on that commit seems to describe it as a merge but that doesn't really appear to be the case from what I can see, and the message does not seem to follow the same format as the automatically-generated merge messages.  So I'm not quite sure what's going on there.

    If you want to have your history be more explicit, disable fast-forward merges altogether.  That will create some technically unnecessary commits (in that they don't introduce any changes compared to one of their their parents) but it will make all the occasions where merges occurred much more explicitly clear.




 

Jirong Hu May 5, 2016

Hi Tim

First of all, thank you very much for the detailed explanations. Honestly even I can't remember what I did, but I think your interpretation are mostly right. I was trying all different ways of merging (ff, rebase, etc.). To see if we can restore the action history from the graph is indeed the main idea of this post.

I have a strong background of ClearCase UCM. As we can almost explain everything from the component baseline diagram, I am trying to do the same with this graph.

  1. Random color is find, but it will be good if each line can marked with the branch name (ClearCase does this). Otherwise I can't see which branch a commit was made on, e.g. the "Test the push" commit, maybe it's the DEVOP-224 branch which had been deleted already. I guess git doesn't care about this. It's the commit it all cares about.
  2. Check the "Show Remote Branches" box doesn't change the graph, but add the branch names to the commit. It further explains git only care about the commit, not branch. Branch is not a persistent object here.
  3. I was thinking a line (connected dots in the same color) represent a branch in the graph. Now I start to doubt it. I think the graph just represent the status and history of explicitly branching and merging ( you can't see a ff merging here). 
  4. As you know, the problem of not using ff merging is the mess of the history mentioned here:http://rypress.com/tutorials/git/rebasing
2 votes
Jim Constant September 30, 2017

I found this thread that contradicts much of the accepted answer: https://community.atlassian.com/t5/Sourcetree-questions/How-to-read-the-Graph-in-SourceTree-part-2/qaq-p/165698/jump-to/first-unread-message

The thing that stands out the most is that the lines do NOT represent branches, they represents commits and this is fundamental to understanding all of this. 

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events