代码分支管理规范
Git Flow
在使用 Git 的过程中如果没有清晰流程和规划，否则,每个人都提交一堆杂乱无章的 commit,项
目很快就会变得难以协调和维护。
Git 版本管理同样需要一个清晰的流程和规范，Vincent Driessen 为了解决这个问题提出了 A
Successful Git Branching Model
Git Flow 流程图：
分支管理规范
- master/develop 分支：所有在 master 分支上的 Commit 应该打上 Tag，一般情况下 master 不存在 Commit
- develop 分支：develop 分支基于 master 分支创建，feature 分支做完后，必须合并回 develop 分支。由develop再合并到master分支
- test 分支：测试环境分支代码，功能开发完成后部署测试，需要定期从master上进行代码同步
- feature 分支：feature 分支做完后，必须合并回 develop 分支, 合并完分支后一般会删点这个 feature 分支，在需求有依赖的前提下，feature分支可以基于其他需求的feature分支创建
- hotfix 分支：hotfix 分支基于 master 分支创建，hotfix分支也是一个feature分支，只不过可以直接合并到master，开发完后需要合并回 master ，同时在master 上打一个 tag。如果没有合并到develop 分支，则需要将master和develop代码同步
代码开发
- 每位开发人员认领自己的功能需求，分别从 master 分支拉取自己个人分支进行功能编码。敏捷开发强调功能小版本迭代，并行开发。
- 当研发人员每个 feature 分支完成，开发自测和测试人员完成测试之后，提交 merge request，team leader 经过 code review 确定运行无缺陷后合并到 develop 分支。
- 此时测试人员需要从 develop 分支打包最新代码，并部署集成测试环境，同步进行功能、接口测试与其他系统的交互测试。
分支代码管理
- master 分支的每一次更新，都建议打 tag 添加标签，通常为对应版本号，便于管理
- feature分支、hotfix分支在合并后可以删除，避免分支过多管理混乱
- 每次 pull 代码前，提交本地代码到本地库中，否则可能回出现合并代码出错，导致代码丢失
冲突的场景及解决方案如下
- 多 feature 分支并行开发，在提交测试合并至 develop 分支时，容易出现合并冲突。这就要求各研发人员尽量只修改个人功能代码文件。公共配置或公共依赖包应由单独开发人员维护，按需添加，修改合并后推送到各 feature 分支。
- Hotfix 分支修复的同时有 release 分支功能需要发版上线，合并 master 时容易出现合并冲突。这时按功能生产环境紧急性依次发布上线，发版上线后立即合并 master 并合并到develop分支