目录
1.Git分支管理
Git 的默认分支就是 master。你所作的commit会在master分支上自动移动。 在多次提交操作之后，master分支指向最后那个commit object（提交对象链）。
Git 的 “master” 分支并特殊，跟其它分支没有区别。 之所以几乎每一个仓库都有 master 分支，是因为 git init 命令默认创建它。
但很多时候听别人说master分支，往往有一种 这个分支是稳定、无bug的分支。而develop往往预示这新功能，不稳定的分支。这和分支策略有关，但本质上这两个分支没区别。
1.1 分支创建
通过git branch来查看和创建分支。
创建标签记在HEAD指针所指向的提交点创建tag（就是当前所在分支）
git branch dev
分支切换到dev
git checkout dev
创建分支与切换分支同时完成
git checkout -b dev2
这是我们在dev2分支创建一个文件A.txt并且提交。我们发现在dev2分支可以看到这个文件，当我们切换会master时候无法看到这个文件。
1.2 分支删除
不能删除自己所在的分支
git branch -d dev
我们可以切换到master删除一个合并后的或者没有发生变化的分支
git checkout master
git branch -d dev
- 如果一个分支发生了变化不能删除
我们发现dev2发生了变化，同时没有合并不能删除。如果要强制删除可以
git branch -D dev2
1.3 分支合并
我们继续基于上面的例子，切换到master上做dev2 的合并
git merge dev
我们发现master分支上也添加了A.txt这个文件
如果修改的是同一个文件也可以做同样的合并，让我们切换到dev2分支修改A.txt中的内容。在A.txt中添加了一行World
git checkout master
我们切换会master分支的时候发现提示了A.txt的变动。通过合并发现master分支上也合并了dev2修改的内容，合并之后dev2就删除就被允许了。
git merge dev2
cat A.txt
1.4 分支的本质
master指向的是提交
HEAD是指向当前的分支，当前在哪个分支就指向哪个分支
第二张图上我们可以看到创建了dev的分支，当我们切换到dev分支的时候HEAD就会指向dev
当我们进入.git文件夹查看HEAD的内容的时候可以看到，所处分支不同内部的文件指向就不同。
master分支
cat HEAD
dev2分支
cat .git/HEAD
git的分支与svn不同，svn是整体拷贝一份分支，git用的是指针。
如果dev发生修改提交，dev的版本就会向后移动。
在master分支上如果合并就会出现下面的图
1.5 分支的冲突
我们在dev2分支里面修改A.txt文件添加一行 update by dev2后提交
vi A.txt
git add.
git commit -m 'dev2 commit'
我们在master分支里面修改A.txt文件同时添加一行 update by master后提交
vi A.txt
git add.
git commit -m 'commit master'
git merge dev2
合并时候我们发现出现冲突
cat A.txt
<<<<<<<<<<<HEAD是当前指向的分支所修改
>>>>>>>>>>dev2是dev2分支修改
我们需要手工合并。修改后报了master的内容
vi A.txt
git status
git add.
git commit -m '提交冲突合并'
我们可以通过图形来查看冲突的提交日志。
git log --graph
2.Git stash
1 当正在dev分支上开发某个项目，这时项目中出现一个bug，需要紧急修复，但是正在开发的内容只是完成一半，还不想提交，这时可以用git stash命令将修改的内容保存至堆栈区，然后顺利切换到hotfix分支进行bug修复，修复完成后，再次切回到dev分支，从堆栈中恢复刚刚保存的内容。
2 由于疏忽，本应该在dev分支开发的内容，却在master上进行了开发，需要重新切回到dev分支上进行开发，可以用git stash将内容保存至堆栈中，切回到dev分支后，再次恢复内容即可。
总的来说，git stash命令的作用就是将目前还不想提交的但是已经修改的内容进行保存至堆栈中，后续可以在某个分支上恢复出堆栈中的内容。这也就是说，stash中的内容不仅仅可以恢复到原先开发的分支，也可以恢复到其他任意指定的分支上。git stash作用的范围包括工作区和暂存区中的内容，也就是说没有提交的内容都会保存至堆栈中。
2.1 git stash
我们在master分支修改A.txt添加一行
这时我们要切换dev2分支
我们发现会提示错误，git建议我们先提交或者stash修改的内容再切换
我们执行
git stash
git checkout dev2
会先把修改的内容做保存然后我们就可以切换到其他的分支
列出stash保存的所有修改
我们切换回master分支执行，我们能看到上次保存的操作
git stash list
我们同样也可以再次修改文件去做stash，这样就会产生2条保存的记录
vi A.txt
git status
git stash
git stash list
我们可以将stash过的修改恢复出来。通过pop取出最近的恢复并且删除stash中的修改
git stash pop
cat A.txt
git stash list
如果两次pop由于第一次没有做提交则会报错，所以我们应该把第一次pop的提交，在pop第二次的。
git stash pop
git stash list
git commit -am 'stash update'
git stash pop
3.分支管理策略
git 的分支整体预览图如下：
从上图可以看到主要包含下面几个分支：
master：git默认主分支（这里不作操作）。
stable：稳定分支，替代master，主要用来版本发布。
develop：日常开发分支，该分支正常保存了开发的最新代码。
feature：具体的功能开发分支，只与 develop 分支交互。
release：release 分支可以认为是 stable分支的未测试版。比如说某一期的功能全部开发完成，那么就将 develop 分支合并到 release分支，测试没有问题并且到了发布日期就合并到 stable分支，进行发布。
bugfix：线上 bug 修复分支。
3.1主分支
因为master分支我们不作操作，所以针对stable和develop这两个主分支来讲解。
stable分支：用来发布，管理着多个稳定的版本。
develop分支：就是我们日常开发的分支。
使用这两个分支就具有了最简单的开发模式：develop 分支用来开发功能，开发完成并且测试没有问题后，则将 develop 分支的代码合并到 stable分支并发布。
3.2辅助分支
通过这些分支，我们可以做到：团队成员之间并行开发，增加新功能更加容易，可以同时进行开发和版本发布、线上bug修复等。
3.3Feature分支
feature 分支用来开发具体的功能，一般基于develop分支，最后完成功能后再合并到develop分支。
比如，目前我们针对develop分支来做功能开发，在开发的过程中会有紧急需求需要开发，且在本次版本发布时间之前要能测试完成。我们可以基于之前稳定版本另开一个feature分支来做紧急需求的开发，发布并进行测试，完成之后再合并到develop分支上。
3.4release分支
release分支作为预发布分支，release 分支从 develop 分支 fork 出来，最终会合并到 develop 分支和 stable 分支，合并到 stable分支上就是可以发布的代码了。
为什么我从develop分支fork出来，还要合并到develop分支中呢？因为我们在release分支上难免会有bug产生，修复bug也是在release分支上，所以必须要合并到develop分支。
3.5bugfix分支
bugfix 分支用来修复线上bug。当线上代码出现 bug 时，我们基于 stable 分支开一个bugfix分支，修复 bug之后再将 bugfix分支合并到stable分支并进行发布，同时develop 分支作为最新最全的代码分支，bugfix分支也需要合并到 develop 分支上去。