仅单人修改对应文件时出现Git merge conflicts的原因及解决方案咨询

为什么仅你修改的文件也会出现合并冲突 #

合并冲突的本质是Git三方合并时，两个分支相对于公共祖先节点的同一范围代码出现了不同变更，你遇到的冲突和你的代码没有直接关系，核心原因如下：

• 冲突发生在release分支反向合并到其他hotfix分支的流程中，这类其他hotfix分支的拉取基线通常远早于你使用的指定hotfix分支，和release分支的公共祖先节点更早
• release分支除了你的hotfix合入记录外，还包含了其他功能提交、其他hotfix提交，这些提交完全可能修改了你改动的文件的其他行、相邻行，当这些变更和目标hotfix分支上的同范围代码变更重叠时，就会触发冲突
• 部分冲突是Git合并策略的识别问题：如果你们的工作流中存在大量无fast-forward的合并提交，反向合并时Git可能无法定位到准确的公共祖先，导致误判大量变更冲突。你本地合并时看到冲突均来自他人代码变更，也验证了冲突和你的改动无关

cherry-pick是不是唯一的解决方式 #

不是唯一方案，可以根据你的需求选择对应处理方式：

• 如果仅需要把你自己的提交同步到目标hotfix分支：cherry-pick是成本最低的方案，只需执行git cherry-pick <你的commitID列表>，遇到冲突时仅需要处理你自己代码相关的冲突即可，不需要关心其他无关的代码冲突
• 如果需要将整个release分支的内容全量同步到目标hotfix分支：可以选择rebase方案，将目标hotfix分支rebase到release分支的HEAD节点，一次性解决所有冲突后，后续合并就不会重复出现同类问题，适合需要长期维护的hotfix分支
• 如果需要保留完整的合并提交记录：可以从目标hotfix分支拉出临时分支，先把release分支合并到该临时分支，统一解决所有冲突后再合回目标hotfix分支即可，符合对提交审计有要求的工作流
• 若大部分冲突涉及你不了解的业务代码，建议直接同步测试基建团队处理，他们作为分支规则维护方更清楚各分支的保留优先级，避免你自行合入错误的变更

内容的提问来源于stack exchange，提问作者Drake .C