05_Git分支重要操作

上一篇文章中，我们创建了一个新的分支，并且在新分支下创建了一个新的文件并且提交给了Git版本库，但是切回master分支，我们发现原分支没有受到任何的影响。我们这一篇文章就对Git的中的分支再做一个更加详细的操作分析。

分支的删除

• git branch -d 分支名：删除指定的分支，但是我们不能删除我们当前所处的分支，如果新分支有改动并且我们没有合并过新分支，那么我们就需要使用-D删除，请看以下例子
  删除失败
  切回原分支删除成功
• git checkout -b 新分支名：创建一个新的分支并且切换到新分支

Git分支的合并

我们第一次删除的时候，发现删除失败，原因是新分支存在修改（我们提交了新的内容），因此删除失败需要-D来删除，那么我们如果把新分支的内容合并到master分支上，就可以正常删除分支了

• git merge 分支名：将指定分支合并到当前分支上，我们看以下例子，分别展示了两个分支的不一样的地方，然后合并后，进行了一次顺利的分支删除
  一次成功的合并和顺利的删除

分析原理

• 为什么每一次git log的commit都能按顺序来打印？

我们可以看到每次commit后，生成了一个新的标识，而新的commit中又记录了上一次commit的标识，以此来保持顺序，并且是由后面的的指针指向前面的commit。

类似链表结构的commit链

• 那么分支合并是什么？再谈分支，有两个重要的概念（指针）
  • HEAD指向的是当前分支

  • master指向提交

    
    HEAD指向master，master指向提交
    如果创建了dev分支，并且切换到dev分支

• 若我们在dev分支上又进行了提交

  
  HEAD指向dev，dev指向属于它的提交

• 现在我们切换回master分支并且合并分支，而这种合并我们一般称为FastForward，没有冲突直接合并。

  
  现在把分支合并
• 有冲突的分支如何合并？假如master和dev分支都存在对同一文件的不同修改提交呢？比如我在master中对test.txt文件添加一行Aqing，而在dev中对它添加一行Cyan。
  分别在不同分支的同一文件做不同修改，合并失败

• 我们再打开看一下冲突文件此时的内容是什么

  
  冲突的文件包含了两个内容
• 因此我们可以手动的去选择要保留的内容是什么，删除不需要保留的部分。之后再调用git status查看状态
  此时的add和commit都是为了确认冲突解决

• 此时我们切回到dev分支，发现dev分支还是原来的样子，此时我们在dev分支合并master分支，会发现直接成功，冲突被Git自己按我们的解决方式解决了。

  
  分析原因？

• 因为根据分支的指针指向，当我们在master分支解决了冲突后，HEAD指针指向master，master指向commit，master指向的commit已经领先了dev指向的commit，因此当切换到dev分支，HEAD指向的dev，要求合并，dev会直接指向到最新的commit（该commit中已经解决了合并的冲突）

  
  如图所示