Git三大特色之Branch(分支)

傷城~ 2022-06-06 01:28 204阅读 0赞

# 我习惯每篇博客都有个开篇 #

还记得 Git 系列第一篇 [Git 自我介绍][Git]的话吗？其中有 Git 自己都赞同的三大特色

> cheap local branching, convenient staging areas, and multiple workflows

轻量的本地分支, 方便的暂存，以及多工作流。其中因为有分支的存在，才构成了多工作流的特色，所以 Branch 不愧为 Git 的王牌特色。这篇博客，主要和大家一起学习一下轻若鸿毛，帅到炸裂的分支儿。

# Branch 的概念 #

分支的概念，在我看来，分两个版本：

**从使用场景上解释，是这么个概念**

Git 的分支，就是开发过程中，要选择的一条路，你可以选择和其他小伙伴一起走同一条路，也可以自己走一条路，路与路之间相互没有影响，作为路的主人，你也随时可以让两条路合并。

![简笔画 Git 分支][Git 1]

**深入一点的话，是这么个概念**：

Git 的分支，其实本质上仅仅是指向提交对象的可变指针，这个可变指针，指向路的终点。同时，还有一个比较特别的 HEAD 指针，用于记录当前工作的位置，借用上面的例子，这个 HEAD 指针等于在路上走的你自己，你在哪，指针就在哪，你在哪个分支，HEAD 指针就指向哪个分支的指针。  
![深层次的分支概念图][7251bd4d7b1af4aaaa3ffaf9ed004c48.png]

实际上，当我们使用 Git 的时候，我们就使用了分支，因为 Git 的默认分支名字是 master，如果你有心的话，会发现执行 `git init`后，命令行的输出头部已经默认在 master 分支了。 但是这个时候，还并未创建 master 分支，只有当有一个提交的时候，才会创建 master 分支。原因在于，分支的指针要指向提交的呀，突然明白了，当初看 Android Studio 的教程，为什么每个都让有一个初步提交了呢。

无图无真相，不信的看下面:

![git 默认分支 master][git _ master]

# 玩转 Branch 必备技能 #

有关分支的命令不多，无非是换着花样的增删改查，掌握好以下基本的命令，以后就可以在 Branch 的草原上策马奔腾潇潇洒洒啦

### 创建分支 ###

git branch <name>

这个命令看起来，似乎简单到你只需要想个分支的名字就好了。  
但是在创建分支的时候，要想下，是否要从当前分支的内容基础上去开辟一条新分支。

### 查看分支 ###

三个命令，让你想看什么分支就看什么分支，就是这么方便

git branch //查看本地分支
     git branch -r //查看远程分支
     git branch -a //查看本地和远程的所有分支

### 删除分支 ###

当本地分支删除后，推动到远程仓库后，远程仓库并不能自动删除远程分支（原因，下回分解）。所以，分支的完全删除是分两个部分的，一个是本地，一个是远程。

本地删除操作需要加上 `-d`或者 `-D` 参数，参数的名称来自英语 `delete`的缩写，Remember it so easy!

两者的区别在于`-D`比`-d`要粗暴一点。当被删除分支有新内容没有被合并的时候，使用`-D`，会直接删除， 使用`-d`，会提示该分支有新内容没有被合并，不执行删除。删除需谨慎，建议非特殊情况下，使用温柔的`-d`要好一点，以免小手一抖，眼泪长流。

git branch -d <name>
     git branch -D <name> //强制删除

删除远程分支需要 push 操作。

git push origin :<name>

### 重命名分支 ###

其实，这是个伪命题。

但是有很多人，包括我，都有过对分支名称不满意想该修改一下的想法，所以，就有了这个伪命题的存在。

事实上，分支不存在重命名，没有 rename 的这个命令。如果你起的名字不满意，想重新起的话，那只要创建一个和要修改分支内容一样的分支，起上你喜欢的名字，然后再把之前的给删掉。

### 检出分支 ###

这个检出分支的“检出”二字，算是个关于 Git 分支的专业术语了,你可以理解为切换当前分支。  
本质上， checkout 操作是移动 HEAD 指针，将 HEAD 指针指向要切换的分支的指针处。

使用场景有两个：

1.  已经存在的分支，现在要切换过去。

git checkout <name>

1.  创建一个新分支，并切换到新分支，这个一步到位的话需要 `-b` 参数。
    
    以当前分支为基础，创建一个新分支
    
        git checkout -b <branch name>
    
    以指定的某一个提交，创建一个新分支
    
        git checkout -b <branch name> <SHA1>

### 合并分支 ###

以上，是分支的增删改查独立操作，但是 Git 创造这个分支，并不只是为了让它们自个儿和自个儿玩的，还需要它们之间的相互协作和配合。 就像写项目的时候，分好开发任务，你和你的小伙伴新建了两个分支，你写你的 Anglela，他写他的 baby,到开发完成之后，肯定要合在一起，才能成就 Anglelababy。合的这个动作，就涉及到了分支合并的概念。

分支合并使用到的命令是

git merge <branch name>

分支合并相对分支的其他操作，是相对要复杂一点的，怎么说也是多分支操作，至少要对得起它一听就比较高端的名字吧，于是我决定把分支的合并作为一个大标题。

# Branch 合并是大事 #

#### git 的两种合并模式 ####

分支的合并是非常智能的，目前有两种模式，两种模式的选择，不需要我们参与，而是 Git 根据分支情况不同，自行判断选择的。在我使用 Git 的过程中，执行分支合并，有时需要输入提交信息，有时不需要，作为小白的我懵的不知所以然，后来才知道是因为合并模式的问题。

两种模式是：

1.  Fast-Forward（快进式）（PS:这个名字是官方的）
2.  Recursive Strategy Merge（策略合并式）（PS:这个名字非官方，我自己起的，有时也叫三方合并式）

*  **Fast-Forward（快进式）**

![4791580da9c9651af125f4e52304334a.png][]

如图，有两个分支，master 分支和 feature 分支。当这两个分支处于上面的关系时，当进行合并操作时，就会出现 fast-forward。

原因是；由于当前 master 分支所指向的提交是 feature 分支的直接上游，所以 Git 只是简单的将指针向前移动。 换句话说，当你试图合并两个分支时，如果顺着一个分支走下去能够到达另一个分支，那么 Git 在合并两者的时候，只会简单的将指针向前推进（指针右移），因为这种情况下的合并操作没有需要解决的分歧——这就叫做 “快进（fast-forward）”。

合并后的分支指针位置如下：

![4279e4bea29f9cf8b9320ecc4451b0b1.png][]

*  **Recursive Strategy Merge（策略合并式）**

这个合并方式，是为补充 fast-forward 而出现的，因为你知道，在项目开发过程中，很多人开发的情况下，出现 fast-forward 的情况并不是很多，很多是类似下面这种。提交历史是分叉的，无法满足执行 fast-forward 的条件：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDUyNjIz_size_16_color_FFFFFF_t_70]

因为，master 分支所在提交并不是 feature 分支所在提交的直接祖先，Git 不得不做一些额外的工作。 出现这种情况的时候，Git 会使用两个分支的末端所指的快照（C4 和 C5）以及这两个分支的工作祖先（C3），做一个简单的三方合并,生成一个新的提交（C6）。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDUyNjIz_size_16_color_FFFFFF_t_70 1]

#### 实战演练一下 ####

说起来就是一堆理论，我自己都记不住，找个例子演示一下:

//创建一个文件夹，并初始化 Git
    mkdir GitDemo
    git init
    
    //初次提交，创建 master 分支
    touch master.txt
    git add.
    git commit -m '添加master文件'
    
    //从master分支末尾，创建并切换 featureA 分支，并创建一个提交
    git checkout -b featureA
    touch A.txt
    git add.
    git commit -m '添加A文件'
    
    //从master分支末尾，创建并切换 featureB 分支，并创建一个提交
    git checkout master
    git checkout -b featureB
    touch B.txt
    git add.
    git commit -m '添加B文件'
    
    //切换 master 分支
    git checkout master
    
    //master 合并 featureA 分支
    git merge featureA
    
    //master 合并featureA 后再合并 featureB 分支
    git merge featureB

博主不想给你说话，并向你投掷了一大串命令，快去敲敲看啊，会看到两种合并模式的！

master 分支合并 featureA 时，是快进式合并：

![在这里插入图片描述][20210510012051574.png]

master 分支合并 featureA 后， 再合并 featureB 时，已经不满足快进式条件了，此时合并会触发一个三方合并，产生一个新的提交。所以，执行合并命令，会跳到下面的页面，让我们编辑这个新提交的提交信息，默认提交信息是“Merge branch ‘branch name’”. 按 `i`编辑提交信息, `:wq!`保存并退出页面。

![d57118e0d93d16ada1b251d88ff1f9a6.png][]

合并成功后的提示信息：

![1c2425d23ee08ce6e0535975957acf45.png][]

画出上面小例子的分支合并，示意图，如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDUyNjIz_size_16_color_FFFFFF_t_70 2]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDUyNjIz_size_16_color_FFFFFF_t_70 3]

# 和平解决 Branch 合并冲突 #

有人在的地方就有江湖，有分支在的地方，就有冲突。

有时候合并操作不会如此顺利。 如果你在两个不同的分支中，对同一个文件的同一个部分进行了不同的修改，Git 就没法干净的合并它们，于是就会发生冲突。

如下，分别在 master 和 featureA ，在master.txt 文件第一行添加一句话，然后两个分支合并，就会发生冲突。  
![在这里插入图片描述][2021051001213943.png]

冲突提示信息中，指明冲突文件为 master.txt。同时，也可以通过 `git status` 命令，查看冲突的详细信息

![6efe8882246b15e3d7d09b1acfe46f2a.png][]

需要说明的是，如果遇到冲突的话，git 就无法自动合并了，接下来要靠我们自己手动解决冲突，方法是：

1.  查看造成冲突的文件，修改冲突部分
2.  对修改后冲突文件，执行 `git add`操作
3.  创建一个修改冲突的提交。

先知道一下思路，有个简单的概念在脑子里，接下来，一步一步仔细看～

#### 第一步：查看造成冲突的文件，修改冲突部分 ####

冲突文件 master.txt 如下，git 虽然无法解决冲突， 但是已经帮我们帮到最后了，使用简单的三个符号，标明了冲突的地方，以及冲突的两个分支在该地方发生冲突内容。

![a73a78c211855cc57d4505f92b0787f4.png][]

<table> 
 <thead> 
  <tr> 
   <th>符号</th> 
   <th>意义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>=======</td> 
   <td>分隔符</td> 
  </tr> 
  <tr> 
   <td>&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD 至 =======</td> 
   <td>master 分支中该地方的内容</td> 
  </tr> 
  <tr> 
   <td>======= 至 &gt;&gt;&gt;&gt;&gt;&gt;&gt; featureA</td> 
   <td>featureA 分支中该地方为内容</td> 
  </tr> 
 </tbody> 
</table>

接下来编辑 master.txt 文件,完成合并，确认之后，把 git 冲突标识符号给删除掉即可。

#### 第二步 & 第三步：修改后冲突文件，add && commit ####

![7a1d1dd42e5576200d4aadf2aa0b6d52.png][]

# 分支回滚， 有后悔路可以走 #

现实中，难免有些时候，你会有后悔的念头。例如每天我迟到的时候，都会后悔为什么第一遍闹钟响的时候没有起床，但是这个世界，没有后悔路可以走，我只能努力做到明天早起。

但是，Git 中有！，因为神奇的 reset 和 revert 命令～，两个命令都可以达到回滚的效果，两者之间的区别以后会专门说，这里我们使用 reset 。

**提前声明：回滚之前，不要忘记做好备份，有备无患呐。**

#### 本地分支回滚： ####

确定回滚到哪个提交，找到该提交的 commit id,执行以下命令，就好了

git reset --hard commit id

#### 远程分支回滚 ####

依旧是个伪命题。远程分支不存在什么回滚，要想达到回滚的效果，就是删除之前的远程分支，然后把本地回滚好的本地分支，push 到远程。

git reset --hard commit id //本地分支回滚
    git push origin :<name> //删除远程分支
    git push origin <name> //用回滚后的本地分支重新建立远程分支

# 我习惯每篇博客都有个结束语 #

这篇博客用了我不少洪荒之力，希望对大家理解 Git 分支有所帮助，不对之处还请指出。  
最近 Git 系列走起，下篇博客见！

# 欢迎订阅我的Git系列文章 #

*  [ 01. 请回答：Git是什么？][Git]
 *  [ 02. Git常用命令一日游活动][02. Git]
 *  [ 03. Git三大特色之Branch(分支)][03. Git_Branch]
 *  [ 04. Git三大特色之Stage(暂存区)][04. Git_Stage]
 *  [ 05. Git三大特色之WorkFlow(工作流)][05. Git_WorkFlow]
 *  [ 06. Git-你好, HEAD 同学][06. Git-_ HEAD]
 *  [ 07. Git-用 cherry-pick 挑好看的小樱桃][07. Git-_ cherry-pick]
 *  [ 08. Git-rebase 黑魔法之打造完美的线性历史][08. Git-rebase]
 *  [ 09. Git-rebase 黑魔法之打磨 commit 颗粒度][09. Git-rebase _ commit]
 *  [ 10. Git-少年，你想学回滚吗？想撤销文件修改吗？][10. Git-]
 *  [ 11. Git-移动记录仪 & 贴心小棉袄 reflog][11. Git-_ _ _ reflog]
 *  [ 12. Git-丢失的 commit 是真的消失了吗？][12. Git-_ commit]
 *  [ 13. Git-叹为观止的 log 命令 & 其参数][13. Git-_ log _ _]
 *  [ 14. Git-送娃子们一本关于如何自学 Git 的秘籍][14. Git-_ Git]

--------------------

欢迎关注个人微信公众号「浅浅同学的开发笔记」，最新的博客，好玩的事情，都会在上面分享，期待与你共同成长。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDUyNjIz_size_16_color_FFFFFF_t_70_pic_center]

[Git]: http://blog.csdn.net/qq_32452623/article/details/78276451
[Git 1]: /images/20220606/e204ba54fbde42d88c0e7a0833b8729c.png
[7251bd4d7b1af4aaaa3ffaf9ed004c48.png]: /images/20220606/f27f4dc65a324005ace0d992706a8d87.png
[git _ master]: /images/20220606/ad11d89ec4754db7a37b68522a0d1f2f.png
[4791580da9c9651af125f4e52304334a.png]: /images/20220606/fe5c1190f4384f6bb1233f7ecc53b7ba.png
[4279e4bea29f9cf8b9320ecc4451b0b1.png]: /images/20220606/37ce3593914a460d95cf7723984a422d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDUyNjIz_size_16_color_FFFFFF_t_70]: /images/20220606/d482510ab8e24f3380ac2f7da2c11a5e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDUyNjIz_size_16_color_FFFFFF_t_70 1]: /images/20220606/b9ebb863bab646a691a358f4e3d9c985.png
[20210510012051574.png]: /images/20220606/7540c90342f84b789586fda388860d43.png
[d57118e0d93d16ada1b251d88ff1f9a6.png]: /images/20220606/770245cf84934a59ade2c99fb97df1bd.png
[1c2425d23ee08ce6e0535975957acf45.png]: /images/20220606/8b0baa646a4a496fb361128620e6b174.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDUyNjIz_size_16_color_FFFFFF_t_70 2]: /images/20220606/0ae500ccb2d34db58c0a3944f01883aa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDUyNjIz_size_16_color_FFFFFF_t_70 3]: /images/20220606/e6de564094d94aa482d439be960a1ea7.png
[2021051001213943.png]: /images/20220606/472332638d634c8989523afb0f51394c.png
[6efe8882246b15e3d7d09b1acfe46f2a.png]: /images/20220606/53438e48160f48c69b6e63fc5b340c91.png
[a73a78c211855cc57d4505f92b0787f4.png]: /images/20220606/214bb0c48b7445418f57c296ffcd131d.png
[7a1d1dd42e5576200d4aadf2aa0b6d52.png]: /images/20220606/a52393b6f8284f85976de0af600ea971.png
[02. Git]: http://blog.csdn.net/qq_32452623/article/details/78276474
[03. Git_Branch]: http://blog.csdn.net/qq_32452623/article/details/78355976
[04. Git_Stage]: http://blog.csdn.net/qq_32452623/article/details/78417609
[05. Git_WorkFlow]: http://blog.csdn.net/qq_32452623/article/details/78905181
[06. Git-_ HEAD]: http://blog.csdn.net/qq_32452623/article/details/79415990
[07. Git-_ cherry-pick]: http://blog.csdn.net/qq_32452623/article/details/79449534
[08. Git-rebase]: http://blog.csdn.net/qq_32452623/article/details/79459842
[09. Git-rebase _ commit]: http://blog.csdn.net/qq_32452623/article/details/79475057
[10. Git-]: http://blog.csdn.net/qq_32452623/article/details/79521461
[11. Git-_ _ _ reflog]: http://blog.csdn.net/qq_32452623/article/details/79534832
[12. Git-_ commit]: http://blog.csdn.net/qq_32452623/article/details/79551429
[13. Git-_ log _ _]: http://blog.csdn.net/qq_32452623/article/details/79599503
[14. Git-_ Git]: http://blog.csdn.net/qq_32452623/article/details/79619798
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNDUyNjIz_size_16_color_FFFFFF_t_70_pic_center]: /images/20220606/6adb75791b714eb5b510869872eff228.png