Why Does Git Lose Files After a Merge? Mastering Three‑Way Merges and Strategies

“The file was there before the merge, but it disappears after,” “I hit a Git merge bug” – these statements are common, yet often stem from misunderstanding Git’s merge behavior. This article walks through three‑way merges and Git’s merge strategies step by step, helping you set accurate expectations and avoid merge mishaps.

Story Time

A developer creates a dev branch from node A, adds http.js on node B, and merges it into master at node E. A bug forces a revert (node E'). Later, the developer adds main.js on dev, which imports http.js. Merging dev back into master results in http.js disappearing without conflicts, leading to the mistaken belief that Git has a bug.

How Two Files Are Merged

Before understanding branch merges, we need to grasp file merges. Git uses a three‑way merge: it finds a common base version of the file, then compares the changes made on each side to that base. If both sides modify the same line differently, Git cannot auto‑merge and reports a conflict.

Git Merge Strategies

Git offers several merge strategies, selectable with git merge -s <strategy>. The most common are:

Fast‑forward : When the target branch has not diverged, Git simply moves the branch pointer forward. Use git merge --no-ff to force a merge commit.

Recursive : Default for diverging branches. Git finds the shortest‑path common ancestor (the merge base) and performs a recursive three‑way merge. The algorithm may need to walk multiple ancestors to locate a unique base, reducing conflicts.

Ours & Theirs : git merge -s ours dev records a merge commit but keeps the current branch’s content; -s theirs does the opposite, keeping the other branch’s content. Useful for preserving history while discarding one side’s changes.

Octopus : Merges more than two branches in a single commit (e.g., git merge dev1 dev2 dev3). Ideal for integrating multiple feature branches in testing or pre‑release environments.

Git Rebase

git rebase

rewrites history by moving a series of commits onto a new base. When rebasing feature onto master, Git creates brand‑new commits with new SHA‑1s because their parent changes. Interactive rebase ( git rebase -i) lets you squash, edit, or drop commits, e.g., turning two commits into one.

Summary and Solutions

In the opening example, the final merge uses the default Recursive strategy. Git selects node B as the merge base for branches D and E'. Since B and D contain http.js unchanged while E' deletes it, the three‑way merge results in the file’s removal without conflict.

To avoid this, you can:

Create a new branch from the revert node E' and continue development there, rather than advancing the original dev branch.

Revert the revert (create E'') before merging D, ensuring the file is restored.

Understanding Fast‑forward, Recursive, Ours/Theirs, Octopus, and rebase equips you to choose the right strategy, minimize conflicts, and predict merge outcomes accurately.

References

Three‑Way Merge: http://blog.plasticscm.com/2016/02/three-way-merging-look-under-hood.html

Recursive Merge (video): https://www.youtube.com/watch?v=Lg1igaCtAck

Pro Git – Scott Chacon, Ben Straub (Apress, 2014)

Version Control with Git – Jon Loeliger, Matthew McCullough (O’Reilly, 2012)