Git分支管理

 

理解分支

本章开始介绍Git的杀手功能之一：分支。分支就像一种平行宇宙发生的事情，你在学习C++知识的时候，另一个世界的你可能在偷摸学JAVA。

如果两个平行宇宙互不干扰，那么对于你当然没有影响，但如果哪天你们要合体了了的话，你就又学会了 C++和JAVA

在版本的回退里，每次提交，Git都把他们穿成一条时间线，这条时间线就可以理解为是一个分支。截止到目前，在Git中，这个分支叫主分支，也是master

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

 

每次提交，master就会向前移动一步，这样随着不断提交，master分支的线就越来越长，而HEAD只要一直指向master分支即可指向当前分支 

 

---

创建分支

Git允许我们查看或创建其他分支，在这里我们来创建一个自己的分支dev：

• 查看当前本地所有分支 git branch
• 新建分支 git branch [分支名] 

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

目前dev和master指向同一个修改。 

一张图总结：

 

切换分支： 

 那如何切换到dev分⽀下进⾏开发呢？使⽤? git checkout ?命令即可完成切换，⽰例如下：

git checkout dev

 

此时提交线为：

 git branch显示我们在dev分支下工作：

此时我们在dev分支下创建一个文件newfile 并add 和 commit 一下：

 

但当我们切回master分支后，这个文件竟然离奇消失了~~

 

 在dev分支上创建的内容，竟然在master分支上看不到。为什么会出现这个现象？

我们来看一下master分支的指向，发现两者指向不一样的~~

很明显这时候dev和master指向的并不是同一个版本了，此时的状态如下图：

当我们切换到master分支的时候，HEAD就指向了master，那就看不到提交了！！

---

合并分支 

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

• git merge dev 合并dev分支 

 要合并dev分支首先我们就不能在dev分支上：先git checkout master上后merge

此时我们就能在master分支上看到newfile了

git merge用于合并指定分支到当前分支。合并后，master就能看到dev分支提交的内容了。此时的状态如下图：

 

---

删除分支 

合并完成后，dev分支对我们说就没有作用了，那么dev分支就可以被删除掉，注意如果当前处于某分支下就不能删除当前分支，即不能删除当前所在分支：

• git branch -d dev 

 就能够完成对dev分支的删除，值得说的是，如果想要删除的分支已经提交过且尚未合并，那么git会认为当前分支对你有作用，上面的删除方式是不行的

• git branch -D dev 

 这个即是强制删除分支，尽管他已经commit过且尚未merge

 

 

合并冲突： 

在实际分支合并的时候，并不是想合并就合并成功的，大概率会遇到代码冲突问题：例如上面的平行宇宙例子：宇宙a中你认为最好吃的是汉堡，宇宙b中的你认为可乐是最好的，那么你们合并的时候就会对“最好吃的事物”产生冲突，此时就需要手动处理一下~~

为了演⽰这问题，创建⼀个新的分⽀? dev1 ，并切换⾄⽬标分⽀，我们可以使⽤? git checkout -
b dev1 ⼀步完成创建并切换的动作，⽰例如下：

 对dev1修改ReadMe文件：

对master修改ReadMe文件：

 

此时的提交图；

 

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

 

此时的ReadMe文件变成这样：

 

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

 

 

 

git log也可以看分支的合并情况，具体可以搜索git log的用法：

• git log --graph --pretty=oneline --abbrev-commit 

 

最后别忘记删除一下dev1 分支：git branch -d dev1

---

分支管理策略 

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

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

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

 

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

Git支持我们禁用Fast forward模式，那么就会在merge时生成一个新的commit，这样从分支历史上就能看到历史的分支信息

• --no-ff方式的git merge 

 即在merge的时候加上--no-ff ,这里的ff就是Fast forward的缩写

• git merge --no-ff -m "xxx" [dev.name]  

 这样就可以在合并的时候禁用Fast forward

 分支策略：

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

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

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

团队合作的时候就像下面这样：

 

BUG分支： 

假如我们现在正在? dev2 ?分⽀上进⾏开发，开发到⼀半，突然发现 master 分⽀上⾯有?bug，需要解决。在Git中，每个?bug?都可以通过⼀个新的临时分⽀来修复，修复后，合并分⽀，然后将临时分⽀删除。
可现在? dev2 ?的代码在⼯作区中开发了⼀半，还⽆法提交，怎么办？

Git提供了一个git stash 的命令，即在当前工作区写的东西还不够提交的时候，可以使用这个指令将当前工作区信息进行储藏， 被储藏的内容可以在将来某个时间恢复出来

• git stash 保存现场
• git stash pop 恢复现场，并删除stash内容(一般用这个就行，stash内容一般不会再恢复一次)
• git stash apply 恢复现场
• git stash drop 删除stach内容

也可以用恢复指定的stash,用git stash list查看 , 用那个git stash apply stash@{0} 指定恢复

此时就可以创建一个fix_bug分支修改bug后合并到master上，最后再删除fix_bug：具体操作方法和上面一样，唯一要注意的一点是，在上面我们说了master只能发布稳定版本，所以如果要merge到master上的代码绝对不能有问题。 

解决这个问题的⼀个好的建议就是：最好在⾃⼰的分⽀上合并下 master ，再让 master 去合并
dev ，这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试，⽽不影响 master 。此时的状态

解决完冲突再合并：

 

 

小结：

分支在实际当中有什么用呢？比如你要开发一个新功能，但是需要一星期完成，前两天你写了一半的代码，如果立刻提交，由于代码没写完，不完整的代码库会导致别人都干不了活了。如果等代码全部写完再一次提交会有丢失进度的风险。

有了分支你就不用怕，在自己的分支干活，别人看不到，也不影响别人，你在自己的分支想提交就提交，想回退就回退，直到开发完成后再一次性合并进去即可，这样又安全又不影响其他人工作