I don't understand this graph
Asked by Qiuxiao (Cash) Mu:

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!  
[](https://community.atlassian.com/t5/Sourcetree-questions/I-don-t-understand-this-graph/qaq-p/58200?attachment-id=2280){#link_1168affa542211}  
[](/tnckb94959/attachments/tnckb94959/sourcetree-questions/1665/1/image2016-11-18%2015%3A10%3A26.png){#display_1168affa542211_0}  
[](https://community.atlassian.com/t5/Sourcetree-questions/I-don-t-understand-this-graph/qaq-p/58200?attachment-id=2281){#link_1168affa542211_0}  
[](/tnckb94959/attachments/tnckb94959/sourcetree-questions/1665/2/image2016-11-17%2018%3A23%3A59.png){#display_1168affa542211_2}


Answers:
author: Seth
body: 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).

comments: author: Seth
body: Git documentation explaining how branches and remote branches interact with each other: <https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches>


author: Qiuxiao (Cash) Mu
body: 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!


author: Seth
body: 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.*


author: Qiuxiao (Cash) Mu
body: 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)?


author: Seth
body: 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.


author: Qiuxiao (Cash) Mu
body: 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 ?


author: Seth
body: 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.


author: G__Sylvie_Davies__bit-booster_com_
body: 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](http://vm.bit-booster.com/bitbucket/plugins/servlet/bb_net/projects/BB/repos/aui/commits) repo as an example of git Bolognese (note, that's my demo clone of aui.git to show off my [commit-graph add-on](https://marketplace.atlassian.com/plugins/com.bit-booster.bb/server/overview)).

I posted a stackoverflow question \& answer for more reading on this: [\[StackOverflow\] How can I prevent foxtrot merges in my 'master' branch?](http://stackoverflow.com/questions/35962754/git-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](https://marketplace.atlassian.com/plugins/com.bit-booster.bb/server/overview) 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 [developer.atlassian.com](https://developer.atlassian.com) for that goes into greater depth on this: [Protect our Git Repos, Stop Foxtrots Now!](https://developer.atlassian.com/blog/2016/04/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.