Git 仅为某些文件解决合并冲突，并提交到分支，以便其他团队解决其冲突

简言之，我们有一个repo，它承载不同功能团队的代码，即服务器端、移动、ci、自动化qa等

现在，当我们试图将支持分支的bug修复拉到开发版本分支时，许多冲突似乎与不同的团队/开发领域有关。因为我们没有一个人负责服务器端和移动设备，所以很难为一个人解决冲突

这里的问题是：是否有可能以某种方式仅解决一些冲突（例如服务器端），然后推到中间分支，并让其他团队解决与其开发领域相关的冲突。只有在所有团队解决所有冲突后，最终合并中间分支

---

也许我们做错了什么。任何建议都将不胜感激（除了将代码库拆分为单独的回购协议，为时已晚）。

好吧，您可以尝试以下方式：

签出

开发发布分支

，并开始与

支持分支

的第一次合并

（由一个人）解决尽可能多的冲突。那个家伙不能合并的文件和目录应该恢复到它的

dev发行版分支

状态

将结果状态提交为

a-half-a-merge

，并将其另存为（临时本地）标记

将开发版本分支恢复到其合并前状态

由另一个能够合并源代码树其他部分的人使用

支持分支执行anothermerge。同样，将不被视为步骤2中的更改还原

如果要合并更改，请重复步骤3-5（当然，请选择其他标记名）

当最后一个“域”中的所有冲突都已解决，但合并提交尚未创建时，让我们开始组合来自不同“半标记”的更改

将当前更改集添加到索引

cherry pick

从第一个

半标记开始更改。您必须使用
-m
开关指定合并父级（可能是
-m1
）和
--no commit

解决在此阶段遇到的任何冲突。希望这份清单简短明了

将更改添加到索引中

对所有

half标签重复步骤2-4

最后，进行大合并

现在所有的半标签都可以安全删除了

正如您可能已经注意到的那样，整个过程有些漫长、复杂和繁琐。对于未来的版本，我建议将项目分成适当数量的子项目，并使用

git子模块将它们组合成一个大项目

git checkout -b server-team-merge dev-release-branch
git merge support-team-fixes
# fix the conflicts you can fix here
git commit -m "server-team partial merge of $(git describe support-team-fixes)"

而另一支球队也是如此。然后合并部分合并分支--如果结果确实是不相交的，您可以一次完成所有操作，这将是一个简单的操作

git checkout dev-release-branch
git merge {server,mobile,ci,automation}-team-merge

但如果这些投诉一次合并成一个，就可以找出关于如何解决一些冲突的不同想法

当您合并一个分支时，git会将结果视为结果提交中合并历史的正确和完整合并，因此任何后续合并都会将整个历史标识为共享，无需执行任何操作。但是，如果您从同一个父级进行多个独立合并，这些合并不在彼此的历史记录中，可以产生任何您想要的结果；在这些结果的后续合并中，Git可以看到提交的祖先并确定正确的基础。
我们有类似的想法，但我的印象是我们遗漏了一些东西，应该有一种更简单的方法在Git中实现。好吧，有一种稍微简单的方法-检查@jthill的答案。但他的方法在历史图表中留下了混乱的中间合并，更重要的是，它有效地打击了CI机器人的机械思维。对不起，合并后，我不太清楚我应该如何处理范围外的修复程序-只是让它们挂起在冲突状态，不提交？如果所有文件不属于我们的范围，我们是否可以从提交中排除所有自动合并的文件？我希望服务器分支只包含与服务器相关的修复程序。在提交合并结果之前，您当然可以覆盖对范围外文件的所有本地更改，
xargs-d\\n git checkout merge_HEAD--但是未经确认的更改应该在每次合并中以相同的方式自动合并，因此最终合并的内容从何处获得并不重要，从字面上看，这是完全相同的区别。考虑到这一点，我认为没有必要重新设置。对于冲突解决，您可能已经找到了一些方法来确定谁，在哪个合并中进行更改，谁有权解决每个冲突，所以只需使用该分支的版本，那么在其他分支中所做的任何事情都没有任何区别。