别再只用 add 和 commit 了

说实话，刚入职那会儿我也觉得只要会 git push 和 git pull 就够用了。直到有一次因为没搞清楚分支合并逻辑，把同事正在写的代码给覆盖了，被 Lead 叫过去谈话，才意识到只会基础命令在实际开发流程里有多危险。

在公司团队协作里，我们不仅仅是在写代码，更是在管理代码的历史轨迹。如果你还在机械地用 git merge，可能很快就会发现你的提交历史（Commit History）乱得像一团乱麻。

到底选 git merge 还是 git rebase？

这是很多中级开发者都会纠结的问题。虽然它们的目的都是要把一个分支的改动合并进来，但底层的逻辑完全不同。

• git merge (合并模式)：

当你执行 git merge main 时，Git 会创建一个全新的“合并提交”（Merge Commit）。它会保留完整的开发轨迹：分支从哪儿分出来的、在哪儿又合回来的，一清二楚。
- 优点： 绝对安全，不会破坏历史，真实记录了所有的操作。
- 缺点： 如果团队频繁进行这种操作，你的 Git Graph 会出现大量的交叉线，看起来非常“乱”。

• git rebase (变基模式)：

如果你执行 git rebase main，Git 会把你当前分支的提交“拆下来”，先让分支对齐到 main 的最新位置，然后再把你的提交一个一个重新“贴”上去。
- 优点： 提交历史是一条直线，非常干净，方便 Code Review。
- 缺点： 它在“重写历史”。这也就是为什么我总结了一个避坑指南：

> 避坑准则： 只对你自己正在开发的私有分支用 rebase；千万不要对已经推送到远程、且有其他人在协作的分支用 rebase。

如果你在公共分支上用了 rebase，会导致其他同事的代码历史全部对不上，到时候修冲突的痛苦，真的能让你怀疑人生。

实战中的典型场景

假设你在做 feature 分支，此时 main 分支有了新的更新，这时候该怎么选？

1. 如果你追求极致的提交整洁，且这个 feature 分支只有你一个人在弄，那就用：

git checkout feature-branch
git rebase main

2. 如果你所在的团队对历史记录的完整性有硬性要求，或者你担心操作失误，那就老老实实走合并流程：

git checkout feature-branch
git merge main

我个人的习惯是，在本地开发阶段用 rebase 来保持提交记录的线性，但在准备合并到主干分支（如 develop 或 main）时，尽量遵循团队规定的合并策略。