I believe because they are all fundamental concepts and mechanisms of how things work, they should be applicable in solving many other relevant Git puzzles as well. I learned quite a few things about GIT & Github from this exercise. But if we understand the root cause and set branch rules accordingly, we could prevent the regular hassles from happening, which is especially important for large dev teams. Of course, conflicts are not the end of the world and still can be resolved manually. Now, the puzzle was solved: when we merge hot fixes back in the previous release cycle, different types of merge methods cause the different outcomes when the next release cycle starts. Git has no idea which diff to apply, so it throws in towel by saying merge conflicts. When Git applies both diffs on C2(merge base), Git has two different updates on the same line of the same file. Diff between C2 & C8 is to update from v1.0 to v2.0.Diff between C2 & C5 is to update version from v1.0 to v1.1.In the meanwhile, on develop branch, C6 is added as a new feature. Commit C4 is created for that then we updated the app version with commit C5. When we managed our app releases(Android project), we realized that whenever we added hot-fixes to master branch(release branch) and merged it back to develop branch(trunk branch), if we used squash or rebase merge on Github, the next time when we released, Git would always tell us about conflicts, even we had already merged everything from master back to develop. Let us go back to the original incident that prompted me to go down the investigation in the first place: Now we have understood what the two types of Git branch merge( fast-forward & three-way) mean. Because there are three important commits involved for Git to perform the merge. Now we also see why it is named “three-way merge”. (Also note, the snapshot content of C7 is also the same as C6) Since this is a merge from develop to master, Git moved the master branch name to C7. Because no real diff between C3-C4, Git only needs to apply diff of C3-C6. Apply both diffs to the merge base(C3).Diff of C3-C4, which are identical thanks to the previous -no-ff merge.Their closest common ancestor is C3(merge base).create merge commit (aka three-way merge)įast-forward merge happens when “merge branch A to branch B”, the commit that branch B points to is already on the branch A.Īpply to the example: when merging branch develop(A) to branch master(B), the commit that master(B) points to is already on branch developer(A).There are two kinds of merges and we will dig into each of them. “Merge branch A to branch B” means to make all the commits on branch A also on the branch B. Commit 38a9c(C1) is on both master and develop branches, because it is on the parent chains of both commit b6362(C2/master) and commit 60d31(C3/develop).Commit b6362(C2) is on branch develop, because that commit is an ancestor commit of 60d31(C3), which branch develop points to. With the same diagram above as example, we can say: What “on branch” meansĪ commit is “on the branch” means that the commit is an ancestor, or is reachable through the parent chain from the commit that the branch name points to.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |