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

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

I don't understand this graph

image2016-11-18 15:10:26.png

Hi Guys, our team is currently migrating to Git and Stash. we are new to both Git and Stash, please bear with my ignorance here. 

my question is, the last commit said merging feature branch; but what i see from the graph is merging the purple(which is master I think, might be local master) to master. I am sure I am wrong. but how shall I understand this bit of graph?

Second thing is, the green dot (for feature/VT-PHEW), I am merging from master to feature and then the feature branch just floats there and I don't see a connection that it goes back to master. I am sure I am wrong again, but how to interpret the graph though?

Last but not least, the blue-ish line, the purple line, and the yellow line all seemed to mean master branch here. 

This is confusing to me. shouldn't we just just have one master all the time?


Thanks guys!

2 answers

1 accepted

2 votes
Answer accepted
Seth Rising Star Nov 17, 2016

Your confusion is understandable, but is based on some bad assumptions.

To put it briefly, Git (and by extension, SourceTree) does not know or care which commits used to be in a branch. The colored lines don't represent branches, they represent the parent/child relationships between commit objects.

SourceTree doesn't associate colors with branches. The most recent commit is ALWAYS on a blue line, or blue and red/pink if it's a merge commit. SourceTree assigns colors to new lines as it needs them.

I'll use these terms in regards to your screenshot. Since you cropped out commit ids, I'll refer to commits by an abbreviation of the color of the commit/line (B for blue, R for red/pink, Y for yellow, and P for purple, G for green) along with a number counting up from the bottom (bottom commit is B1, next is R1, then R2, then P1, etc):

  • All of the branches in question trace their ancestry back to B1 at the bottom of the screenshot. 
  • B2 has the commit message "change on master", so I'll assume that was committed to master (safe assumption, not contradicted by the rest of the graph). It follows that all of the blue commits were part of the master branch.
  • P2 is the active commit for bugfix/busaba-test1, so it's safe to say that the purple line entirely belongs to that branch.
  • Y1 is the only yellow commit, and its commit message indicates that this is ALSO master. This may seem contradictory, but each user has their own repository, so B2 was commit to one user's master branch, and Y1 was committed to another user's master branch. B3 is the merge of these two master branches so the result could be pushed to origin/master.
  • The red/pink commits were probably all committed to feature/VT-PHEW. This is where things start to get confusing.
  • One team member merged the Y1 master into feature/VT-PHEW, resulting in G1. This same user probably then tried to push their master branch, but had to Pull first (creating B3 as discussed earlier). They then pushed master to origin/master.
  • Next someone merged feature/VT-PHEW into master. This person either hadn't pulled the latest feature/VT-PHEW (G1), or the other user hadn't pushed it, so R3 was merged into master instead.

  • Now everything has been pushed.

If you merged master to feature/VT-PHEW, there shouldn't be a connection back. When you do a merge, it only modifies one of the branches (the one you have checked out when you do the merge).

Seth Rising Star Nov 17, 2016

Git documentation explaining how branches and remote branches interact with each other:

Thanks Seth! Your answer made it to our team official Stash Guide smile. it was very detailed. I have read the git doc when I just started migration but it didn't work well for me.

I have some more questions to ask based on your answer:

  1. when I merged back R3 to master, was I correct that i merged only my local feature/VT-PHEW to master branch? Given G1 (which indicates another team member's feature/VT-PHEW local branch, just like Blue and Yellow were both masters from different users) hadn't been pulled from remote/pushed to remote by team members?
  2. I didn't quite understand your last line: 

    If you merged master to feature/VT-PHEW, there shouldn't be a connection back. When you do a merge, it only modifies one of the branches (the one you have checked out when you do the merge).

    for example, I can see I have merged B2 to feature/VT-PHEW(RED-ish line) and the connection was there, unless this indicated something different.
    I might well be wrong, but did you mean when I merged master to feature/VT-PHEW, it only modified feature/VT-PHEW and no commits/dots shall appear on the graph? My impression was git merge does auto-commit if no --no-commit option was set? I was thinking a commit should appear on the graph for a merge commit?

Thanks very much for your time! 


Seth Rising Star Nov 18, 2016
  1. Yes, you merged your local feature/VT-PHEW to master. If the other team member had already pushed G1, you could have pulled before the merge, and the G1 commit would have been included. If the other team member had NOT yet pushed G1, then there's nothing you could have done.
  2. The difference is the direction of the merge. If you merge from feature to master, then the resulting merge commit will be in the master branch, not the feature (B4 is an example of this). If you merge master to feature, the resulting merge commit will be in feature, not master (this is what G1 is). There is an exception here if you allow fast-forward merges, which don't actually create a new merge commit when you merge.


On 2nd question, just as B4 is an example of feature of master, is R3 an example of master to feature (which is also not a fast-forward)?

Seth Rising Star Nov 18, 2016

Yes, that's true. If you took a snapshot of the graph before merging feature back to master, then R3 would look much like G1 looks right now. However, that particular master-to-feature merge was followed sometime later by a feature-to-master, so the R3 commit gets connected back to a commit in the master branch.

Thanks Seth! now things all come together. one last thing, how do I take a snapshot of the graph? can I go back to look at a historical graph ?

Seth Rising Star Nov 18, 2016

By snapshot I just meant like a screenshot. You can scroll through the graph to view the history, but you can't go back and see what it looked like at an earlier date - git doesn't track enough information for that.

In out-of-the-box default git, there isn't really a strong concept of a linear "master" branch.  Instead "master" is just a pointer to a commit, and while the left parent (e.g., the first parent) is generally the previous "origin/master" commit, there's no guarantees.  To further confound matters, out-of-the-box default "git pull" commands tend to create merge commits with "origin/master" in the 2nd-parent position.  This combined with a repo that allows "--fast-forward" can quickly cause havoc with master's history, turning it into a spaghetti.  See Atlassian's own aui.git repo as an example of git Bolognese (note, that's my demo clone of aui.git to show off my commit-graph add-on).

I posted a stackoverflow question & answer for more reading on this:  [StackOverflow] How can I prevent foxtrot merges in my 'master' branch?

You can enable the "Bit-Booster Hook" in my Bit-Booster Commit Graph and More add-on to make your branch history more predictable and linear.  It does this by rejecting commits that perturb the --first-parent relation:  e.g., the previous "origin/master" *must* appear in the --first-parent history of any subsequent commits.

I also wrote a guest blog post on for that goes into greater depth on this:  Protect our Git Repos, Stop Foxtrots Now!

While I don't see any foxtrot merges in your graph, I think my blog post on the subject will help you deepen your understanding of commit graphs in general.

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events