5.分支管理
5.1.分支使用场景和作用
通常在项目上线后，我们经常会同时面临生产环境出现Bug和新需求正在开发的情形，如何将这些情形同时处理而又互不影响呢？这个时候就需要使用到版本控制系统的分支管理。
分支管理参考图：
上图针对不同时期的工作场景建立了不同的项目分支，分别处理不同场景下产生的问题，通过建立分支可以将工作同时分配给多个人员进行开展，工作人员各自处理不同场景的任务，并且各自之间没有冲突，这不仅在效率和稳定方面都有很好的作用。
5.2.分支实战运用
在实际的工作中一般中大型规格的软件项目都会有一套分组管理机制，为项目不同的场景、不同的阶段形成独立的项目工程，促使让项目的迭代根据流畅、生产环境运行更加稳定。严格的、清晰的实施分组管理机制是管理好项目必不可缺的一项工作。
以下根据个人的经验，将分支划分为如下的种类：
主干分支master
生产环境的源代码，代码功能的运行要和正在运行的生产环境完全一致。开发人员通常是无权限进行编辑操作的。
开发分支 develop
相当于主干分支的副本。“开发分支 develop”并不是在该分支上进行开发的，基于“开发分支”(最新的代码)并根据新需求，通常将该分支作为母体进行扩展建立一个新的分支“功能分支”。例如，接到某个新的需求要开发一个在线聊天功能，此时开发人员就需要在该分支(开发分支 develop)上拉一个新的分支用于开发在线聊天功能。
功能分支 feature
一般对于周期较短的功能，我们可以斟酌下直接在“开发分支 develop”上进行完成。但是对于冲长期的开发功能模块，通常设计、编码、测试会花上大量的时间，通常会在“开发分支 develop”上扩展出一个新的分支专门用于某个功能的开发，该分支就称为“功能分支 feature”。
Bug分支 hotfix
主要用于解决生产环境下出现系统问题(Bug)，该分支通常是从“主干分支master”上扩展建立新的分支。该分支需要注意的一项是，在修复完毕并测试上线后，最好将变更的内容同步合并到正在工作的其他分支，如开发分支、功能分支，以免造成其他分支上线覆盖掉了修复的内容。
合并预发布分支 MergeRelease
该分支的运用场景是，当我们开发好新功能或者修复好一个bug时，我们会用“主干 master”扩展建立一个新的分支，在将当前开发好新功能或者修复bug的分支与当前从主干拉的新分支进行一个代码合并，并在代码合并时或之后要排除合并的冲突问题，并在进行一次测试，测试无误后用户发布上线，上线后在将变更的内容同步合并到正在工作的其他分支，如开发分支、功能分支。
各个分支的工作流程图：
注：以上圆形代表每个分支
5.3.Git分支管理操作
5.3.1.创建分支
创建一个分支就是将某个目标分支做为一个原型将其复制成为一个新的项目工程(分支)。
创建：git <分支名称>
查看：git branch -v
操作参考图：
在实际的项目中创建分支一般使用：git checkout -b <分支名称>，这边表示创建分支并定位到分支
操作参考图：
5.3.2.切换分支
操作命令：git checkout <分支名称>
操作参考图：
5.3.3.合并分支
第一步，切换到主干：git checkout master
第二步，合并：git merge 分支名
操作参考图：
5.3.4.删除分支
1.切换到主干：git checkout master
2.删除：git branch -D 分支名
操作参考图：
6.冲突
6.1.冲突的出现场景
6.1.1.代码上传
当多名的开发人员都对同一份代码文件的同一块区域进行了编辑，那么当非首位提交人员在进行commit后再在对GitHub进行Push时就会产生冲突：
操作场景参考图：
6.1.2.版本合并时
从主干创建了一个分支并在分支中对某个代码的函数进行了编辑，另外同时主干也对同份代码的函数进行了编辑。主干对编辑的内容先进行了commit，那么当分支在对编辑内容进行commit时就会产生冲突。
冲突参考图：
6.2.解决冲突
下面以上述的第二种情况来介绍如何解决冲突：
- 通过命令：”git diff”，找到发生冲突的文件及冲突的内容区域，如图：
2.对冲突文件中的冲突内容进行编辑(手工解决冲突内容)，在实际的工作中这块往往需要找到和你同时操作同块内容的同事进行协商，看如何对内容进行编辑取舍。
3.对冲突的内容确定好修改后，需要对冲突文件进行add后再commit
操作参考图：
注：当Merging标识消失就表示冲突已经解决。
4.如果是代码上传是产生的冲突，那么在commit之后还需要进行一次push操作。
后续详见第二节.....