Git 分支工作流：从单人开发到多人协作

分支的本质

Git 的分支只是一个指向某次提交的可变指针，创建和切换的成本极低（几十字节）。这也是 Git 鼓励频繁分支的原因。

但「成本低」不等于「应该随便开」。分支是协作的边界，它决定了别人在什么时候会看到你的改动。

单人开发：主干直接提交

一个人维护的项目不需要复杂流程。直接在主分支上工作，每次改动一个提交：

git add -A
git commit -m "修复文章分页越界"
git push

唯一要守住的是每次提交都能跑。有了这条底线，就不需要额外分支。

多人协作：短生命周期特性分支

多人时，主分支必须保持随时可发布。做法是每个功能开一个分支：

git switch -c feature/comment-reply
# 开发、提交
git push -u origin feature/comment-reply
# 发起合并请求，评审通过后合入主干

关键约束是分支要短命。一个分支活过三天，冲突概率就会明显上升；活过两周，基本上要重写。

提交的粒度

提交粒度只有一个判断标准：这个提交能不能被单独回滚。

好的提交应该是「一件事 + 一句能读懂的话」。如果写完提交信息发现要用「和」来连接，就该拆开。

分块暂存：最值得养成的习惯

git add -p 让你逐块检查改动再决定要不要暂存：

git add -p
# 对每一块改动回答 y（暂存）/ n（跳过）/ s（再拆分）

这个习惯能挡掉绝大多数「不小心把调试代码提交上去」的事故。

合并还是变基

黄金法则：不要对已经推送、别人可能在用的分支做变基。 变基会重写提交哈希，别人的本地历史会对不上，然后被迫做一次痛苦的修复。

安全的用法是：变基只在自己本地的、还没推送的提交上做。

冲突处理

冲突不是错误，只是 Git 无法替你决定。处理流程：

git merge feature/other
# 打开冲突文件，会看到 <<<<<<< 标记
# 手工编辑成最终想要的样子，删掉标记
git add <冲突文件>
git commit

千万不要无脑选一边。冲突往往说明两边改了同一处逻辑，必须理解两边的意图再决定。

常见误操作与恢复

git reflog 是最后的保险绳。它记录了 HEAD 的所有移动，即使提交已经被「删除」，只要还在对象库里就能找回来。

注意：已被垃圾回收的提交无法恢复，所以误操作后要尽快处理，不要继续做大量操作。

小结

分支工作流没有标准答案，只有取舍：流程越重，主分支越稳，但反馈越慢。

小项目就用主干开发，多人协作就用短生命周期特性分支。守住两条底线——每次提交都能跑、不在共享分支上变基。