Git在简单合并时频繁触发冲突问题咨询

哇，这种问题确实糟心——用了好几年Git都没碰到过，突然遇到这种无厘头的冲突，还搞丢工作、引入回归，换谁都头大。咱们来一步步排查可能的原因，以及对应的解决办法：

1. 行尾换行符（EOL）不一致导致的隐形冲突 #

这是最常见的“无变更却冲突”的元凶。如果团队里有人用Windows（CRLF），有人用macOS/Linux（LF），Git的自动换行处理可能会在合并时把所有行标记为变更，哪怕内容没改。

• 检查仓库的.gitattributes文件，如果没有就新建一个，添加：

  * text=auto
  

  这个设置会让Git自动转换行尾符，确保仓库里统一存储LF，本地根据系统自动转换。
• 执行git config --global core.autocrlf true（Windows用户）或git config --global core.autocrlf input（macOS/Linux用户），统一本地的换行符处理规则。

2. Git合并策略或配置被意外修改 #

有时候团队成员可能不小心调整了Git的合并配置，导致冲突判定变严格，甚至出现异常行为。

• 先检查全局和仓库级的合并相关配置：

  git config --list | grep merge
  

  重点关注merge.tool、merge.conflictstyle、merge.ours.driver这类配置项，看有没有被改成非默认值。比如如果设置了自定义的合并驱动，很可能会引发问题。
• 若不确定配置是否正常，可以重置为默认合并策略：

  # 重置全局合并工具配置
  git config --global --unset-all merge.tool
  # 恢复默认冲突显示风格
  git config --global merge.conflictstyle merge
  

3. BitBucket服务器端钩子的问题 #

BitBucket的服务器端钩子（比如预合并钩子）如果配置错误，可能会在合并时篡改提交内容，或者误判冲突，导致无意义的冲突提示。

• 联系仓库管理员，检查服务器端的预接收、预合并钩子脚本，看有没有逻辑错误——比如钩子强制修改了文件内容，导致本地提交和远程仓库的版本出现差异。
• 可以先在本地完成合并，推送到一个临时分支，再手动合并到目标分支，测试是否还会出现冲突，以此排除钩子的影响。

4. 分支历史被强制篡改 #

如果有人对已经共享的分支执行了git push --force，会导致分支历史混乱，后续合并时Git无法正确识别公共祖先，从而产生大量无意义冲突。

• 检查分支历史：执行git log --graph --oneline <你的分支名>，看有没有奇怪的历史分叉或强制覆盖的痕迹。
• 规范团队的推送流程：禁止对已共享的分支执行强制推送，除非所有人都知情并同意。如果已经出现历史混乱，可以用git reflog恢复旧的提交，或者重新创建干净的分支。

5. 大文件/二进制文件的干扰 #

Git对二进制文件（比如图片、编译产物）的合并处理本来就很敏感，哪怕是文件时间戳的微小变化都可能触发冲突；大文件也会增加合并时的计算误差。

• 找出仓库里的大文件：用git ls-files --size-sort | tail -10查看最大的几个文件，考虑用Git LFS来管理这类文件。
• 把编译产物、临时文件加入.gitignore，避免它们被提交到仓库，减少不必要的合并冲突。

如果合并时出现工作丢失，很大概率是冲突解决时误删了代码，或者合并后未测试就推送。建议：

• 养成本地合并测试再推送的习惯：

  git checkout 目标分支
  git pull
  git checkout 你的分支
  git merge 目标分支
  # 解决冲突后，务必本地测试代码功能
  git push
  

• 启用BitBucket的合并检查（Merge Checks），要求合并前必须通过CI测试、代码审查，避免未经验证的代码被合并到主分支。

内容的提问来源于stack exchange，提问作者B-Lat