目录
[1. Git 分支管理](#1. Git 分支管理)
[2. 如何自己创建分支？](#2. 如何自己创建分支？)
[3. 创建分支修改内容，之后合并到主分支](#3. 创建分支修改内容，之后合并到主分支)
[4. 删除分支](#4. 删除分支)
[5. 出现 merge 冲突如何解决](#5. 出现 merge 冲突如何解决)
[6. 分支策略](#6. 分支策略)
前言
之前只是知道有 master 分支这个东西，但是具体是啥意思还是不知道，今天详细总结一下。
如下图所示：这个时间线就是 master 主分支，HEAD就是指针，是指向 master 的，所以就通过HEAD 找到 master，通过 master 找到最后一次的提交，此时这条时间线就可以理解为是一个分支。
除了主分支之外，它也是可以创建一些其他的分支的，
下图所示：git 也是支持创建分支和合并分支的。
1. Git 分支管理
在创建第一个分支之前，是需要看下当前 Git 中有哪些分支；使用 git branch 命令；如下图所示：
只有一个 master 分支，当Git创建出来仓库之后，默认的就是这个 master 分支， 此时可以回想上文中介绍的 HEAD，HEAD 指针不只是可以指向 master 分支的，还可以指向任何的分支，被 HEAD指向的分支才是当前我们工作的分支， 所以 HEAD 的作用：HEAD 指向那个分支，哪个分支就是工作分支。
2. 如何自己创建分支？
使用 命令：git branch [分支名称]
创建好之后还是用 git branch 命令来查看当前有哪些分支，如下图所示：
也可使用 tree .git/ 来查看当前 Git 中的树状结构：
然后查看 master 和 dev 分支下都有什么，可以看到当前 master 和 dev 都是指向最新的一次的提交的，下图所示：
下图就是树状结构图的直观体现，dev 分支也是指向 最新的一次提交的原因：在创建 dev 分支的时候就是站在当前版本的最新的提交基础上创建的分支。
3. 创建分支修改内容，之后合并到主分支
如果此时我们想在 新创建的 dev分支来进行 add 和 commit 操作，需要先将工作分支切换到 dev 分支才可以，可以使用 git checkout dev，（之前的 checkout -- ... 的意思是撤销工作区中修改的内容）
修改 dev 分支作为工作分支之后，此时就可以在 dev 分支修改文件了，随便做一个修改之后，如下图所示：
在 dev 这个工作分支修改内容之后，进行一次 commit 提交，之后切换分支到 master 为工作分支，可以看到，两次的最新提交记录并不是一样的，如下图所示：
其实在工作分支进行提交之后，是并不会影响其他分支的，dev 分支提交的是最新的一次改动，但是 master 分支还在指向上一次的改动，我们可以使用 git merge dev 来将 dev 分支改动的内容提交到 master 主线上来，前提是将工作分支切换到 master 分支上，合并之后的内容就是一样的了；如下图所示：
其实上述所描述的就是 创建一个 dev 分支，在 dev 分支上修改了 ReadMe 文件，修改之后再将dev 分支修改的内容合并到 master 主线上。（master分支就是一个创建git仓库之后默认就有的主线），一旦合并之后，dev 的使命也就结束了，对于 dev 分支来说，不用了就需要将删掉，为了不占用资源。
4. 删除分支
注：++首先要删除一个分支，需要在其他分支上来进行删除，如：要删除 dev 分支不能只在 dev 分支上删除 dev 分支，可以在 master 分支上删除 dev 分支。++
如下图所示：如果当前分支是工作分支，是不能对这个 工作分支进行删除的。
只能在当前工作分支，来删除其他的工作分支，（但是删除 dev 分支之后并不会影响 master 分支指向的最新的一次提交）如下图所示：
master 分支还是指向的 dev 最新一次修改的提交：
Git 是鼓励创建分支来修改 master 主线上的内容的，因为这个过程很轻量，直接更换的就是HEAD指针，虽然也可以在 master 主线上对文件的内容进行修改，但是 创建 dev 分支修改然后进行合并的这种方式，过程是更安全的。
5. 出现 merge 冲突如何解决
首先介绍一下什么是 merge 冲突，如：现在提出了一个新需求来进行开发一个新功能，所以此时就需要创建一个新的 dev 分支，现在正在 dev 分支进行开发呢，但是 master 分支上突然出现了一个 bug（master 分支上的代码也不是完全稳定的，只是相对来说稳定），所以就要修改 master 分支上的代码，不一会，dev 的代码写好了，然后 master 分支的 bug 也改好了，此时要进行合并了，但是dev分支一个版本，master 分支一个版本，此时应该merge保留的是哪个版本的代码呢，此时出现的情况就叫代码 merge 冲突，Git 是不会替开发人员做决定来保留哪个版本的代码的，所以需要开发人员来自己解决，解决的方法手动修改代码，然后进行 add 和 commit 操作即可。
来模拟一下这个流程，创建一个 dev 分支，并切换到 dev 分支，还是修改 ReadMe 文件，如下图所示：
解决 merge 冲突之前就是如下图所示的这个状态：
上图所示的过程就是手动解决 merge 冲突的方法。
还有一个命令 就是 git stash，这个意思就是将当前工作分支没有 commit 的文件进行保存，保存当前的工作进度，应用场景就是：在进行代码开发时，希望临时保存当前的工作进度，包括已暂存和未暂存的修改，然后去处理其他分支的任务，但是需要注意的是，前提是这个文件已经交给 Git 托管了，此时才能进行 stash，如下图所示：
但是如果新建一个文件，这个文件还没有进行过 add 和 commit 操作，此时这个文件就是没有被 Git 管理的，就不能进行保存，ReadMe 文件可以 stash 就是因为这个文件已经托管到 Git中了如下图所示：
6. 分支策略
上图所示：右边 master 主分支跑的代码是稳定的代码，所以 master 分支跑的代码是非常稳定的，次啊可以保证线上环境是稳定的，除了 master 分支，还有日常进行开发的主分支的 dev 分支，dev 分支上的代码是不稳定的，这个环境是没有经过验证测试的分支。
但是 master 分支也不是绝对稳定的代码，当 master 分支出现了 bug ，开发人员是不可以进行bug 的 fix 的，应该先创建一个本地分支，之后再进行 bug 的 fix，修复完成之后要进行一系列的测试，之后才可以 merge 到 master 主分支，如果直接在 master 主分支上进行修改，可能在改代码的过程中就出现更大的 bug，可能线上的环境就会更加不稳定。
如现在有这样的一个场景，正在 dev2 分支上进行开发，之后突然在 master 分支上出现了一个bug，此时开发人员该如何解决呢？
首先 git stash dev2 分支的代码（保存当前的工作进度）,之后切换到 master 分支上创建 fix bug 的分支，当然也可以在 dev2 分支上进行 fix，但 dev2 的初衷是开发新需求，而不是修改bug，所以最好创建一个新的分支：
上图所示：现在的状态是已经 fix bug 了，也已经 merge 到 master 分支上了，但是此时还需要回到 dev2 进行新需求的开发，下图所示：
但是此时 dev2 分支的代码不见了，就是因为刚才fix bug 之前使用了 git stash，所以切换回来 dev2 分支后，还需要将 stash 区保存的内容拿出来，使用 git stash pop命令，在操作之前可以使用 git stash list 命令来查看 stash 区中保存的是哪一次的内容：
此时就可以看到我们的开发到一半的代码了，但是此时可以看到 dev2 分支的状态还是没有修复bug 的版本，原因就是 dev2 的创建就是在 master 分支提交bug之后这个版本的基础上创建出来的，但是此时 dev2 分支也不会影响 master 分支，因为 master 主分支已经 fix bug了。
当在 dev2 分支上开发完新的需求之后，此时就可以将 dev2 分支的功能合并到 master 主分支上了，但是 master 分支在 fix bug 时候也已经改了内容了，所以此时进行合并一定是会 merge 冲突的，有了冲突就要解决冲突，解决冲突就需要手动改动代码，手动改就有可能出现 bug，所以是不建议在 master 分支中进行merge 冲突的解决的，此时一个比较好的做法就是将 master 分支中的代码 merge 到 dev2 分支上来，此时即使改出来新的 bug，也不会影响 master 主分支中的内容，所以可以按照下图所示进行操作：
