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 。此时的状态

解决完冲突再合并：

?

?

小结：

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

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