合并浩劫 - 合并两个不相关的分支，每个分支都有主变更 [英] Merging havoc - merging two unrelated branches, each with master changes

问题描述

这里是情况：

• 有一个主分支 M


• 在某些时候，功能分支 F 是从 M 创建的。这应该是一个功能的主要分支，所有其他开发这个功能的开发者都应该从这个分支分支出来，或者直接在这个分支上工作。


• 在某个点分支 F1 由 M 创建。部分开发团队创建了自己的分支，并开始研究部分功能。但他们忘记使用 F ，而是使用 M 。没有人知道它（包括我自己）。
  

大多数开发该功能的开发人员都使用 F 。他们几次（每次快进）都在 M 上重新发布了 F 。到现在为止还挺好。然而，一些开发者在使用他们的 F1 时，他们也重新发布了几次到 M 。

今天是合并到掌握的那一天。因此，开发者使用 F1 重新绑定到 F - 他们报告了一些合并问题 - 但几小时后，他们报告已解决问题， F 有所有的东西。

现在，我自己想将 F 合并到 M 中，并正式完成 F 即可。对我来说，它不能自动合并在github上。所以我做了 git fetch ，并开始将 F 重新绑定到 M 。破坏开始了，冲突。所有这些文件出现在我们在 F 上工作时甚至没有触及的文件中。我放弃了20-30个冲突解决方案和 git rebase - continueue 步骤。

现在，当我意识到（在与这些开发者）认为他们的 F1 是由 M 而不是 F 创建的，我想我知道是什么导致冲突。是否因为 M 的更改现在第二次应用于 F ？我的假设是否正确？我不确定。但是我确信我不知道如何解决这种情况。我无法及时将 F 合并到 M ，原因是我们在处理 F 时甚至没有碰到过无数次文件冲突。 。

解决方案

如果您将F合并到M中，而不是将F重新绑定到M，那么最多只能有一个冲突解决方案，而不是每次提交一次，因为它看起来像你正在经历。

在你做这件事之前，虽然......它让我感到你的开发者认为F和F1都没有触及那些文件是冲突的，因为冲突证明这些文件在F分支和主文档中都被更改了。如果您不应该更改这些文件，那么使用git log来查看这些文件的历史记录，并查看它们在F中的更改时间。有人很可能会在分支中引入一些无意的更改，可能是在重新分区期间。撤销/恢复这些无意的更改，您的冲突可能会变得更加复杂。

  git log -p origin / master..F  -  path / to / unexpected_conflicting_file 
  
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.
解决方案
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.

                        
这篇关于合并浩劫 - 合并两个不相关的分支，每个分支都有主变更的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！