Question

以下是这种情况：

有一个主分支 M
在某些时候，功能分支 F 是从 M 创建的。这应该是一个功能的主要分支，所有其他处理此功能的开发人员应该从该分支扩展或直接在此分支上工作。
在某些时候，分支 F1 是从 M 创建的。开发团队的一部分创建了自己的分支，并开始处理部分功能。但是他们忘了使用 F ，而是使用 M 。其他人都不知道（包括我自己）

大多数使用该功能的开发人员都在使用 F 。他们在 M 上重新加强 F 几次（每次快进）。到现在为止还挺好。不过有些开发人员使用 F1 ，他们也会重新调整几次 M 。

今天是合并掌握的日子。所以开发人员使用 F1 重新定位到 F - 他们报告了一些合并问题 - 但几个小时后他们报告已经解决了<\ n>强> F 有所有的东西。

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

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

Answer 1

如果你将你的F合并到M而不是将F重新定义为M，那么你最多只能有一个冲突解决方案，而不是每次提交一次，就像你正在经历的那样。

在你这样做之前......我担心你的开发人员认为F和F1都没有碰到冲突的文件，因为冲突证明这些文件在F分支和master中都被改变了。如果您不应该更改这些文件，请查看带有git log的文件的历史记录，并查看它们在F中的更改时间。很可能有人在分支中引入了一些无意的更改，可能是在rebase期间。撤消/恢复这些无意的更改，您的冲突可能会变得简单得多。

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

最后，除非您的团队一次只在一个功能分支上有一个人编码，否则我会认真考虑从rebase工作流转移到合并工作流。每次重写共享分支（通过rebase或其他方式）时，它会强制共享分支的所有其他开发人员重置或将其分支重新绑定到rebaser推送的重写/重新定位的历史记录。如果有人忘记并拉动而没有重置到重新分支的分支，那么你有两个版本的历史经常相互冲突。这是一个容易出错且不必要的步骤，可以通过合并来避免。

合并破坏 - 合并两个不相关的分支，每个分支都有主变化

1 个答案: