目录
引子
本以为使用 Git 的工作流规范已经很普遍了，发现事实并不是那样。找了些资料，结合实际的工作情况，尝试整理出一个规范。
介绍
Git 工作流是一个如何使用 Git 以一致和高效的方式来完成工作的建议。在 Git 管理的项目中与团队合作时，确保团队对如何应用工作流达成一致意见是很重要的。在看下面介绍的内容时，请记住，这些工作流是一个指导原则，而不是具体的规则。可以根据自身实际情况进行相应调整。
什么是成功的 Git 工作流
当评估团队工作流时，考虑团队的文化是很重要的一件事。你希望工作流提高团队的效率，而不是成为限制生产力的负担。当评估时可以考虑的事情：
- 此工作流是否随团队规模而扩展？
- 此工作流是否可以轻松撤消失误和错误？
- 此工作流是否会给团队带来任何新的不必要的认知开销？
下面就来比较一下常见的 Git 工作流。
Git 工作流
详细介绍见 Git branching model 。
优点：
- 很早就提出，很多人多少了解点这套流程。
- 分支作用明确，相互独立，减少了意外发布到线上的情况。
- 总有一个可以马上发布到线上的分支。
缺点：
- 接受成本相对较高。
- 当项目开发规模扩大复杂后，可能会同时出现开发、待发布、热修复、发布交叉的情况，这个时候可能会相互牵制，容易混淆。
- 分支相对过多，发布到线上整个构建周期相对较长。
GitHub 工作流
详细介绍见 GitHub flow 。
优点：
- 主要有
feature分支和master，发布到线上更加简化。 - 修复问题可以直接在
feature上持续进行，减少了一些合并提交的开销。 - 总有一个可以马上发布到线上的分支。
缺点：
- 在
feature合并到master之前，feature分支需要发布到一个线上环境验证，也就是说可能同时存在多个线上环境，这可能需要额外的开销。 - 开发的功能很多时，合并到
master时相互之间出现冲突可能性更高。
GitLab 工作流
详细介绍见 GitLab Flow 。
优点：
- 相对灵活，可以马上发布上线，可以增加或减少发布之前的步骤。
- 着重使用
issue跟踪的方式，减轻了项目管理上的工作，让每一个开发人员能够有意识自我管理。 - 文档中说明涉及的方面相对比较全面。
- 总有一个可以马上发布到线上的分支。
缺点：
- 由于相对灵活，没有一些统一的硬性规定，分支和环境的管理就会相对复杂一些。
- 强调与 GitLab 平台的结合，如果换了其它平台，可能需要一些转换成本。
- 希望适应更多的情况，也给出了多种情况的示例，过多选择，导致需要再次考虑，反而会产生没有通用遵循规范的感觉。
规范参考
根据上面的几种工作流，以及个人在实际工作中碰到的情况，对于规范有下面的一些想法。
下面以环境功能作为一个切入点开始。
环境划分
一般有开发环境、测试环境、生产环境，下面说下每个环境的特点。
开发环境
主要用于开发，例如接口调试。这个环境中的代码变化最为频繁。可能有以下的形式：
- 开发人员自己使用的电脑就是一个开发环境。
- 有单独的服务器部署，一般都有相应的持续构建。
测试环境
主要用于测试，这个环境中代码相对稳定，一般都是有单独的服务器部署。测试和开发会出现并行的情况，因此未正常运行的代码通常不允许进入到这个环境中，以免影响测试。测试的类型可能有：
- 新功能开发后的人工测试。
- 提供第三方进行对接或验收。
生产环境
用于线上对外访问，这个时候就是真实用户的环境。只有特定的人员会有相关代码访问权限。
分支策略
整体上跟 Git 工作流中分支策略差不多。原则是每一个分支对应一个特定环境。
develop
- 从项目开始就存在的分支，且一直存在，对应开发环境。
- 每开发一个新功能时，都是基于此分支创建对应的
feature分支，名称统一前缀feature/。开发完成后，经过确认会进行发布的feature，才能合并到此分支。合并后删除feature分支。 - 每当有新的提交到此分支时，可以使用脚本自动构建部署到对应环境中。
- 可以直接在此分支上进行修改提交。
待确认 develop 分支运行正常后，就可以合并到 release 分支，或者创建基于 develop 的 release 分支。进入到测试环节。
release
- 并不一定总是存在，但也可以长期的存在，对应测试环境。
- 最初的分支来源是
develop分支。 - 每当此分支有新的提交时，可以使用脚本自动构建部署到对应环境中。
- 不允许直接在此分支上进行修改提交。
相关测试通过后，开始合并到 master 分支，同时合并到 develop 分支，因为期间可能有 bug 修复。接着进入到发布环节。
master
- 从项目开始就存在的分支，且一直存在，对应生产环境。
- 此分支的代码总是处于发布就绪状态，每发布一次，根据项目版本管理规则，添加一个新的版本号
tag。 - 每当此分支有新的提交时，可以使用脚本自动构建部署到对应环境中。
- 不允许直接在此分支上进行修改提交。
分支合并
merge指令强制使用--no-ff参数，产生对应合并记录，方便回溯。develop和release分支一般开发人员有合并权限，master分支合并权限特定人员才能有。
修复 bug 策略
按照上面分支对应的环境，对 bug 进行区分。
测试环境中 bug
- 基于
release分支创建修复分支，名称统一前缀bugfix/。 - 修复 bug 后合并到
release分支。 - 该分支一直持续到合并到
master之前，release合并到master之后就删除该分支。
生产环境中 bug
- 基于
master分支创建修复分支，名称统一前缀hotfix/。 - 修复 bug 后合并到
release分支，在测试环境进行验证，验证通过后，将此分支分别合并到master和develop。 - 合并后删除该分支。
其它情况处理
上面所说是一个正常的流程，但实际中不会那么理想。可能出现下面的情况。
多版本测试
release 对应测试环境是一个版本，由于时间问题，提前开发的功能分支 feature/function 已完成，需要马上进行测试。
这个时候，可以直接基于 feature/function 分支构建一个单独的测试环境。这个需要在持续构建系统里面花费一定成本。待 release 发布后，按照原有的流程合并即可。
环境同步
一般测试环境和生产环境的数据和配置是相互独立的，有些时候生产的问题无法在测试环境复现，那么处理的方式有：
- 将生产环境的数据和配置导入到测试环境。
- 将测试环境的代码部署到单独一个环境，该环境直接使用生产环境的数据和配置，但只允许相关人员访问。
灰度发布
灰度发布的情况，生产上有两套环境，不同的用户在不同的环境。这个时候，可以这么做：
- 基于
master创建一个预发布的分支。 release合并到预发布分支中，灰度过后，将预发布分支合并到master。- 灰度期间的生产的 bug，可以合并到灰度分支中验证。验证通过后，将修复分支分别合并到
master和develop。
另外一种思路
以上遵循一个分支对应一个环境的原则，也可以一个分支对应多个环境。例如 develop 分支，构建后，可以部署到两个不同服务器，测试人员在一个环境中使用，开发人员在另外一个环境中使用，也是相互不影响的。这个需要在持续构建工具里面进行相关的配置。
规范参考简化
按照上面的流程，可以发现，分支一旦增加，就少不了创建、合并的操作。有些时候团队开发也就 2、3 个人。那么在这个时候，可以简化的步骤有：
- 无需创建
feature分支，直接在develop上开发。 - 无需创建测试环境修复 bug 分支，直接在
release上修改。 - 生产环境的 bug ，修复验证后只需合并到
master。在下个版本合并到release之前，统一把master合并到develop一次。
规范参考增强
随着团队规模的扩张，更加详细的规则变的愈加必要。强化的步骤有：
- 每个需求开发以一个
issue开始，描述开发的内容和实现方式，并给相关人员审阅。随后的进度状态都在这个issue中反映。 - 合并分支时一定要经过相关审阅。
- 增加自动测试环节。
- 分离构建和部署，测试环境部署权限交给测试部门，生产环境的部署权限交给相关负责人。
- 在提交到测试、生产的环境前，必需要用邮件的方式告知相关的功能、代码库、配置更改、脚本更改等。评审同意之后才能进行部署。此步骤可以借助相关自动化工具。