第02章：AI帮我解决了merge conflict，但搞乱了commit history

第02章：AI帮我解决了merge conflict，但搞乱了commit history

“你把 merge conflict 贴给 AI，AI 帮你解决了——但 AI 不知道你的团队约定是 rebase 还是 merge，不知道你的 main 分支需要 linear history，也不知道它帮你做的 merge 会产生一个丑陋的 ‘Merge branch dev into feature/login’ commit。”

ℹ️ 版本说明：本章基于 Git 2.54.0。

2.1 AI默认会生成什么

你遇到 merge conflict，AI 通常给你这样的步骤：

git fetch origin
git merge origin/main
# 解决 conflict 后
git add .
git commit -m "fix conflicts"

这会产生：

  1. 一个 merge commit（“Merge branch ‘main’ into feature/login”）
  2. 如果解决了很多 conflict，commit 里可能包含混杂的变更
  3. main 分支的 commit history 变成非线性的（有分叉和合并节点）

2.2 AI通常遗漏的4个坑

⚠️ 坑1：merge 和 rebase 的选择没有规范

# 方式1：merge（默认）
git merge origin/main
# 产生 merge commit，history 是非线性的
# 优点：保留完整的分支历史，安全
# 缺点：git log 很乱，有大量 "Merge branch..." commit

# 方式2：rebase（更干净，但有风险）
git rebase origin/main
# 重写 commit hash，history 是线性的
# 优点：git log 清晰，每个 commit 都有意义
# 缺点：如果分支已经 push 了，rebase 后 force push 会影响队友

大多数现代团队的约定是：feature 分支上用 rebase 同步 main，合入 main 时用 squash merge（把整个 feature 压缩为1个 commit）。

⚠️ 坑2：rebase 冲突比 merge 冲突多

如果你的 feature 分支比较旧，分叉点很远，rebase 时每个 commit 都可能有冲突，要逐个解决：

git rebase origin/main
# 遇到冲突
# 修复冲突
git add .
git rebase --continue
# 又遇到冲突...
# 修复冲突
git add .
git rebase --continue
# 重复 N 次

如果感觉 rebase 陷入泥潭，可以放弃：

git rebase --abort  # 恢复到 rebase 之前的状态

⚠️ 坑3：解决 conflict 后 commit message 混乱

AI 通常让你用 git commit -m "fix conflicts" 来提交解决冲突的结果。但这不够：

  • 是什么 conflict？（同一行被两个人修改，还是同一文件有删改）
  • 你选择了哪个版本？为什么？
  • 如果冲突在关键业务逻辑里，3个月后没人知道为什么选了这个版本

正确做法：解决冲突时在 commit body 里说明你的选择：

fix(auth): resolve merge conflict in token validation

Kept origin/main version of validateToken() which adds
expiry check. The feature branch version was missing this.

This change may affect existing sessions - users with
tokens over 24h will be logged out.

⚠️ 坑4：不会用 git rerere 避免重复解决同一冲突

如果你在长期维护一个分支，需要多次和 main 同步，你会反复遇到同样的冲突。

git rerere（Reuse Recorded Resolution）可以记住你的冲突解决方法，下次遇到同样的冲突自动应用：

# 全局开启 rerere
git config --global rerere.enabled true

# 解决一次 conflict 后，rerere 会记录解决方法
# 下次遇到相同 conflict，自动应用

2.3 更好的提示词

提示词 P01：选择合适的 conflict 解决策略

使用时机：遇到 merge conflict 时，先让 AI 分析情况再决定怎么做

比默认多了什么：

  • 判断用 merge 还是 rebase
  • 处理前后的步骤完整
我遇到了 Git merge conflict，帮我分析并给出最佳处理策略。

当前情况：
- 当前分支：[feature/login]
- 目标分支：[main / develop]
- 分支是否已经推送到远程？[是/否]
- 是否有其他人在用这个分支？[是/否]
- 冲突文件数量：[N 个]
- 团队规范：[rebase 优先 / merge 优先 / 不清楚]

帮我决策：
1. 这种情况下该用 merge 还是 rebase？（说明理由）
2. 完整的操作命令序列（包括处理冲突前后的所有步骤）
3. 如果处理失败，如何安全退出（abort 命令）？
4. 处理完成后，如何验证 conflict 全部正确解决？

冲突文件内容（如果有需要分析的具体冲突）：
[粘贴 conflict 内容]

基于 Git 2.54.0。

提示词 P02：分析具体冲突内容并给出推荐解法

使用时机：不知道 conflict 该保留哪个版本时

比默认多了什么：

  • AI 分析两个版本的语义
  • 给出推荐选择和理由
帮我分析以下 Git merge conflict，给出推荐的解决方案。

冲突内容（完整的 conflict 标记）：
<<<<<<< HEAD
[你当前分支的代码]
=======
[要合入的代码]
>>>>>>> origin/main

背景信息：
- 这是什么功能的代码？[描述]
- 两个版本分别是谁写的/什么时间做的修改？[如果知道]
- 最终目标是什么？[描述预期行为]

帮我：
1. 解释两个版本的区别（语义层面，不只是代码差异）
2. 推荐保留哪个版本（或如何合并两个版本的改动）
3. 给出解决后的代码（可直接粘贴）
4. 这个决策的理由（让我能在 commit message 里解释清楚）

基于 Git 2.54.0。

提示词 P03：设置团队 Git 合并工作流规范

使用时机：为团队建立统一的 merge/rebase 规范

比默认多了什么：

  • 完整的工作流选择决策
  • GitHub Branch Protection 配置
帮我为一个5-10人的开发团队制定 Git 合并工作流规范。

团队情况：
- 主分支：main（保护分支）
- 开发分支：develop（集成分支）
- 功能分支：feature/* （每人一个）
- 发版分支：release/*
- CI/CD：GitHub Actions

我需要决定：

1. Feature 分支如何同步 main 的最新代码？
   - 选项A：rebase（线性历史，但需要 force push）
   - 选项B：merge（非线性但安全）
   - 推荐哪个？给出理由

2. Feature 分支合入 main 时的策略：
   - squash merge（把 feature 所有 commit 压缩为1个）
   - merge commit（保留分支历史）
   - rebase merge（线性历史，保留每个 commit）
   - 推荐哪个？给出理由

3. GitHub Branch Protection 配置（给我 Settings 里的截图描述或 GitHub API 配置）：
   - main 分支需要保护哪些行为？
   - PR 要求几个 reviewer approve？
   - 要求 CI 通过才能合并？

4. 给我一份团队 Git 工作流文档（Markdown 格式，放在 CONTRIBUTING.md 里）

基于 Git 2.54.0 + GitHub。

2.4 验收清单

检查项 验证方法 AI辅助
团队有明确的 merge/rebase 规范 CONTRIBUTING.md 里有说明 用 P03 生成文档
main 分支有 Branch Protection GitHub Settings 里配置了保护规则 用 P03 配置
conflict 解决有记录 commit message 里说明了选择理由 用 P02 分析 conflict
rerere 已配置 git config --global rerere.enabled true 让 AI 配置 rerere
没有孤立的 “fix conflicts” commit git log 里无无意义的 merge commit 用 squash merge
force push 有保护 main 分支禁止 force push 让 AI 检查 GitHub 设置

2.5 本章小结

如果你只记一件事：feature 分支上用 git rebase origin/main 而不是 git merge origin/main 来同步最新代码。rebase 让你的 feature 分支的基点变成 main 的最新 commit，合入时不会产生 merge commit，history 保持线性。

Conflict 处理的三个层次：

  1. 能解决（AI 帮你找到 conflict，手动选一个版本）：conflict 消失了，但可能选错了版本
  2. 会分析（理解两个版本的语义，做出有根据的选择）：选择有理由，能在 commit 里说清楚
  3. 有规范（团队统一 merge/rebase 策略，GitHub 保护主分支）：conflict 更少，history 更干净

→ 第3章：AI生成了 .gitignore，但我的 API 密钥还是提交进去了