分支说明
master分支
master分支只部署到线上。每次新功能在测试环境验证通过了才可以合并到master分支。要保证master分支就是线上最新代码。
develop分支
用于部署到集成测试环境。
feat/xxx分支
命名规则是：feat/{版本}-{功能点}。feature分支基于最新的master分支拉，开发完毕之后往develop分支合。然后上测试环境即可。
hotfix/xxx分支
用于线上bug，只能从最新的master分支中切出来。
基本原则
- 基本的feature分支开发+MR 的工作流
- 全局一个master分支，为线上稳定分支
- develop分支不能合并入master分支或者hotfix/*分支，否则会污染master和hotfix
- master作为稳定分支，可以随时合并入其他分支
- 避免一个commit中包含跨多个功能模块的改动，提交粒度以 revert 为准，一个commit只做一件事，在需要revert时可省去很多麻烦
- 理论上任何分支可以随时合并最稳定的master分支，但是通常没有必须合并的bug fix、或者必须合并的线上feature，不需要在开发时和提mr前刻意合并master，落后目标分支不会带来代码冲突，反而不当的解决冲突会污染当前开发的feature分支，进而污染每一个该分支合并汇入的下游分支。
举例
需求迭代
- 开发时
基于最新master切出新的功能分支，命名为feat/1.2-new-card。正常进行开发-提交 - 提测时
将自己的feat分支推送到远程，提MR合并到develop分支，期间进行CodeReview。通过后部署至测试环境。
注意：
- develop分支禁止直接推代码。
- 确保测试环境包含线上全部功能。
- 提测中
出现问题在自己的feat分支上修复，完成后推送至远程，提MR合并至develop分支。 - 上线
在feat分支上rebase或者merge 最新master 分支，解决可能的冲突，并推送到远程，提MR合并至master分支，进行CodeReview（此时的review以解决冲突为主） 。合并完成后准备上线。
BugFix
- 测试环境：直接在feat分支上面修复，然后提MR至develop分支。
- 线上环境：从master分支上fork出hotfix/xxx分支，解决后合并至develop分支，验证通过后直接并回master。
MR冲突
- 如果是feature分支往master分支提MR时有冲突，那就从自己分支merge或者rebase最新的master分支，解决完冲突后，再次push。
- 如果是feature分支往develop分支提MR时有冲突，可以尝试自己在本地的目标分支实验性地merge一下，看看与谁的代码有冲突，找到相关人，一起分析冲突的原因。
- 如果是与master分支的冲突。例如feature/1.2-new-card提mr到develop分支，提示有冲突，一种可能的原因是develop已经合并了最新的master分支，而feature/1.2-new-card与master分支有冲突，从而导致了本次mr有冲突，那么这种情况是可以通过feature/order合并最新的master来间接解决与develop的冲突。
- 如果不是，就要在目标分支（一般是develop分支）手动切分支出来，合并源分支解决冲突，并提交至远程，再提MR合并至bata分支。
- 所以，就算feature分支需要合并master，也应该是发生在提MR之后，并且合并master的commit一定是在MR的commits列表中的最新的一条，这样能保证就算你合并master解冲突出了问题，也能很方便地用reset --hard去回滚（如果MR已经被合并）。
Commit message书写规范
一般使用commitlint推荐的约定式提交规范，并且在pre-commit 时校验message的格式，不符合规范的不会提交成功。
其他参考
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow