开发分支与公共分支Rebase流程

如果不使用 MR，而是你自己负责把 feature 合并到 dev，那推荐流程如下。

假设：

• 公共分支：dev
• 个人分支：feature

---

推荐流程（Rebase + Merge）

第一步：更新 dev

git checkout dev
git pull origin dev

保证你的 dev 是最新的。

---

第二步：切回 feature

git checkout feature

---

第三步：Rebase 到最新 dev

git rebase dev

如果有冲突：

git add .
git rebase --continue

完成后：

A──B──C──D (dev)
          \
           E'──F' (feature)

这里只修改了 feature，dev 没有任何变化。

---

第四步：切回 dev

git checkout dev

---

第五步：合并 feature

推荐：

git merge --ff-only feature

如果可以快进（Fast Forward），结果就是：

A──B──C──D──E'──F'
                ↑
              dev

没有 Merge Commit。

最后：

git push origin dev

---

为什么推荐 --ff-only？

因为经过 Rebase 后，feature 已经是基于最新 dev 的：

dev

A──B──C──D

feature

A──B──C──D──E'──F'

Git 不需要创建 Merge Commit，只需要把 dev 指针向前移动：

A──B──C──D──E'──F'

历史非常干净。

---

如果 --ff-only 失败

例如：

git merge --ff-only feature

提示：

fatal: Not possible to fast-forward, aborting.

说明在你 Rebase 完成之后，又有人往 dev 提交了代码。

例如：

dev

A──B──C──D──G

feature

A──B──C──D──E'──F'

这时不要强行 Merge，而是：

git checkout feature
git rebase dev

重新基于最新的 dev。

---

不推荐的流程

很多人会这样做：

git checkout dev
git merge feature

如果 feature 没有先 Rebase，就容易得到：

A──B──C──D
 \       \
  E──F────M

会产生很多 Merge Commit，时间长了历史会比较杂乱。

---

我推荐的完整流程

 

# 更新公共分支
git checkout dev
git pull origin dev

# 更新自己的分支
git checkout feature
git rebase dev

# 如果 feature 已推送到远程，需要更新远程
git push --force-with-lease

# 合并到公共分支
git checkout dev
git merge --ff-only feature

# 推送公共分支
git push origin dev

 

---

这套流程的优点

• dev 的提交历史保持线性，没有额外的 Merge Commit。
• feature 始终基于最新的 dev。
• 冲突会在 Rebase 时解决，而不是合并到 dev 时才暴露。
• 即使没有 MR，这也是很多团队采用的手动集成流程。

需要注意一点：如果 dev 是多人协作的公共分支，在你执行 git push origin dev 前，最好再执行一次：

git pull --ff-only origin dev

确认没有人在你合并期间又更新了 dev，这样可以避免把过时的本地状态推送到远程。