Stop copying, it's time to merge. Part 2. A merge conflict that never happened (but should have been)

The last time we saw how changing the code in a copied commit creates the danger of a conflict that sits quietly until both copies merge somewhere, which may happen in the very distant future. But you know what's worse than a merge conflict?







The absence of any conflict.







Let's go back to the old situation:







first tree







Let's imagine that the "feature" branch has been around for a long time and is periodically merged into "master". The diagram shows a snapshot of the tree just after the last merge A. We are working on a sprint in "feature" full of new functionality.







Suppose the line "apple" is in the settings file that controls some feature. Both branches commit commits M1 and F1, which do not touch this file.







Now let's imagine that we have found a serious error in an old feature that completely destroys the behavior of the entire program. Abruptly stopping the problem, we turn off the feature by changing the line to "berry" and committing the changes as F2.







In life, something like changing line c will happen







#define IS_FEATURE_ENABLED 1
      
      





on







#define IS_FEATURE_ENABLED 0
      
      





But since I started using "apple" and "berry", let them stay that way.







, , , "master". , , , .







"master", "feature", .







, "master" . , F3 "feature" . :







Bug fixed







"berry" M3 "master". "feature" "apple" F3.







"feature" "master" . :







Oops







M4, "berry". "master" ! , "master" : , . , . , "feature", "master" .







, .







:







Before merge







Git (merge base): , . Git - (three-way merge), , M3 HEAD, F3 . , :







simple







"master" "apple" "berry". "feature" . "apple" "feature", "master" . "master" "berry" .







, "master" "feature", "berry" "feature":







incorrect







, . ( ) "apple", "feature" , "berry" "master". , (fast-forward) .







" , ", . , , , .







If you are careful not to touch the lines involved in the copy, the expectations will be met. Otherwise, instead of merging, you will end up with overlapping changes. Worse, if your changes undo the copied ones, you won't even get a merge conflict to show that something is wrong. Within our team, we call this the ABA problem because first the line contained A, then it was changed to B, B was copied, and then returned to A just before the merge into "master".







Well, in short, we wanted to do a partial merge from "feature" to "master", but the problem is that there is no "partial" merge.







Or is there?







In the next article, I'll show you how to do it.








All Articles