简而言之，我们有一个存储库，用于托管不同功能团队的代码，即服务器端、移动、ci、自动化 qa 等。
现在，当我们尝试将支持分支的错误修复下拉到 dev-release-branch 时，会出现很多与不同团队/开发领域相关的冲突。由于我们没有一个人覆盖服务器端和移动端，因此很难为一个人解决冲突。
这里的问题是：是否有可能只解决一些冲突（例如服务器端），然后推送到中间分支，并让其他团队解决与其开发领域相关的冲突。并且只有在所有团队解决了所有冲突之后，才最终合并中间分支。
也许我们在这里做错了什么。任何建议都将不胜感激（除了将代码库拆分为单独的 repo，为此为时已晚）。
【问题讨论】：
标签： git git-pull merge-conflict-resolution
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 可以查看提交的祖先并识别正确的基础。
【讨论】：
xargs -d\\n git checkout MERGE_HEAD -- <out-of-scope-files 只是按原样获取传入的内容（如果可能没有冲突，您可以使用 @ 987654324@ 合并以强制有机会进行此类修复）。可能通过标记git ls-files 输出来生成此类更改的日志，并验证是否有人在最终提交中为每个更改提供担保。
好吧，你可以试试这样的：
dev-release-branch 并开始与support-branch 的第一次合并。dev-release-branch 状态。a-half-of-a-merge，将其保存为（临时本地）标签。dev-release-branch 恢复到合并前的状态support-branch 执行另一个合并。再次重申，不考虑在第 2 步中考虑的更改。当最后一个“域”的所有冲突都解决了，但尚未创建合并提交时，让我们开始合并来自不同“半标签”的更改。
cherry-pick 从第一个 half-tag 更改。您必须使用-m 开关（可能是-m 1）和--no-commit 指定合并父级
half-tags 重复步骤 2-4
您可能已经注意到，整个过程有些漫长、复杂和繁琐。对于未来的版本，我建议将项目拆分为适当数量的子项目，然后使用 git submodules 将它们组合成一个大项目。
【讨论】：