前言
我们都在口口称道Git给我们做版本控制带来的好处:
1、底层文件存储系统为版本切换时带来的快捷性；
2、去中心化为版本库的安全性提供了更高的水准，并拥有了离线使用的便利；
在以上两项为基础下，分支的优势被放大，本文记录当前的Git使用分支管理方案；
示例
假如项目组有三明后端开发工程师，Mike，Jary，Amy；
管理思路
在实际项目中，版本控制的核心内容可分为：个人版本的管理、个人版本合并为合并版本、合并版本匹配环境；
个人版本管理：单人开发的记录，也是整个项目中的基础版本单元，侧重是按时按节点进行提交以清晰的记录；
合并版本管理：作为个人版本的合并载体，侧重是每个提交节点的注释工作好做好；
环境版本管理：即与项目所有的环境进行同步的版本，本项目分为开发环境、测试环境、验证环境、生产环境；
．
思路：
- 本地分支与远程库分支是灵活关联的，即本地的一个分支可以分别向当前关联远程库内的不同远程分支进行交互；
- 单人的所有操作都可以基于本地个人分支，通过向远程分支的不同同步策略实现管理的差异化，来达到不同的远程分支本身的版本路线；
- 如上所示：除了版本管理员之外，普通开发人员本地仅需保留个人分支即可，需要合并操作时，将合并操作在本地分支执行完之后再同步至需要的远程分支；
示例图：
需要哪些分支
以下举例分支都需在远程库同步一个同名远程分支；
个人版本
命名
“个人英文简称”+“_branch”，例：Mike_branch、Jary_branch；
个数
单人需要至少一个本人的分支；实际需要根据个人同时在做的开发任务线而定，即每个开发任务线至少有一个，如果同时在做多个任务线即需要多个个人分支；
假如个人有多个个人分支时，同任务线内的开发人员尽量协调一个统一的关键字；
作用
个人开发记录版本，也是整个管理方案的基础版本；
操作
- 根据开发内容进行里程碑式提交；
- 每天起码要有一次备份作用的提交并同步当日所有提交节点至远程库；
合并分支
命名
merge_branch
个数
与项目同时存在的任务主线同步，每个任务线至少有一个合并分支；
作用
个人版本的合并操作载体；
操作
- 个人在需要时依次将个人版本推送（或者与merge_branch合并后推送）至merge_branch
环境分支
命名
开发环境：dev_branch、测试环境：test_branch、验证环境：pre_branch、生产环境：pro_branch
个数
每种环境分支应只有一个并且应该与对应的环境在线版本保持实时同步；
作用
保证代码实时同步备份；
操作
- 当合并版本的指定合并节点（个人版本合并后的版本节点）需要上环境时，保证本地分支版本正确的前提下，向远程环境分支进行推送；
操作案例
假如项目起始时，三人同时进行个人中心模块开发任务；
开发内容划分和分工为为：
登录功能：Mike
个人中心UI展示：Mike、Jary
个人记录（浏览记录、收藏等）功能：Jary、Amy；
初始化库
管理员Mike负责创建远程库，并初始化分支；
- 创建个人分支Mike_branch；
- 由于Mike在主线开发任务（登录功能）之外还有UI展示任务的协作任务，则需要另建一个个人分支，Mike_ucenterUI_branch（关键字需与Jary协调）
- 创建合并分支merge_branch，并且由于同在个人中心模块，属于一个主任务线，则仅需一个合并模块即可；
- 创建环境分支dev_branch、test_branch、pre_branch、pro_branch并同步至远程库；
- 通知项目开发成员远程库地址；
初始化分支
Jary&Amy对远程库进行clone，并初始化自己的分支；
- Jary_branch、Jary_ucenterUI_branch、Jary_record_branch；
- Amy_branch、Amy_record_branch；
两人的个人主分支前期不用，但是在没有协作的时候尽量使用个人主分支；
日常提交
- 每人每天根据开发内容进度以及备份要求进行提交；
- 即每人每天至少应该有一次提交和同步；
合并代码
此时举个简单的例子，record任务线已完成开发需要上环境，此时任务线成员Jary和Amy需依次将代码推送至merge_branch上，例如：
- Jary先通过本地分支Jary_record_branch已完成的某个提交节点为版本推送至远程分支merge上；
- Amy通过fetch远程库信息发现Jary已经提交完自己的版本，此时Amy需要在本地的本地分支Amy_record_branch上与merge_branch进行合并，完成合并之后将最新的合并版本推送至远程 merge_branch。
单元测试
此时的合并版本完成之后，任务线成员需协调共同在指定的合并版本上进行各自的单元测试。
环境版本
当测试通过后，由指定人员负责将版本同步至环境，具体操作如下：将本地分支版本切换至正确的提交节点，然后通过本地分支推送至指定的环境分支，同时，为环境分支配置上CI功能，即完成环境版本的发布。