Two people on a four-person team have been working for five days on branches nobody has
merged. Both touched the same pipeline file. The second person to merge gets a conflict
spanning most of the file, spends an hour resolving it while a demo is waiting, and takes
"their side" for the big blocks to make it stop. The build goes green and the merge lands.
Three days later a fix that was definitely written and definitely reviewed is not in the
code. git log shows the commit. The file does not contain it. The person who wrote it is
told they must have forgotten to push.
Any team of three or more sharing one repository, and it fires hardest in exactly the situation P5 creates: several people fixing different defects in the same small codebase in the same week. A repo of a dozen files gives everybody the same handful of shared seams — the feature module, the config file, the requirements list. Also common when one person is designated "the git person" and the others avoid the tool. Linked modules: P5 (Team project on inherited broken codebase), 0.2 (Git and GitHub as an engineer), 4.5 (Testing ML code), 4.6 (CI/CD with GitHub Actions).
Nothing was lost by git. Git never loses a commit that was pushed; the commit is still reachable and the work is still recoverable. What was lost was a decision, made by a tired person under demo pressure, about which of two versions of a hunk survives. A conflict resolution is a code change, and this one was never reviewed by anybody.
Three causes stack up and you should name all three. The first is branch age. A branch
that lives five days accumulates conflicts with everything else being merged, and the size
of the conflict grows faster than the size of the work. A branch merged twice a day almost
never conflicts badly. The second is the shared file. Two defects in the P5 repo both live
in src/features.py, so two people editing "different things" are editing the same
hundred lines. The third is the resolution itself: choosing "ours" or "theirs" for a whole
block is not a resolution, it is a coin toss with extra steps.
Confirm it in two commands. git log --oneline --all -- path/to/file shows every commit
that touched the file, including the one that is supposedly missing. git show <sha> shows
what that commit actually contained. If the commit exists and its content is absent from
the current file, a merge resolution dropped it, and git log --merges plus git show -m
on the merge commit will show you which one and when.
The organisational cause sits under all three: nobody said out loud that they were about to touch that file. Two people planned their work separately from the same defect list and never compared file names.
Immediate: recover the work, do not rewrite it. Find the commit with
git log --oneline --all, then git show <sha> > /tmp/lost.patch and read it. Apply it on
a fresh branch off current main with git cherry-pick <sha>, resolve the small conflict
carefully this time, and open a normal pull request for it. The person who wrote it does
the recovery, not the person who merged, because only they know what the change was meant
to do.
Then change how the team works, in this order.
One defect, one branch, one pull request, and open the pull request within a day of
starting. Branch names that carry the defect id — fix/D02-drop-leaked-columns — make the
scope visible on the branch list before anybody reads a diff.
Integrate daily, in both directions. Every morning each person runs git pull --rebase origin main before touching anything. Every merged pull request is announced in the team
chat with the files it touched. A conflict found on day one is four lines; the same
conflict found on day five is four hundred.
Rotate an integrator. One named person per stage owns merges to main, in order, one at a time, and does not merge their own work. That role is why the P5 workflow contract lists it first, and it rotates so every member does it once.
Resolve conflicts with the author in the room, and never during a demo. Read both sides aloud, decide which behaviour is correct, and write a one-line note in the decision log saying what you kept and why. If a test covers the disputed behaviour, run it before you commit the resolution — this is the moment the characterisation tests from stage 2 earn their place, because they fail when a resolution silently drops behaviour.
Last, claim shared files before you open them. Two people editing features.py in the same
day is a thirty-second conversation, and it prevents the whole incident.
Keep branches shorter than a day of work. This single habit removes most painful conflicts, and it is a habit, not a tool.
Make the shared seams smaller. One file that everybody must edit is a design problem, not a git problem. In an inherited repo, splitting a fat module into two files early — as its own reviewed change, before the fixes start — is often the cheapest thing a team can do.
Give conflict resolutions the same respect as code. They are edits nobody reviewed, made under pressure, and they belong in their own commit with a message that says which side was kept. Run the test suite after every resolution, before the push.
Finally, write down who is doing what, where everyone can see it, updated daily. Most teams that lose work do not have a git problem; they have two people who each assumed the other was doing something else. The decision log and the daily standup exist to make that assumption impossible.
Q: "A teammate's work disappeared after a merge. What happened and what do you do?" Strong
answer: start by saying git did not lose it, and that the commit is almost certainly still
reachable — then give the commands that prove it (git log --oneline --all -- <file>,
git show <sha>, and the merge commit itself). Name the real cause as a human decision:
somebody resolved a large conflict by taking one whole side, and that resolution was never
reviewed. Give the recovery — cherry-pick onto a fresh branch, resolved by the author, sent
through a normal pull request. Then give the prevention in three concrete habits: branches
that live under a day, a rotating integrator who merges one pull request at a time, and a
word to your teammate before you open a file you both need. Strongest answers add that
tests are what make a bad resolution visible, so the team writes them before the fixes
begin rather than after.