【Git】分支管理
【简介】
【分支相关基础命令】
git支持创建分支
在合并分支后，master所指向的提交版本就可以同时拥有主分支与新分支的修改内容
【查看分支命令】
git branch 命令可以查看， 当前本地仓库内有哪些分支
众所周知， HEAD指针一般指向master分支， 而HEAD是可以指向其他分支的， 被指向的分支就是当前正在工作的分支
上图中master前有个“*”符号， 这意味着HEAD指向master分支，master分支是当前正在工作的分支
【创建分支命令】
git branch [分支名] 可以在当前本地仓库内创建分支
【切换分支命令】
git checkout [分支名] 可以在当前本地仓库内，让HEAD指针指向想要的分支
而git checkout -b [分支名] 可以在当前本地仓库内，新创建一个分支并让HEAD指针指向（集合了创建与切换）
【合并分支命令】
在dev上commit的内容， 不会在master分支上体现， 这是因为commit操作会新增一个提交版本， 并导致HEAD指向的dev分支， 指向最新的这个提交版本
而没被HEAD指向的master分支，并不会指向最新的这个提交版本
master分支为主分支，要想将修改同步到主分支，就要进行合并分支操作
第一步， 把分支切换到master
第二步， 使用git merge [分支名] 命令把指定的分支合并到切换的分支上
如此一来， 就能把修改同步到主分支
【删除分支命令】
使用git branch -d [分支名]命令可以删除该分支，
但要注意， 不能在该分支上删除该分支， 只能在其他的分支上删除该分支， 否则会报错
【合并冲突】
在实际分支合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。
譬如， 有一个文件遭到了master和dev1两个分支的共同修改
合并时，需要将dev1分支合并到master分支， 但在合并时， git没办法自己知道到底是保留master分支的修改， 还是dev1分支的修改， 因此就会出现合并冲突，报错
查看冲突文件时， git会用分隔符来分割冲突的代码， 此时只需要删除其余冲突的部分， 同时删除分隔符即可解决报错
修复完后， 还需要对该文件进行一次add 和commit， 提交到版本库后，才能让git知晓到底是保留哪个分支的修改，这里保留master分支的修改
提交后， master分支更新到最新， 但dev1分支还没有
因此， merge冲突需要手动解决， 并进行一次提交操作
【合并模式】
可以通过git merge --no--ff [分支名] 命令来切换合并模式， 其中-m参数代表切换模式的同时进行提交到版本库
可以通过git log 命令查看日志， --graph参数是形成图， --abbrev参数令其更加简洁
这可以知晓是commit还是merge
这个模式的关键是，对分支信息进行显示， 知晓修改到底是commit进来的， 还是merge进来的
【bug分支】
若我们修改完dev2分支后，切换到master分支， 就会发现dev2分支在工作区中的调整也跑到了master分支的工作区上
它仅在工作区中影响， 但我们还是不想看到修改的内容跑到master分支的工作区上
因此，我们可以切回dev2， 使用git status命令
该指令可以把当前分支在工作区中已经修改的内容存储到一个stash空间
注意， 只能存储被git追踪管理的文件， 如果新创建一个文件， 是无法进行存储的，必须通过add和commit才行
随后， 需要创建一个用于专门修复bug的fix_bug分支， 并在里面修复bug后提交
现在bug已经修复了， 但没有合并到master上
因此需要切换到主分支上，把fix_bug合并到master上
现在bug修复了， 但dev2没有开发完， 要接着开发，切换到dev2， 会发现dev2修改的内容不见了， 这是因为内容都存到了stash中， 现在要用git stash pop命令取出来
此时dev2中的文件没有修复bug（因为创建dev2时是根据有bug的master创建的），但这无关紧要， 因为master已经修复bug了，dev2的bug在同步过去时会被覆盖
在dev2的代码开发完，add和commit后，此时是这个样子
此时如果切到master上， 让dev2合并入master， 会产生如下结果， 出现合并冲突
合并冲突要手动解决， 一旦手动操作， master就容易改出bug ，又前功尽弃了
因此我们需要遵循一个良好的习惯：不在master上合并代码，而是先在dev上进行一次合并
【强制删除分支】
正常来说，使用普通的删除命令无法删除一个已经commit的分支
而git branch -D命令可以强制删除这样的分支
