You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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?
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):
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.
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).
Thanks Seth! Your answer made it to our team official Stash Guide . 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:
Thanks very much for your time!
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.
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.
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.