【git】分支管理

Ne0inhk

22 Mar 2026 — 14 min read

🌈个人主页：秦jh__https://blog.ZEEKLOG.net/qinjh_?spm=1010.2135.3001.5343
🔥 系列专栏：https://blog.ZEEKLOG.net/qinjh_/category_13026221.html?fromshare=blogcolumn&sharetype=blogcolumn&sharerId=13026221&sharerefer=PC&sharesource=qinjh_&sharefrom=from_link

前言

💬 hello! 各位铁子们大家好哇。

今日更新了git分支管理的内容
🎉 欢迎大家关注🔍点赞👍收藏⭐️留言📝

分⽀管理

理解分⽀

分⽀就是科幻电影⾥⾯的平⾏宇宙，当你正在电脑前努⼒学习 C++ 的时候，另⼀个你正在另⼀个平⾏宇宙⾥努⼒学习 JAVA。

如果两个平⾏宇宙互不⼲扰，那对现在的你也没啥影响。不过，在某个时间点，两个平⾏宇宙合并了，结果，你既学会了 C++ ⼜学会了 JAVA！

在版本回退⾥，已经知道，每次提交，Git都把它们串成⼀条时间线，这条时间线就可以理解为是⼀个分⽀。截⽌到⽬前，只有⼀条时间线，在Git⾥，这个分⽀叫主分⽀，即 master 分⽀。

再来理解⼀下HEAD，HEAD 严格来说不是指向提交，⽽是指向master，master才是指向提交的，所以，HEAD 指向的就是当前分⽀。

每次提交，master分⽀都会向前移动⼀步，这样，随着你不断提交，master分⽀的线也越来越⻓,⽽ HEAD只要⼀直指向master分⽀即可指向当前分⽀。

通过查看当前的版本库，我们也能清晰的理出思路

创建分⽀

Git ⽀持我们查看或创建其他分⽀，在这⾥我们来创建第⼀个⾃⼰的分⽀ dev ，对应的命令为：

当我们创建新的分⽀后，Git 新建了⼀个指针叫 dev， * 表⽰当前 HEAD 指向的分⽀是 master 分⽀。另外，可以通过⽬录结构发现，新的 dev 分⽀：

发现⽬前 dev 和 master 指向同⼀个修改。

切换分⽀

使⽤ git checkout 命令即可完成切换

我们发现 HEAD 已经指向了 dev，就表⽰我们已经成功的切换到了 dev 上

在 dev 分⽀下修改 ReadMe ⽂件，并进⾏⼀次提交操作：

dev 分⽀的⼯作完成，我们就可以切换回 master 分⽀。切换回 master 分⽀后，发现ReadMe⽂件中新增的内容不⻅了！赶紧再切回 dev 看看。在 dev 分⽀上，内容还在。

此时查看dev 分⽀和 master 分⽀指向，发现两者指向的提交是不⼀样的

这是因为我们是在dev分⽀上提交的，⽽master分⽀此刻的提交点并没有变，此时的状态如图如下所⽰：

当切换到 master 分⽀之时，HEAD 就指向了 master，当然看不到提交了

合并分⽀

为了在 master 主分⽀上能看到新的提交，就需要将 dev 分⽀合并到 master 分⽀

git merge 命令⽤于合并指定分⽀到当前分⽀。合并后，master 就能看到 dev 分⽀提交的内容了。此时的状态如图如下所⽰。

Fast-forward 代表“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度⾮常快。当然，也不是每次合并都能 Fast-forward。

删除分⽀

合并完成后, dev 分⽀对于我们来说就没⽤了，那么dev分⽀就可以被删除掉，注意如果当前正处于某分⽀下，就不能删除当前分⽀，如：

⽽可以在其他分⽀下删除当前分⽀

此时的状态如图所示：

因为创建、合并和删除分⽀⾮常快，所以Git⿎励你使⽤分⽀完成某个任务，合并后再删掉分⽀，这和直接在master分⽀上⼯作效果是⼀样的，但过程更安全。

合并冲突

在实际分⽀合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。

创建⼀个新的分⽀ dev1 ，并切换⾄⽬标分⽀，我们可以使⽤ git checkout - b dev1 ⼀步完成创建并切换的动作

原本master主分支的文件的内容是aaa，此时我们创建dev1分支，然后修改文件内容为bbb并提交。切换到master主分支，对内容修改为ccc，并提交。

现在， master分支和dev1分⽀各⾃都分别有新的提交，变成了这样：

这种情况下，Git 只能试图把各⾃的修改合并起来，但这种合并就可能会有冲突。

发现 ReadMe ⽂件有冲突后，可以直接查看⽂件内容

Git 会⽤ <<<<<<<，=======，>>>>>> 来标记出不同分⽀的冲突内容。

此时我们必须要⼿动调整冲突代码，把要的留下，不要的删去，并需要再次提交修正后的结果！

到这⾥冲突就解决完成，此时的状态变成了

⽤带参数的 git log也可以看到分⽀的合并情况：

*在这里的绿线上是在dev1分支上，在这里的红线上是在master主分支上。这里的颜色只是用来区分而已。

分⽀管理策略

通常合并分⽀时，如果可能，Git 会采⽤ Fast forward 模式。还记得如果我们采⽤ Fast forward 模式之后，形成的合并结果是什么呢？回顾⼀下

在这种 Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提交到底是 merge 进来的还是正常提交的。

但在合并冲突部分，我们也看到通过解决冲突问题，会再进⾏⼀次新的提交，得到的最终状态为

那么这就不是 Fast forward 模式了，这样的好处是，从分⽀历史上就可以看出分⽀信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分⽀，但依旧能看到 master 其实是由其他分⽀合并得到：

Git ⽀持我们强制禁⽤ Fast forward 模式，那么就会在 merge 时⽣成⼀个新的 commit ，这样，从分⽀历史上就可以看出分⽀信息。

--no-ff 参数，表⽰禁⽤ Fast forward 模式。禁⽤ Fast forward 模式后合并会创建⼀个新的 commit ，所以加上 -m 参数，把描述写进去。

不使⽤ Fast forward 模式，merge后就像这样：

所以在合并分⽀时，加上 --no-ff 参数就可以⽤普通模式合并，合并后的历史有分⽀，能看出来曾经做过合并，⽽ fast forward 合并就看不出来曾经做过合并。

分⽀策略

在实际开发中，我们应该按照⼏个基本原则进⾏分⽀管理：

⾸先，master分⽀应该是⾮常稳定的，也就是仅⽤来发布新版本，平时不能在上⾯⼲活；

那在哪⼲活呢？⼲活都在dev分⽀上，也就是说，dev分⽀是不稳定的，到某个时候，⽐如1.0版本发布时，再把dev分⽀合并到master上，在master分⽀发布1.0版本；

你和你的⼩伙伴们每个⼈都在dev分⽀上⼲活，每个⼈都有⾃⼰的分⽀，时不时地往dev分⽀上合并就可以了。

所以，团队合作的分⽀看起来就像这样：

bug 分⽀

假如我们现在正在 dev2 分⽀上进⾏开发，开发到⼀半，突然发现 master 分⽀上⾯有 bug，需要解决。在Git中，每个 bug 都可以通过⼀个新的临时分⽀来修复，修复后，合并分⽀，然后将临时分⽀删除。

可现在 dev2 的代码在⼯作区中开发了⼀半，还⽆法提交，怎么办？

Git 提供了 git stash 命令，可以将当前的⼯作区信息进⾏储藏，被储藏的内容可以在将来某个时间恢复出来。

⽤ git status 查看⼯作区，就是⼲净的（除⾮有没有被 Git 管理的⽂件），因此可以放⼼地创建分⽀来修复bug。

储藏 dev2 ⼯作区之后，由于我们要基于master分⽀修复 bug，所以需要切回 master 分⽀，再新建临时分⽀来修复 bug，⽰例如下：

修复完成后，切换到 master 分⽀，并完成合并，最后删除 fix_bug 分⽀：

⾄此，bug 的修复⼯作已经做完了，我们还要继续回到 dev2 分⽀进⾏开发。切换回 dev2 分⽀：

⼯作区是⼲净的，刚才的⼯作现场存到哪去了？⽤ git stash list 命令看看：

⼯作现场还在，Git 把 stash 内容存在某个地⽅了，但是需要恢复⼀下，如何恢复现场呢？我们可以使⽤ git stash pop 命令，恢复的同时会把 stash 也删了，⽰例如下：

再次查看的时候，我们已经发现已经没有现场可以恢复了

另外，恢复现场也可以采⽤ git stash apply 恢复，但是恢复后，stash内容并不删除，你需要⽤ git stash drop 来删除；

你可以多次stash，恢复的时候，先⽤ git stash list 查看，然后恢复指定的stash，⽤命令 git stash apply stash@{0}

恢复完代码之后我们便可以继续完成开发，开发完成后便可以进⾏提交：