GitHub squash合并后仍存在冲突的原因及解决咨询

为什么冲突会重复出现？ #

你猜的没错——squash and merge正是问题的根源。

当你把fix-conflicts分支用squash合并到develop时，Git并没有把master和staging的提交历史整合到develop的历史中。Squash操作会把fix-conflicts上的所有提交压缩成一个全新的、独立的提交，然后追加到develop的末尾。这就意味着：develop和master的历史依然是完全分叉的，Git根本不知道你之前已经解决过那些冲突。所以下次你从develop拉取master时，它还是会把两边的冲突文件当作从未合并过的内容来对比，自然会重复触发冲突。

解决办法 #

根据你的团队工作流，这里有几种可行的方案：

方案1：用常规合并替代squash来对齐主分支历史（推荐）

如果团队允许develop存在合并提交，这是最彻底的解决方式：

• 从develop创建一个新的对齐分支：

  git checkout -b align-develop-with-master develop
  

• 拉取master并合并，仔细解决冲突后提交：

  git merge master
  # 解决冲突后执行 git add . && git commit
  

• 将这个对齐分支合并回develop时，使用常规的merge（不要选squash）：

  git checkout develop
  git merge align-develop-with-master
  

这样develop的历史就会和master形成一个合并节点，Git会永久记录这次冲突解决的上下文，之后再合并master就不会重复出现相同冲突了。

方案2：如果必须保留线性历史（坚持用squash）

如果团队要求develop保持严格的线性提交历史，那可以用cherry-pick把master上的热修复提交同步到develop：

• 先找到master上所有热修复提交的哈希值：

  git log master --oneline
  

• 切换到develop，把这些热修复提交逐个复制过来：

  git checkout develop
  git cherry-pick <热修复提交哈希>
  # 如果遇到冲突，解决后执行 git add . && git cherry-pick --continue
  

这样develop的历史里就会包含这些热修复的修改副本，之后再合并master时，Git能识别出这些内容已经被同步过，就不会重复触发冲突了。

方案3：发布前的前置对齐流程

可以把“将master合并到develop（常规merge）”作为发布流程的固定步骤：

• 每次准备发布前，先从develop切分支合并master，解决冲突
• 确认无问题后，再把更新后的develop合并到staging，最后到master
  这个方式需要团队配合，确保合并后的develop处于稳定状态，但能从根源避免发布时的冲突重复。

额外提醒 #

Squash merge非常适合功能分支合并到develop（可以清理功能分支的琐碎提交，保持主分支历史整洁），但跨主分支（比如develop和master）的历史对齐，绝对不要用squash——它会破坏Git的历史追踪能力，反而导致后续的冲突问题。

内容的提问来源于stack exchange，提问作者Anthony O'Neill