merge

合并

将 merge-and-cleanup 和 merge-to-main 合并为一个流程。默认采用快进合并；无法快进或用户要求时，保留合并提交。删除分支和工作树时始终先征求用户意见。

流程

1. 如果当前已在 main 上，则拒绝操作。 如果 git rev-parse --abbrev-ref HEAD 返回 main（或 master），则停止并报告——无需合并。
2. 工作树必须干净。 如果有未提交的更改，询问用户是提交、暂存还是中止。不要擅自暂存。
3. 记录功能分支名称——FEATURE=$(git rev-parse --abbrev-ref HEAD)。
4. 同步 main。
   • git checkout main
   • git pull --ff-only origin main
5. 先尝试快进合并。
   • git merge --ff-only "$FEATURE"
   • 如果成功，历史记录就是线性的——合并步骤到此完成。
   • 如果失败（分支已分叉），继续执行第 6 步。
6. 回退到合并提交——git merge --no-ff "$FEATURE"。
   • 如果发生冲突，则停止并报告。不要自动解决冲突。
   • 编写有意义的合并提交说明；如果默认说明只是“Merge branch …”，则不要接受。
7. 推送——git push origin main。
8. 交互式清理。 询问用户：“是否删除 $FEATURE（本地和远程）及其关联的任何工作树？”
   • 如果用户回答是：
     • 如果 $FEATURE 有对应的工作树（git worktree list | grep -F "$FEATURE"），先 cd 到主仓库目录，然后执行 git worktree remove <path>。
     • 执行 git branch -d "$FEATURE"（只有在用户明确确认时才使用 -D——如果分支尚未合并，-d 会拒绝删除；这正是我们需要的安全保障）。
     • 执行 git push origin --delete "$FEATURE"（如果分支从未推送过，则忽略失败）。
   • 如果用户回答否：保留所有内容。
9. 报告最终状态——main 上的提交哈希、分支是否已删除、工作树是否已移除。

注意事项

• 优先采用 ff-only。 线性历史更容易理解。只有在分支确实已分叉时才回退到合并提交。
• 绝不使用 --no-verify。 如果预推送钩子失败，请修复根本问题，不要绕过。
• 先清理工作树。 如果功能分支是在工作树中开发的，就不能在该工作树内删除分支。务必先 cd 到主仓库工作目录。
• 冲突处理策略。 此技能不会自动解决冲突。如果 git merge 报告冲突，则停止并告知用户，由用户决定如何处理。

易忽略的问题

• 如果 main 在本地已分叉（例如直接在 main 上提交过），在 main 上执行 git pull --ff-only 会失败。这是另一个问题——如实告知用户，不要用 --rebase 掩盖。
• git branch -d 会拒绝删除尚未合并的分支。这是安全保障——绝不要自动改用 -D。
• 如果远程分支不存在，git push origin --delete 会以非零状态退出。在此流程中这没关系（该分支仅存在于本地）——记录并继续。
• macOS 不区分大小写的文件系统可能掩盖仅大小写不同的冲突；如果功能分支与另一个分支只有大小写之差，git checkout 的结果可能出乎意料。