Git分支管理

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险
现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作
Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件

每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支
每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上

从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变
假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并

1、创建与合并分支
a)创建dev分支，然后切换到dev分支：

$ git checkout -b dev

git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

$ git branch dev
$ git checkout dev

b)显示分支

 git branch

c)切换分支
dev分支的工作完成，我们就可以切换回master分支：

 git checkout master

d)合并分支
把dev分支的工作成果合并到master分支上
合并指定分支到当前分支

git merge dev

e)删除分支

git branch -d dev

注：当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交

用git log --graph命令可以看到分支合并图

2、禁止快速合并分支
Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息；
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息
准备合并dev分支，请注意–no-ff参数，表示禁用Fast forward

git merge --no-ff -m "merge with no-ff" dev

因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去

3、分支使用原则
在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

4、工作区的暂存
当正在dev分支干活，活还没有完成，但收到一个紧急修改master分支bug的工作，可以将dev干到一半的活暂存起来。

git stash

用git stash list查看暂存区的内容

然后去master分支创建临时分支，来修复bug，修复完后，合并临时分支到master
然后dev分支接着干活。
有两种方法将暂存区的内容恢复到工作区：
a)用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除
b)用git stash pop，恢复的同时把stash内容也删了
你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令

git stash apply stash@{0}