✍️记录自己的git分支管理经验

feature/phase_2 已经把我在 feature/phase_2_devjjq 上的所有改动收进来了，提交历史也没有多出来那种一看就烦人的合并节点。接下来把过程说清楚，步骤和那些容易踩坑的地方都写明了，想按我这套走的人照着做就行。

简单结论先放这儿，按我最后做的顺序来：

– 更新远端引用：git fetch origin

– 把我的开发分支切到最新的 feature 基线上做变基：git checkout feature/phase_2_devjjq; git rebase origin/feature/phase_2

– 处理可能出现的冲突：按提示逐个解决，git add 文件；冲突解决后 git rebase –continue；出问题就 git rebase –abort

– 切回 feature 分支做快进合并：git checkout feature/phase_2; git merge –ff-only feature/phase_2_devjjq

– 推送到远端：git push origin feature/phase_2

– 如果需要把个人分支也更新远端：git checkout feature/phase_2_devjjq; git push –force-with-lease origin feature/phase_2_devjjq

这套流程的关键在变基那步。把自己做的提交“搬”到远端最新的 feature/phase_2 上去，合并的时候就能走快进，不会生成额外的 merge commit，提交树看着干净，审查也舒服。变基时遇到冲突按常规解决，不要把变基在公共分支上乱用就好。下面我把每一步按顺序展开说清楚，谁按着做都能复刻。

先交代背景。我们仓库主线叫 master，按阶段把开发分成 feature/phase_1、feature/phase_2、feature/phase_3 这种。个人开发一般在对应阶段下再建自己的分支。我叫江建清，个人分支名叫 feature/phase_2_devjjq。团队里大家都往 feature/phase_2 上合小改动，我在个人分支上做了不少功能，目前要把这些改回去，让主线能用到我的工作成果。

为什么不用最直观的 merge 流程？我以前是那样干的，过程直观但历史会多出合并节点。那套流程大致是：

– git checkout feature/phase_2

– git pull origin feature/phase_2

– git merge –no-ff feature/phase_2_devjjq

– git push origin feature/phase_2

这个做法没错，能把改动合并上去，但缺点明显：每次合并都会在历史上留下一笔 merge commit。如果频繁同步，提交记录就变得杂乱，回头查问题要翻许多页。碰到多人并行改同一模块时，短小的 merge 节点堆积，审查和追踪改动都不舒服。我就是被这种历史搞烦了，于是换成了变基+快进的做法。

下面正式讲操作细节，按实际操作的顺序来写，注意那些容易被忽视的小点：

1) 抓远端最新引用

先更新远端引用，不要直接用本地可能过时的分支做变基：

git fetch origin

这一步只刷新 origin/feature/phase_2 的引用，不会动你的工作树。比起直接 git pull，少了自动合并的灰色地带，更安全。

2) 在个人分支上变基

切到自己的分支：

git checkout feature/phase_2_devjjq

把我在个人分支上的提交，按顺序重放到远端最新的 feature 分支之后：

git rebase origin/feature/phase_2

这一步会一条一条把你的提交“搬家”过去。过程中如果有人在 feature/phase_2 上改了你也改的地方，git 会停下来报冲突，提示哪个文件需要你处理。

3) 遇到冲突怎么干

碰到冲突先别紧张，按提示打开冲突文件，按项目实际需要把冲突部分修好。常用流程是：

– 编辑冲突文件，把想要保留的代码整理好

– git add <冲突文件>

– git rebase –continue

如果发现处理错了，想回到变基前的样子，就用：

git rebase –abort

变基会改历史，处理冲突时尽量不要把半成品提交上去。每次冲突解决后都要确认本地测试通过再继续，别把不完整的改动往后面“带”。

4) 本地检查

变基结束后，用几条命令确认提交和代码状态：

git log –oneline –graph

git status

看清楚提交顺序和当前工作树是否干净。需要的话跑下单元测试或本地编译，确保变基没有把错误带进来。

5) 快进合并到 feature/phase_2

确认没问题后，切回 feature 分支，做快进合并：

git checkout feature/phase_2

git merge –ff-only feature/phase_2_devjjq

加上 –ff-only 是为了保证合并不会产生额外的 merge commit。如果由于远端有新提交导致无法快进，命令会失败，这时说明你需要先抓最新的远端再处理，或者再把变基做一次。

6) 推送到远端

把 feature 分支推上去：

git push origin feature/phase_2

如果别人也在同时往 feature/phase_2 推新东西，push 可能被拒绝。遇到这种情况别硬推，先 fetch 看差异，协商或者再做一次变基。

7) 个人分支如何同步到远端

变基会重写你个人分支的历史，如果远端也有同名分支，需要强推，但别用 blind force，推荐：

git checkout feature/phase_2_devjjq

git push –force-with-lease origin feature/phase_2_devjjq

这个推法比直接 –force 更谨慎，会在远端有别人新提交时给你警告，不会盲目覆盖别人的工作。前提是你确认没有别人基于你这个分支继续开发。

几个实务层面的提醒

– 变基会改历史，只对自己独占的分支做，别在公共分支上乱变基。我是在自己的 feature/phase_2_devjjq 做变基，把修改重放到 origin/feature/phase_2，然后用快进合并把成果合到团队分支，这样不会改写共享分支的历史。

– 如果在变基时频繁碰到冲突，往往说明你和别人改动太接近，沟通比死磕冲突更省力。有时先在 feature 分支上把别人的改动合并下来，再把工作整理到自己分支，反而更顺。

– 常用命令 git status、git log、git reflog 很重大。万一操作失误，reflog 可以帮你找回变基前的状态。提议在动历史之前，先备份一个临时分支名，列如：

git branch feature/phase_2_devjjq_backup

这样出问题还能回到备份。

– 合并策略最好团队统一。有人喜爱保留所有 merge commit，觉得能看出分支合并的脉络；我这边偏好线性历史，review 时更顺手。两种都行，关键是全队达成一致。

再补一条个人经验：把自己的提交整理得清楚一点再变基，合并时会少许多麻烦。把零散的“试验性”提交合并成逻辑清晰的提交，既有助于代码审查，也能降低冲突概率。变基不是万能的，工具就是工具，目标是让历史更好看、协作更顺畅。

我以前写过更细致的 rebase 文章，里面对一些复杂情形有更深入的说明。最后提醒一句，变基后推个人分支要带 –force-with-lease，这一步别省。