Git分支管理

愿所有美好如期而遇

---

目录

理解分支

创建分支

切换分支

合并分支

删除分支

合并冲突

分支管理策略

---

理解分支

每次提交master都会前进一步，随着不断提交，master分支的线越来越长，而HEAD指向哪条分支就是当前工作的分支。

master分支是我们创建本地仓库时系统默认创建的分支。

创建分支

git branch 查看当前所有分支

这个*表示HEAD指向的分支，也就是我们当前工作的分支

git branch name 创建一个新的分支

 我们发现新建的dev分支与master分支都指向最新的提交

切换分支

那么如何切换到dev分支下进行开发呢?

git checkout 分支名字

现在我们在这个分支下对文件进行修改，添加一句话“分支dev”

 添加并提交

现在我们切换回master分支，看看master分支有没有被影响。

没有受到任何影响，我们再来看他们的指向

发现指向已经不同了。

我们要想在master分支上看见dev上的提交怎么办呢？--->合并分支

合并分支

为了能在master分支上看见dev分支上的提交，我们需要将dev分支合并到master分支上。

git merge 分支名

需要注意的是，要将dev分支合并到master分支上，需要先切换到master分支上 。

Fast-forward模式，快进模式，合并时，master直接指向dev的当前提交

我们还可以来看看他的视图。

当然，也不是每次合并时都能使用快进模式，我们后面会说到其他的合并方式。

删除分支

在我们合并了dev分支后，dev分支也就没用了，所以我们删掉他

git branch -d 分支名字

我们已经完成了合并，所以此时删除分支时可以的。

合并冲突

在实际分支合并时，并不是每次都能合并成功的，有时候会遇到代码冲突的问题

我们创建一个新的分支并切换至该分支

git checkout -b 新的分支名字   一条指令一步到位

再切换至master分支做修改。

两个分支都对原有旧版本代码做了修改并提交，现在我们将newdev与master合并

这些符号之间的代码就是冲突的代码，我们只能手动去除冲突，保留一个

再次添加提交

我们此时的模式是--no -ff，也就是非快进模式

接着，我们删除分支

分支管理策略

通常我们合并分支时，如果可能，编译器通常会采用fast-forward模式，合并后结果是这样

master直接指向dev指向的最新提交。

但在合并冲突部分，我们也看到通过解决冲突问题，会在进行一次添加提交，得到的最终状态是：

这样的好处是，从分支历史上就可以看出分支信息。

我们已经删除了dev和newdev分支，但是我们仍然可以看到他们的过往信息，尽管我们删除了newdev分支，但是我们仍然可以看到现在的master分支是由其他分支合并而得到的。

编译器支持我们强制禁用fast-forward模式，那么在merge时会生成一个新的commit，这样我们就可以从分支历史上看出分支信息。、

我们再次新建一个分支测试--no -ff模式的合并

别忘了切换到master分支

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