Git分支之分支合并冲突、分支管理策略、分支策略

💓博主优快云主页:Am心若依旧💓
 
⏩专栏分类：Git从入门到熟练⏪
 
🚚代码仓库:青酒余成🚚
 
🌹关注我🫵带你学更多的知识
  🔝🔝

🌳前言

本章依然是讲解分支的内容，主要讲解分支里面存在的一些细节。

🌳分支合并冲突

在上一篇文章讲到了创建分支，切换分支，合并分支、删除分支等内容。如果不理解以上概念的话，请移步下篇文章：

代码分支：从 “萌芽” 到 “修剪” 全记录-优快云博客

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

为了演⽰这问题，创建⼀个新的分⽀ dev1 ，并切换⾄⽬标分⽀，我们可以使⽤ git checkout -

b dev1 ⼀步完成创建并切换的动作：

 在 dev1 分⽀下修改 ReadMe ⽂件，更改⽂件内容如下，并进⾏⼀次提交，如：

切换⾄ master 分⽀，观察 ReadMe ⽂件内容:

我们发现，切回来之后，⽂件内容由变成了⽼的版本，这种现象很正常，我们现在也完全能理解。

此时在 master 分⽀上，我们对 ReadMe ⽂件再进⾏⼀次修改，并进⾏提交，如下：

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

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

发现 ReadMe ⽂件有冲突后，可以直接查看⽂件内容，要说的是 Git 会⽤ <<<<<<<，=======，

>>>>>>> 来标记出不同分⽀的冲突内容，如下所⽰：

此时我们必须要⼿动调整冲突代码，并需要再次提交修正后的结果！！（ 再次提交很重要，切勿忘

记）

 

⽤带参数的 git log也可以看到分⽀的合并情况，具体⼤家可以⾃⾏搜索 git log 的⽤法：

最后，不要忘记 dev1 分⽀使⽤完毕后就可以删除了：

🌳分⽀管理策略

通常合并分⽀时，如果可能，Git 会采⽤ Fast forward 模式。还记得如果我们采⽤ Fast

forward 模式之后，形成的合并结果是什么呢？回顾⼀下：

 

在这种 Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提

交到底是 merge 进来的还是正常提交的。

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

 

那么这就不是 Fast forward 模式了，这样的好处是，从分⽀历史上就可以看出分⽀信息。例如我

们现在已经删除了在合并冲突部分创建的 dev1 分⽀，但依旧能看到 master 其实是由其他分⽀合并 得到：

Git ⽀持我们强制禁⽤ Fast forward 模式，那么就会在 merge 时⽣成⼀个新的 commit ，这样，

从分⽀历史上就可以看出分⽀信息。

下⾯我们实战⼀下 --no-ff ⽅式的 git merge 。⾸先，创建新的分⽀ dev2 ，并切换⾄新的分

⽀:

切回 master 分⽀，开始合并:

请注意 --no-ff 参数 ，表⽰禁⽤ Fast forward 模式。禁⽤ Fast forward 模式后合并会创建

⼀个新的 commit ，所以加上 -m 参数，把描述写进去。

合并后，查看分⽀历史：

所以在合并分⽀时，加上 --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}

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

但我们注意到了，修复 bug 的内容，并没有在 dev2 上显⽰。此时的状态图为：

Master 分⽀⽬前最新的提交，是要领先于新建 dev2 时基于的 master 分⽀的提交的，所以我们

在 dev2 中当然看不⻅修复 bug 的相关代码。

我们的最终⽬的是要让 master 合并 dev2 分⽀的，那么正常情况下我们切回 master 分⽀直接合

并即可，但这样其实是有⼀定⻛险的。

是因为在合并分⽀时可能会有冲突，⽽代码冲突需要我们⼿动解决（在 master 上解决）。我们⽆法 保证对于冲突问题可以正确地⼀次性解决掉，因为在实际的项⽬中，代码冲突不只⼀两⾏那么简单， 有可能⼏⼗上百⾏，甚⾄更多，解决的过程中难免⼿误出错，导致错误的代码被合并到 master 上。 此时的状态为

但是这里直接在master上面合并dev2分支，可能就会导致合并发生冲突。所以最好不要直接在master上面直接合并冲突。

解决这个问题的⼀个好的建议就是： 最好在⾃⼰的分⽀上合并下 master ，再让 master 去合并

dev ，这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试，⽽不影响 master 。此时的状态

为：

再用master来合并dev2分支，这样就不会有风险了。

🌳删除临时分⽀

软件开发中，总有⽆穷⽆尽的新的功能要不断添加进来。

添加⼀个新功能时，你肯定不希望因为⼀些实验性质的代码，把主分⽀搞乱了，所以，每添加⼀个新 功能，最好新建⼀个分⽀，我们可以将其称之为 feature 分⽀，在上⾯开发，完成后，合并，最 后，删除该 feature 分⽀。 可是，如果我们今天正在某个 feature 分⽀上开发了⼀半，被产品经理突然叫停，说是要停⽌新功 能的开发。虽然⽩⼲了，但是这个 feature 分⽀还是必须就地销毁，留着⽆⽤了。这时使⽤传统 的 git branch -d 命令删除分⽀的⽅法是不⾏的。演⽰如下：

 当提交完了之后，产品经理把这个功能叫停。切换回master分支看看

直接使⽤传统的删除分⽀的⽅法不⾏，按照提示，有如下方法：

🌳总结

 

分⽀在实际中有什么⽤呢？假设你准备开发⼀个新功能，但是需要两周才能完成，第⼀周你写了50% 的代码，如果⽴刻提交，由于代码还没写完，不完整的代码库会导致别⼈不能⼲活了。如果等代码全 部写完再⼀次提交，⼜存在丢失每天进度的巨⼤⻛险。

现在有了分⽀，就不⽤怕了。你创建了⼀个属于你⾃⼰的分⽀，别⼈看不到，还继续在原来的分⽀上 正常⼯作，⽽你在⾃⼰的分⽀上⼲活，想提交就提交，直到开发完毕后，再⼀次性合并到原来的分⽀ 上，这样，既安全，⼜不影响别⼈⼯作。

并且 Git ⽆论创建、切换和删除分⽀，Git在1秒钟之内就能完成！⽆论你的版本库是1个⽂件还是1万个 ⽂件。