背景
目前团队在 git 实践上还没有一套统一的规范，且存在以下影响开发效率的情况：
- 不同团队成员对于 git 的使用未达成一致，导致在实际开发协助中需要花费更多额外的时间和精力解决各种意想不到的问题。
- 不同项目间使用的 git 实践也不一致，导致在切换项目时存在一定的上下文损耗，且更容易出错。
因此，亟需一套大家达成一致的通用的 git 实践以解决上述问题，从而提升效率。
为什么使用 git flow ?
结合团队项目的实际情况以及各主流 git 分支模型的特点，推荐使用最为知名且经过大量项目验证的 git flow 模型。
什么是 git flow ？
Git flow是由 Vincent Driessen 于2010年提出的 git branching workflow，主要特点是基于两个 long-live 分支以及一些用于支援开发周期的 supporting 分支进行分支管理。
long-live 分支
主要包含 master 及 develop 这两个存在于整个研发周期的固定分支。
- master 分支：对应的是已经在
生产环境上的代码。 - develop 分支：包含下次将要部署到
production的变更。
当 develop 分支上的代码稳定且可以发版时，其中所有的变更应该通过某种形式（一般是从 develop 分支 checkout out 出对应的 release 分支进行进一步的验证）merge 到 master 分支上，之后再 tag 对应的版本号。
supporting 分支
除了上述 long-live 分支，我们还会使用一些 supporting 分支以支援日常的开发场景。不同于 long-live 分支，supporting 分支都是为了特定的目的而存在，因此这些分支的存活周期是有限的。
我们主要使用的 supporting 分支类型有：
- Feature 分支：从 develop 分支 checkout 出来，用于新功能的开发。
- Release 分支：从 develop 分支 checkout 出来，用于部署到
production前的预发布及验证，另外可以解放 develop 分支以进行后续功能的迭代。 - Hotfix分支：从 master 分支 checkout 出来，用于快速修复
production环境发现的 bug。
Feature 分支
- 只应存在于开发者个人的 repo，不应出现在 upstream repo
- 由 develop 分支 checkout，必须 merge 到 develop 分支
- 命名规范：feat/[ticket-no]-[simple-description]
Release 分支
- 需存在于 upstream repo
- 仅可基于该分支进行 bug fix
- 由 develop 分支 checkout（时机为 develop 分支能反映出下次上 production 的状态），必须 merge 到 master 分支（当有在 release 分支进行 bug fix 时，也必须 merge 回 develop 分支）
- 命名规范：release/[release-no]
- 版本号：
*.0.* -> *.1.0或1.*.* -> 2.0.0
Hotfix 分支
- 只应存在于开发者个人的 repo，不应出现在 upstream repo
- 由 master 分支 checkout，必须 merge 回 develop 分支与 master 分支（若此时存在 release 分支，则应将 hotfix 分支先 merge 到 release 分支，再将 release 分支 merge 回 develop 分支）
- 命名规范：hotfix/[issue-no]-[simple-description]
- 版本号：
*.*.1 -> *.*.2
其他约定
- master, develop, release 分支上的迭代必须通过提 PR 的方式进行，禁止直接修改这些分支。
- 合并 PR 时使用
create a merge commit的方式（因为其他方式会导致丢失被合并分支上的 commit 信息，后续若继续使用此原始分支提交 PR，会导致旧 PR 的改动仍然出现在新 PR 中的情况，详情请参考 github 官方文档）。