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