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!
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).
Git documentation explaining how branches and remote branches interact with each other: https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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)?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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 ?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.