Git 进阶：如何保持 Dev 分支的“线性提交”历史？

在团队协作中，你是否经常看到 Git Graph 像织毛衣一样，布满了密密麻麻的交叉线和“Merge branch ‘dev’ of…”的冗余节点？要让 dev 分支保持为一条没有任何分叉的直线（Linear History），核心要点在于：永远不要在 dev 分支上直接使用 git merge 来同步代码。我们需要把 dev 看作是一条“单行道”，所有的代码进入 dev 之前，都必须在自己的分支上先排好队。

1. 核心逻辑：Rebase（变基）优先

分叉产生的根本原因是：本地开发进度与远程服务器进度在不同的时间点上“各走各的”，最后用 merge 强行拉在一起。Rebase 的本质： 让你本地的修改“原地起跳”，重新落在远程最新的提交之后。

2. 每日实战流程（保姆级步骤）

假设你当前在功能分支 suite 上开发，目标是将其整洁地合入 dev。

第一步：同步远程主干

在准备提交代码前，先获取远程 dev 的最新动态，但不要执行合并：

git fetch origin

第二步：在功能分支执行变基

这是最关键的一步。它会把你 suite 上的提交临时取下来，把远程 dev 的新内容补在下面，再把你的提交一个一个接上去：

git checkout suite
git rebase origin/dev
git push -f origin suite

💡 如果遇到冲突（Conflict）：修改冲突文件 -> git add 。执行 git rebase —continue（注意：不要执行 commit）。如果想放弃本次 rebase，执行 git rebase —abort。

第三步：快进式合并到 dev

此时你的 suite 分支已经包含了 dev 的所有内容，且你的提交整齐地排在最前面。回到 dev 分支：

git checkout dev
git merge suite --ff-only

注：—ff-only 确保如果不能走直线就报错，防止误操作产生分叉。

第四步：推送

git push origin dev

3. 避坑指南：为什么大家做不到“无分叉”？

如果你发现 Graph 里还是有小气泡，通常是因为以下两个原因：

🚫 不要直接使用 git pull

默认的 git pull 等同于 fetch + merge。只要本地和远程都有提交，pull 一次就会产生一个分叉点。解决方案： 统一使用 git pull —rebase。

✅ 配置全局 Rebase（一劳永逸）

你可以通过以下配置，让以后所有的 pull 操作默认都走直线：

git config --global pull.rebase true

4. 总结：线性开发“三不”原则

原则	具体做法	目的
不在主分支开发	永远在 feature 或 suite 等功能分支写代码	保证 dev 随时是干净的
不直接使用 Merge	使用 rebase 来同步上游更新	消除合并产生的“小气泡”节点
不强行合并	提交前必须先 rebase origin/dev	确保本地提交永远在远程进度之后

🌟 这样做的好处

• 极速定位 Bug： 当 dev 是一条直线时，你可以通过 git bisect 快速二分法定位是哪次提交引入了问题。
• 可读性极高： 整个团队的历史记录像一本按时间顺序编写的书，而非一团乱麻。
• 回滚安全： 撤销操作变得非常简单，不会因为复杂的合并关系导致代码丢失。