【Git】分支管理_git分支管理
【简介】
每次提交，都会产生一个提交版本，Git把这些一个个提交版本串成⼀条时间线，这条时间线就可以理解为是⼀个“分支”只有⼀条时间线，在Git⾥，这个分支就叫“主分支”，即 “master分支”
HEAD指针指向master指针，master指针指向最新一次的提交，所以，HEAD 指向的就是当前分支（当前的版本）因此，在拿到最新一次的提交后， 就可以追根溯源， 寻找之前提交过的版本
【分支相关基础命令】
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 会采用 Fast forward 模式。在这种 Fast forward 模式下，删除分⽀后，查看分支历史时，会丢掉分支信息，看不出来最新提 交到底是 merge 进来的还是正常提交的
但在合并冲突部分，通过解决冲突问进行的新提交，得到的最终状态为：那么这就是 no-Fast forward 模式了，这样的好处是，显示分支， 从分支历史上就可以看出分支信息
可以通过git merge --no--ff [分支名] 命令来切换合并模式， 其中-m参数代表切换模式的同时进行提交到版本库
可以通过git log 命令查看日志， --graph参数是形成图， --abbrev参数令其更加简洁
这可以知晓是commit还是merge
这个模式的关键是，对分支信息进行显示， 知晓修改到底是commit进来的， 还是merge进来的
【bug分支】
假如我们现在正在 dev2 分支上进行开发，开发到一半，突然发现 master 分支上面有 bug，需要 解决。在Git中，每个 bug 都可以通过⼀个新的临时分支来修复，修复后，合并分支，然后将临时分支删除， 不能直接在dev2上修复bug， 因为这不是dev2的职责
我们可以这么解决：
若我们修改完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命令可以强制删除这样的分支
