Git 的默认分支就是 master。你所作的commit会在master分支上自动移动。 在多次提交操作之后，master分支指向最后那个commit object（提交对象链）。
Git 的 “master” 分支并特殊，跟其它分支没有区别。 之所以几乎每一个仓库都有 master 分支，是因为 git init 命令默认创建它。
但很多时候听别人说master分支，往往有一种 这个分支是稳定、无bug的分支。而develop往往预示这新功能，不稳定的分支。这和分支策略有关，但本质上这两个分支没区别。
一.分支管理
1.分支创建
通过git branch来查看和创建分支。
创建标签记在HEAD指针所指向的提交点创建tag（就是当前所在分支）
创建dev分支：git branch dev
此时有两个分支，一个是刚创建的分支dev一个是默认分支master
分支切换到dev：git checkout dev
创建分支与切换分支同时完成：git checkout -b dev2
这时我们在dev2分支创建一个文件A.txt并且提交。我们发现在dev2分支可以看到这个文件，当我们切换会master时候无法看到这个文件。
2.分支删除
git branch -d dev2
强制删除git branch -D dev2
不能删除自己所在的分支
我们可以切换到master删除一个合并后的或者没有发生变化的分支
3.分支合并
git merge dev2
4.分支的本质
master指向的是提交
HEAD是指向当前的分支，当前在哪个分支就指向哪个分支
5.分支的冲突
两个分支修改同一文件时合并出现冲突
我们需要手工删除冲突的修改内容再合并
二.git stash
git stash
会先把修改的内容做保存然后我们就可以切换到其他的分支
git stash list
列出stash保存的所有修改
git stash pop
将stash过的修改恢复出来。通过pop取出最近的恢复并且删除stash中的修改
三.分支管理策略
（重要）
从上图可以看到主要包含下面几个分支：
master：git默认主分支（这里不作操作）。
stable：稳定分支，替代master，主要用来版本发布。
develop：日常开发分支，该分支正常保存了开发的最新代码。
feature：具体的功能开发分支，只与 develop 分支交互。
release：release 分支可以认为是 stable分支的未测试版。比如说某一期的功能全部开发完成，那么就将 develop 分支合并到 release分支，测试没有问题并且到了发布日期就合并到 stable分支，进行发布。
bugfix：线上 bug 修复分支。
1.主分支
因为master分支我们不作操作，所以针对stable和develop这两个主分支来讲解。
stable分支：用来发布，管理着多个稳定的版本。
develop分支：就是我们日常开发的分支。
使用这两个分支就具有了最简单的开发模式：develop 分支用来开发功能，开发完成并且测试没有问题后，则将 develop 分支的代码合并到 stable分支并发布。
2.辅助分支
通过这些分支，我们可以做到：团队成员之间并行开发，增加新功能更加容易，可以同时进行开发和版本发布、线上bug修复等
2.1Feature分支
Feature 分支用来开发具体的功能，一般基于develop分支，最后完成功能后再合并到develop分支。
比如，目前我们针对develop分支来做功能开发，在开发的过程中会有紧急需求需要开发，且在本次版本发布时间之前要能测试完成。我们可以基于之前稳定版本另开一个feature分支来做紧急需求的开发，发布并进行测试，完成之后再合并到develop分支上。
2.2release分支
release分支作为预发布分支，release 分支从 develop 分支 fork 出来，最终会合并到 develop 分支和 stable 分支，合并到 stable分支上就是可以发布的代码了。
为什么我从develop分支fork出来，还要合并到develop分支中呢？因为我们在release分支上难免会有bug产生，修复bug也是在release分支上，所以必须要合并到develop分支。
2.3bugfix分支
bugfix 分支用来修复线上bug。当线上代码出现 bug 时，我们基于 stable 分支开一个bugfix分支，修复 bug之后再将 bugfix分支合并到stable分支并进行发布，同时develop 分支作为最新最全的代码分支，bugfix分支也需要合并到 develop 分支上去。