Merging havoc - merging two unrelated branches, each with master changes

Question

Here's the situation:

• there's a master branch M
• at some point feature branch F was created from M. This should have been a main branch for a feature, and all other devs working on this feature should have branched out from this branch or work directly on this branch.
• at some point branch F1 was created from M. Part of dev team created their own branch and started working on part of the feature. But they forgot to use F, instead they used M. And nobody else knew about it (including myself)

Most developers working on the feature were using F. They rebased F on M a few times (every time fast-forward). So far so good. However a few devs where using their F1, and they also rebased a few times to M.

Today was the day of merging to master. So devs using F1 rebased to F - they reported some merging issues - but after a few hours they reported it's resolved and F has all the stuff.

Now, myself, I wanted to merge F into M and officially finish work on F. To my supprise, it could not be merged on github automatically. So I did git fetch and started rebasing F onto M. And the havoc started, conflicts. All of them appearing on files that we didn't even touch when working on F. I gave up after a 20-30 conflicts resolutions and git rebase --continue steps.

Now, when I realized (after a chat with these devs) that they had their F1 created from M and not from F, I think I know what is causing the conflicts. Is it because changes for M are now being applied to F for the second time? Is my assumption correct? I'm not sure. But what I'm sure I don't know how to resolve this situation. I cannot merge F to M in timely manner due to infinite number of conflicts on the files that we didn't even touch when working on F.

Answer 1

If you merge your F into M instead of rebasing F onto M, you'll have at most one conflict resolution, rather than one per commit as it seems you're experiencing.

Before you do that though… It concerns me that your devs think that neither F nor F1 touched the files that are conflicting, because a conflict proves that those files were altered in both the F branch and in master. If you weren't supposed to have changed those files, look at the history for those files with git log, and see when they were changed in F. There's a good chance that someone introduced some unintentional changes in the branch, perhaps during a rebase. Undo/revert those unintentional changes, and your conflict may become much less complicated.

git log -p origin/master..F -- path/to/unexpected_conflicting_file

Finally, unless your teams only have 1 person coding on a feature branch at a time, I would seriously consider moving from a rebase workflow to a merge workflow. Each time you rewrite a shared branch (via rebase or otherwise), it forces all other developers who share the branch to ASAP reset or rebase their branch onto the rewritten/rebased history that the rebaser pushed. If someone forgets and pulls without resetting onto the rebased branch, then you have two versions of history that often conflict with each other. This is an error-prone and unnecessary step that can be avoided by just merging instead.