【Git】：分支管理

分支管理

一.概念
二.分支管理基本操作
三.分支管理策略
- 1.noff模式
- 2.分支策略

在这里插入图片描述

一.概念

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

在这里插入图片描述

每次提交，master分⽀都会向前移动⼀步，这样，随着你不断提交，master分⽀的线也越来越⻓,⽽HEAD只要⼀直指向master分⽀即可指向当前分⽀。可能到目前为止还很模糊，接下来结合例子一起看。

二.分支管理基本操作

在这里插入图片描述

1. 查看分支

git branch

在这里插入图片描述

目前为止我们只创建了master分支（这是默认创建的），那么前面的*代表什么呢？之前我们的HEAD指针一直指向master，所以当我们进行add操作时是一直向master分支里添加。而HEAD可以指向其它分支，被指向的分支就是当前正在工作的分支。 *出现在master前面就代表master正在工作。

2.创建分支

git branch+name

在这里插入图片描述

接下来看看.git下的变化。

在这里插入图片描述

看到heads下面多出了一个dev，接下来查看它们的内容。

在这里插入图片描述

我们知道master里是最新提交的commit ID，但dev里存的内容竟然与master一样。这是因为我们是基于当前最新提交而建立的分支。

在这里插入图片描述

3.切换工作分支

git checkout +分支名，加上-b选项表示如果没有就创建一个。

在这里插入图片描述

4.进行测试

对ReadMe文件进行修改，并提交。

在这里插入图片描述

接下来切回master分支，再看看ReadMe内容。

在这里插入图片描述

可以看到我们新加的内容没有了。

5.合并分支

用master分支和并dev分支，注意必须切回mater分支。

在这里插入图片描述

仔细观察，可以发现这里打印出了Fast-forward（快速合并），为什么说快速呢？因为它是直接让master指向dev的本次提交，所以快。从这里你可以发现，在本次直接更改master指针没有问题，因为dev并没有对master内容进行修改，只是增加了一行，所以dev相当于向下兼容。如果dev里的数据是aaa，master里的数据是bbb，那么合并时应当保留谁，去除谁呢？

6.分支冲突

进行实验。在dev1分支上让ReadMe增加一行bbb，在master分支上增加一行aaa。

在这里插入图片描述

此时状态master和dev1都进行了提交：

在这里插入图片描述

再次进入ReadMe查看。

在这里插入图片描述

<<<<<到=====之间的代码都是当前分支的代码， ======到>>>>>之间的代码都是dev1分支的代码。这些都是冲突代码，git没办法解决，需要自己手动删除或保留代码。例如想保留bbb代码，那么只需要删除其它代码即可。

在这里插入图片描述

此时还需要再次提交。

在这里插入图片描述

此时状态master和dev1进行了合并：

在这里插入图片描述

这里再介绍一个命令，可以将上面的图打印出来，git log --graph --abbrev-commit。

在这里插入图片描述

7.分支删除

注意要删除某一分支，只能在其它分支上操作，例如我们要删除dev分支，就要在master或者除dev之外的其它分支上执行git branch -d dev。

在这里插入图片描述

三.分支管理策略

1.noff模式

通常合并分⽀时，如果可能，Git会采⽤ Fast forward 模式。在这种 Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提交到底是merge进来的还是正常提交的。但在合并冲突部分，我们也看到通过解决冲突问题，会再进⾏⼀次新的提交。那么这就不是 Fast forward 模式了(一般称为noff模式)，这样的好处是，从分⽀历史上就可以看出分⽀信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分⽀，但依旧能看到master其实是由其他分⽀合并得到。