Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

How to read the Graph in SourceTree, part 2

buchs August 11, 2016

I found this other question here that seeks general understanding of the SourceTree history graph. There was a start of an answer, but I want to take it further. I'd love to get pointers to documentation or other helpful information. However, I will ask a few specific questions about this particular case.

sourcetree.png

For the given Git repository, I have 8 branches local and I have highlighted an additional branch that is only remote.

  1. How can I tell which vertical track goes with which branch?
  2. The diagonal lines I understand as indicators of merging and branching. Some of these have one colored circle end point anchored on one of the tracks, but none have two. How do I tell which branch they came from or are going to. 
  3. Many of the lines push right past the rightmost track. Does that indicate they are anchored to a branch not shown?
  4. How can I control which branches are shown?
  5. With the branch highlighted, I get the blue bar across the graph/description windows. That doesn't indicate a merge or branch - so what is happening there?

Of course, any pointers to further documentation would be greatly appreciated. 

 

2 answers

1 accepted

4 votes
Answer accepted
Seth
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.
August 11, 2016
  1. You can't. Despite the visual image brought to mind by the word "branch", in Git, a branch refers to one commit. Each commit can have one or two parents. The graph is just a visual representation of that chain of relationships. If you want to find what branch(es) are descendants of a line, you can only scroll up until you find commits on the line that have connected branches.
  2. The diagonal lines should always go "to" a commit. To find where they come from, follow them to the opposing vertical line, then follow that line down to the first commit on that line. The only know way to know what branch(es) were involved at the time of the merge is if the committer listed them in the commit comment.
  3. No, it means the display area for the graph isn't wide enough. You can click and drag between the column headers to resize it.
  4. You can control which branches are shown at the top, but options are limited. You can show just the current branch, or all branches. You can also choose whether the graph should include remote branches or not (origin/...).
  5. It indicates a commit that is on a line that is outside the visible part of the graph. As mentioned in (3), resize the graph to find the dot representing that commit. EVERY row in that list represents a commit, and will have a corresponding dot on the graph.

 

Rick Culpepper August 11, 2016

@Seth, it appears that you and I were writing the same answer at the same time!

Seth
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.
August 11, 2016

Yeah, good to have both though as confirmation/clarification.

buchs August 11, 2016

Thanks.

Rick Culpepper August 11, 2016

Agreed, @Seth. As my brother is fond of saying, "GMTA!" (Great minds think alike!) LOL

5 votes
Rick Culpepper August 11, 2016

First of all, may I suggest you get a good book or online training course on Git and study up? Getting these concepts straightened out will serve you well if you are going to be using Git.

The commit, not the branch is the fundamental unit of work in Git. Everything depends on the commit. A branch is nothing more than a pointer to a specific commit. This is true even for master and HEAD. I think you might be confusing these two concepts which leads to your questions.

  1. You can't because the vertical tracks do not necessarily go with a specific branch. These tracks follow the lineage – parent to child – from one commit to the next. This lineage is fundamental to Git's operation. 
  2. These lines show lineage, .e.g., commit 22e4035 is parent to commit 2394ed5. The branch, is only a pointer to the commit that is the current "top-of-the-world" for the branch. Remember this: a branch can be deleted, a commit cannot. 
  3. The lines that run to the right are showing lineage to a commit that exists, but that is not visible. Go to the Graph column header and stretch the column to the right. They'll appear.
  4. Use the button above the Graph column header. It defaults to "All Branches". You can change it to "Current Branch". There are no other options currently.
  5. That blue bar isn't highlighting the branch. It is highlighting a commit. You see a branch name here, because that branch current points to that commit. A commit means that something that was changed was committed to the repository. That could be a merge or a branch or just checking in some files that were edited.

Hope that helps.

buchs August 11, 2016

Thanks.

Rick Culpepper August 11, 2016

YW, @Kevin Buchs.

thinsoldier
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.
August 13, 2016

Commits that do not have any connection to any branch or tag label will not show up in the Sourcetree ui or git log, so deleting a branch can make 9,000 commits just disappear.

If you had recently checked out the branch before you deleted then a reference to it will be shown in the git reflog command list and you can then create a new branch or tag from the commit hash shown there. 

kevin.tracy December 2, 2019

The graph was very obviously designed by a coder. If it had been designed by a UI/UX Engineer, it would've had much more utility, I think.

A graph is a visual representation, a metaphor, if you will, abstracting esoteric information such as statistics or formulas or, in this case, relationships into an image everyone can understand. A metaphor should be readily recognizable at a glance, it should have a representation that a person can recognize. The mere fact that this graph spurs so many questions and requires such repeated and meticulous explanation makes it a bad metaphor, a bad visual representation, and therefore a bad graph.

Like Ron Prestenback likes this

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events