为何执行git merge --squash master修复冲突推送后，再次操作仍遇相同冲突？

这事儿我太熟了！核心原因就是git merge --squash的特性——它不会在Git的提交历史中留下合并关系记录，导致Git完全不知道你已经处理过一次master到uat的合并。

具体原因拆解 #

• 当你执行git merge --squash master时，Git只会把master分支的所有变更内容“平铺”到当前的uat分支，生成一个待提交的修改集，但不会创建合并提交，也不会更新uat和master之间的合并基准点（merge-base）。
• 所以当你再次运行同样的命令时，Git还是会从上次真正有合并记录的基准点开始对比两个分支的差异，自然会重复触发之前已经解决过的冲突。

解决办法分两种场景 #

场景1：需要长期同步master到uat（推荐）

如果你以后还要频繁从master合并更新到uat，直接放弃--squash，改用常规的合并命令：

git checkout uat
git merge master

• 这个命令会创建一个合并提交，明确记录uat和master的合并关系。下次再合并时，Git会自动使用最新的合并基准点，不会再重复出现旧冲突。
• 解决冲突后，直接提交并推送即可：git commit -m "Merge master into uat"，然后git push origin uat。

场景2：必须保留squash合并的方式（比如想保持uat分支提交简洁）

如果一定要用squash合并，那需要手动追踪上次合并的起点，只合并master上的新增变更：

1. 先找到上次squash合并时，master分支的最新提交哈希值。比如可以通过git log --oneline master查看历史，找到你上次合并时的那个commit（假设是a1b2c3d）。
2. 执行以下命令，只合并master上从该commit之后的新变更：

git checkout uat
git merge --squash a1b2c3d..master

• 这样Git只会对比a1b2c3d到当前master HEAD的差异，不会重复处理之前已经合并过的内容，也就不会出现旧冲突了。

小提醒 #

git merge --squash适合一次性把多个零散commit合并成一个干净的提交，但不适合用于需要持续同步的分支场景——它破坏了Git的合并追踪机制，会导致你每次合并都要手动处理基准点，反而增加麻烦。

内容的提问来源于stack exchange，提问作者Robin