一套规范的git工作流能让每个开发者都有自己的本地的完整项目副本。隔离的环境使得每个开发都的工作独立于项目的其它修改。 —— 他们可以在自己的本地仓库中添加提交，完全无视上游的开发，直到需要的时候。
一、分支划分及作用
- master —— 主分支，已经发布过生产环境的代码
- release —— 发行分支，需要发行到生产环境的代码
- test —— 测试分支，需要发行到测试环境的代码提
- feature —— 特性分支，也可以通俗的理解为版本分支，项目的本次迭代代码
- dev —— 开发分支，开发者开发时的分支
- fix —— 修复分支，用于紧急处理项目线上问题 和 临时短平快需求
- join —— 联调分支，用于在不干扰测试的情况下与后端联调接口时使用，一般情况下可能用不着。管理办法和测试分支保持一致
二、分支管理流程
为更好的描述管理流程，请先查看下方的流程示意图
流程示意图补充说明：
- 文案 001 表示 序号，一般用数字来表示，依次递增即可；
- 文案 ZhangSan 表示 开发者姓名，也可以使用首字母简称(zs)；
- 在创建 开发分支(dev-001-ZhangSan) 时，开发分支 的 序号 是 继承 特性分支(feature-001) 的 序号 的，可以根据多个开发者创建 多个不同 的 开发分支；
- 有序号的 发行分支(release-001) 是在 特性分支合并前创建的，用于合并主分支和当前迭代分支的代码，在这个环节解决与主分支的冲突；
- 修复分支(fix-002)是在出现线上问题和临时的短平快需求时使用的，修改问题后合并发行分支发布后直接合并到主分支；
- 从实际情况来讲 任何分支都是可以直接 合并 或 创建 测试(test) 分支的；
- 发行分支(release)一般只会从 主分支 和 有序号的发行分支上创建；
- 代码审核一般在 开发分支 向 特性分支 合并时提交，任何向 主分支 合并的代码都需要审核；
工作中的实际流程演示：
【版本迭代场景】
- 版本迭代的分支创建：从 主分支 创建 特性分支，再从特性分支创建 开发分支
- 每日代码同步：每日开发工作结束后开发分支合并到特性分支，原开发分支删除，次日再从特性分支创建开发分支（这样操作是为了同步团队中的最新代码）
- 版本迭代完成时：从 主分支 创建 有版本号的发布分支，将特性分支合并到 有版本号的发布分支(该步骤解决与主分支的代码冲突)，删除原来的发布分支，从有版本号的发布分支新建发布分支(直接创建，不需要重复解决发布分支的冲突问题)，有版本号的发布分支合并到主分支后并删除(版本迭代的分支管理结束)
【线上问题修复】
- 分支创建：从主分支创建 修复分支
- 修复分支代码发布：修复分支合并到发布分支
- 修复分支代码合并：修复分支合并到主分支
看到这里，可能你更关心的是大家的代码如何同步？
代码同步简单粗暴的解决办法：开发者每天下班前将代码提交到 个人开发分支 后合并到 特性分支， 每天上班前从 特性分支 重新创建 个人开发分支。如果是工作时间有需要代码同步则是一样的操作流程即可。
三、 git commit 日志规范
有了好的管理流程后，配合优秀的日志规范就更完美啦。
格式：类型(模块):具体事项，一般类型为功能新增(feat)，修改和删除(fix)。。类型搞太多(增删改全来一遍)意义不大。
示例
// 新增代码
git commit -m 'feat(登录):接口联调'// 修改代码
git commit -m 'fix(注册):已注册用户跳转逻辑完善'// 删除代码
git commit -m 'fix(首页):删除已废弃的相关静态资源'// 如果功能过于复杂有子模块需要补充时也可以套用如上格式
git commiit -m 'fix(个人中心-帐号安全):帐号退出异常问题修复'作者：黄河爱浪
本文原创，著作权归作者所有，转载请注明原链接及出处
