lou 发表于 2020-4-23 14:53:42

Geek专栏:一种 Git-Workflow 介绍

本帖最后由 lou 于 2020-4-27 11:12 编辑

Geek专栏:一种 Git-Workflow 介绍


今天Geek专栏为大家带来
乐聚研发部黄怀贤的
“一种Git-Workflow 介绍”

Git-workflow

Git 作为一个自由度极高的软件,在团队配合的时候经常会因为每个人的习惯不同,以及工作流程不同造成一些在使用中不知所措的情况。有人会下结论,这个软件不好用,就走开了。
有些人针对这个情况做了一些尝试,设定了一些规则,进行了实践。总结了一些应用方法,这样一来 Git 的灵活性还在,团队成员根据描述的规则来配合,就很舒适。
一个好的workflow 应该具备以下几个原则:

[*]在团队规模扩大之后仍然能灵活的适应新场景。
[*]当出现问题的时候可以快速的解决和修复,或者回滚。
[*]不应该给原有的工作流程增加负担,和必要的工作内容结合到一起,规则就消失了。变成大家的习惯。
考虑到团队的规模,以及人员的认知负担。我们没有选择 feature-branch 的方式,而是使用了两个主分支(dev,master) 来维护开发流程。

基本要求


[*]要确保发布的软件保持稳定。
[*]能及时修复稳定的软件版本上的紧急问题。
[*]同时能进行新的开发周期的内容。
[*]只测试稳定版本修改内容,正在进行的开发周期开发中的版本不测试。因为整合之前开发人员可能自己会发现一些问题,以及防止测试到不完整的功能。
[*]修复 Bug 的时候可以根据紧急情况来控制修复的代码是立即发布还是等待到下一个版本中发布。
[*]开启新的开发周期之后稳定版出现重大,或者紧急 Bug 能在不影响原有工作的前提下修复问题。

基本规则

分支介绍

dev: 开发分支。在开发周期推进的过程中,代码都合并到 dev。另外一些不紧急,改动比较大的 Bug 修复,也是合并到 dev 中。当前开发周期结束之后,会执行一次 dev 到 master 的合并。开发周期结束之后,会进入一个修复的阶段,此时 dev 就不活跃,所以只需要执行一次 dev 到 master 的合并即可。dev 中挖的坑,在 dev 合并到 master 中之后当成 Bug 修复。
master: 稳定版分支,代表当前最新的稳定版。临时、紧急的 Bug 修复,直接往 Master 上合并。Master 合并测试通过之后,就会进入发布状态。另外当开发周期结束之后,就将 dev 合并到 master 上,此时就产生一个大的版本更新。经过一段时间的测试稳定之后,Master 就可以再次发布。用这种方式来滚动发布稳定版本。正常来说 Master 只在 dev 合并进来之后才会出现频繁的更新,用这种方式来确保 Master 的稳定性。
补充开发周期的概念,我们是参考 https://www.kernel.org/doc/html/v4.15/process/2.Process.html 的方式工作。

Maintainer

每个项目都有一个Maintainer, 他会决定哪些代码是合并到 dev ,哪些代码是合并到 master。并执行 dev 到Master 的合并逻辑

发布软件

当 Master分支有更新并且经过测试确认稳定之后,Maintainer 会打一个 tag。通过这个 tag 的 CI 来自动进行软件发布。不过目前来说 App 的发布还不能完全自动,因为不同的市场都需要单独描述更新的 Changelog,走不同的流程。应该有人在做这种统一发布流程的工具, 只是我还没找到。

总 结

我们是从单master 分支的 workflow 转换到当前这个workflow 的。基本上解决了一些之前开发过程中因为临时性的修改而影响开发流程正常推进的问题。
页: [1]
查看完整版本: Geek专栏:一种 Git-Workflow 介绍