Git 工作流规范参考

Posted thyshare

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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 分支,或者创建基于 developrelease 分支。进入到测试环节。

release

  • 并不一定总是存在,但也可以长期的存在,对应测试环境
  • 最初的分支来源是 develop 分支。
  • 每当此分支有新的提交时,可以使用脚本自动构建部署到对应环境中。
  • 不允许直接在此分支上进行修改提交。

相关测试通过后,开始合并到 master 分支,同时合并到 develop 分支,因为期间可能有 bug 修复。接着进入到发布环节。

master

  • 从项目开始就存在的分支,且一直存在,对应生产环境
  • 此分支的代码总是处于发布就绪状态,每发布一次,根据项目版本管理规则,添加一个新的版本号 tag
  • 每当此分支有新的提交时,可以使用脚本自动构建部署到对应环境中。
  • 不允许直接在此分支上进行修改提交。

分支合并

  • merge 指令强制使用 --no-ff 参数,产生对应合并记录,方便回溯。
  • developrelease 分支一般开发人员有合并权限, master 分支合并权限特定人员才能有。

修复 bug 策略

按照上面分支对应的环境,对 bug 进行区分。

测试环境中 bug

  • 基于 release 分支创建修复分支,名称统一前缀 bugfix/
  • 修复 bug 后合并到 release 分支。
  • 该分支一直持续到合并到 master 之前, release 合并到 master 之后就删除该分支。

生产环境中 bug

  • 基于 master 分支创建修复分支,名称统一前缀 hotfix/
  • 修复 bug 后合并到 release 分支,在测试环境进行验证,验证通过后,将此分支分别合并到 masterdevelop
  • 合并后删除该分支。

其它情况处理

上面所说是一个正常的流程,但实际中不会那么理想。可能出现下面的情况。

多版本测试

release 对应测试环境是一个版本,由于时间问题,提前开发的功能分支 feature/function 已完成,需要马上进行测试。

这个时候,可以直接基于 feature/function 分支构建一个单独的测试环境。这个需要在持续构建系统里面花费一定成本。待 release 发布后,按照原有的流程合并即可。

环境同步

一般测试环境和生产环境的数据和配置是相互独立的,有些时候生产的问题无法在测试环境复现,那么处理的方式有:

  • 将生产环境的数据和配置导入到测试环境。
  • 将测试环境的代码部署到单独一个环境,该环境直接使用生产环境的数据和配置,但只允许相关人员访问。

灰度发布

灰度发布的情况,生产上有两套环境,不同的用户在不同的环境。这个时候,可以这么做:

  • 基于 master 创建一个预发布的分支。
  • release 合并到预发布分支中,灰度过后,将预发布分支合并到 master
  • 灰度期间的生产的 bug,可以合并到灰度分支中验证。验证通过后,将修复分支分别合并到 masterdevelop

另外一种思路

以上遵循一个分支对应一个环境的原则,也可以一个分支对应多个环境。例如 develop 分支,构建后,可以部署到两个不同服务器,测试人员在一个环境中使用,开发人员在另外一个环境中使用,也是相互不影响的。这个需要在持续构建工具里面进行相关的配置。

规范参考简化

按照上面的流程,可以发现,分支一旦增加,就少不了创建、合并的操作。有些时候团队开发也就 2、3 个人。那么在这个时候,可以简化的步骤有:

  • 无需创建 feature 分支,直接在 develop 上开发。
  • 无需创建测试环境修复 bug 分支,直接在 release 上修改。
  • 生产环境的 bug ,修复验证后只需合并到 master 。在下个版本合并到 release 之前,统一把 master 合并到 develop 一次。

规范参考增强

随着团队规模的扩张,更加详细的规则变的愈加必要。强化的步骤有:

  • 每个需求开发以一个 issue 开始,描述开发的内容和实现方式,并给相关人员审阅。随后的进度状态都在这个 issue 中反映。
  • 合并分支时一定要经过相关审阅。
  • 增加自动测试环节。
  • 分离构建和部署,测试环境部署权限交给测试部门,生产环境的部署权限交给相关负责人。
  • 在提交到测试、生产的环境前,必需要用邮件的方式告知相关的功能、代码库、配置更改、脚本更改等。评审同意之后才能进行部署。此步骤可以借助相关自动化工具。

参考资料

以上是关于Git 工作流规范参考的主要内容,如果未能解决你的问题,请参考以下文章

团队项目的Git分支管理规范

聊聊git工作流

基于git的代码版本管理规范及流程

Git提交规范

Git提交规范

你可能已经忽略的git commit规范