Git 工作流规范参考

引子

本以为使用 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 中反映。
合并分支时一定要经过相关审阅。
增加自动测试环节。
分离构建和部署，测试环境部署权限交给测试部门，生产环境的部署权限交给相关负责人。
在提交到测试、生产的环境前，必需要用邮件的方式告知相关的功能、代码库、配置更改、脚本更改等。评审同意之后才能进行部署。此步骤可以借助相关自动化工具。

参考资料

原文地址：https://www.cnblogs.com/thyshare/p/12530824.html

时间： 2024-10-03 09:45:05