nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

I don't understand this graph

Qiuxiao (Cash)

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!

image2016-11-17 18:23:59.png

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

Accepted answers

Seth

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).

All comments

Seth

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

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

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

Qiuxiao (Cash)

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:

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?
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

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.
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.

G__Sylvie_Davies__bit-booster_com_

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 developer.atlassian.com 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.