Today’s puzzle would make a great job interview question. It’s a question that I would’ve failed before today. Are you ready? Here it goes.
Consider the git branch feature-1, which is based on master. Is there a situation where merging the latest master into feature-1 before then merging feature-1 into master would result in a different software state than if you simply merged feature-1 directly into master? If so, describe how this could occur.
The answer is yes, surprisingly, and here’s the kicker: it doesn’t involve any manual git conflict resolution. There are probably more elegant ways to arrive at a proof, but here’s how this is possible. I’ll mostly just let you read through the logs, with an explanation at the two critical sections.
Here’s where things go wonky. The developer working on feature-1 hasn’t fetched the latest origin, and attempts to apply the latest changes that are in his latest local master manually.
At this point, if we were to merge feature-1 into master, we would not have the feature-2.md file. However, what if we had not merged the master branch into the feature-1 branch before merging the feature-1 branch into master? In that case, we would have the feature-2.md file. I’ll prove it:
The takeaway, of course, is to never fetch changes from external branches in a way that causes git to think that those changes occurred in the current branch as new code.