Git高级工作流

什么时候真正需要这个技能

当 Git 从版本控制工具变成黑盒时，问题就开始了。你可能会遇到这些情况：

• feature 分支上堆了 20 个零碎提交，WIP、fix typo、again 占了一半，合并到 main 前想把历史整理成有意义的原子提交
• 代码里突然出现一个 bug，但没人记得是哪个提交引入的，用肉眼翻 git log 如同大海捞针
• 三个项目共用一套工具函数，想抽成独立仓库却不确定该用 submodule 还是 subtree
• 执行了 git reset --hard 后发现丢了一整天的代码，或者不小心 commit 到了错误的分支

这些问题的共同点是：Git 本身没问题，但操作者对 Git 的理解停留在黑盒层面。

它具体怎么工作

Rebase 交互编辑是整理历史的核心手段。git rebase -i HEAD~5 会打开一个编辑器，让你用 pick、squash、reword、edit、fixup、drop 六种命令重写提交序列。比如把 5 个零碎提交合并成 1 个：

pick a1b2c3d 第一个有意义的提交
squash e4f5g6h fix typo
squash h7i8j9k WIP
squash k0l1m2n again
pick n3o4p5q 第二个有意义的提交

保存退出后，Git 会提示你编辑合并后的 commit message，写一个有意义的摘要即可。

Bisect 二分查找能自动定位 bug 引入的提交。流程是：

1. git bisect start 开始二分
2. git bisect bad HEAD 标记当前版本有问题
3. git bisect good v1.0.0 标记已知正常的版本
4. Git 自动 checkout 到中间版本，你测试后用 git bisect good 或 git bisect bad 反馈结果
5. 重复直到找到第一个有问题的 commit
6. git bisect reset 回到原始位置

对于 submodule 和 subtree 的选择，关键看是否需要修改共享代码。Submodule 是独立仓库的引用，适合外部库和版本锁定；subtree 直接把代码复制进主仓库，适合需要修改共享代码的场景。

灾难恢复依赖 git reflog。它记录了 HEAD 的每一次移动，默认保留 90 天。git reset --hard HEAD@{2} 可以回到前两次操作的状态。误删分支也能通过 git reflog 找到最后一次 commit，然后 git checkout -b <branch> <hash> 重建。

适用边界与注意点

这个技能不适用于基础操作（add、commit、push、pull、branch）和 GitHub/GitLab 的 PR/MR 流程。如果你还在用 git pull 拉取代码，建议先改用 git fetch + git merge，避免冲突时无法回滚。

使用 rebase 前务必先建备份分支：git branch backup/$(date +%s)。Rebase 会重写历史，操作失误可能导致代码丢失。

Submodule 的学习曲线较高，git submodule update --init 是必需的，否则子模块目录是空的。如果团队不熟悉 submodule，subtree 可能是更简单的选择。