目录

Version Management Strategy

https://yqfile.alicdn.com/3b84530723a76268f2a99d3b65b3a354e87fe309.jpeg

为了开发高质量的软件,我们需要能够跟踪所有更改并在必要时将其撤消。 版本控制系统通过跟踪项目历史记录并帮助合并多人所做的更改来填补这一角色,极大地加快了工作速度,并使我们能够更轻松地发现错误。

此外,得益于这些工具,分布式团队可以畅通合作,使多个人可以同时处理项目的不同部分,然后将其结果合并为一个产品。 让我们仔细看看版本控制系统,git-flow 和 Trunk-based development(基于主干的开发)是如何形成的。

版本控制系统是怎样改变世界的

在版本控制系统出现之前,开发人员依靠手动备份项目的先前版本。他们手工复制修改过的文件,以便将多个开发人员的工作合并到同一项目中。 这样的操作花费了大量时间、硬盘空间和 money。

软件的目的是为了更好、更高效的完成工作。工欲善其事必先利其器,那么作为开发者肯定会在产出软件之前对自己的代码进行更有效的管理。

当我们回顾历史时 [1],我们可以大致区分出三代阶段的控制软件。

阶段 操作 并发 存储 工具
1 单文件 锁定文件 集中式 RCS
2 多文件 提交前 merge 集中式 Subversion, CVS
3 多文件 merge 前提交 分布式 Git, Mercurial

我们注意到随着版本控制系统的成熟,并行处理项目的能力成为了趋势。

最具突破性的更改之一是从锁定文件转变为合并更改。它使开发者能够更有效地工作。 另一个重大改进是引入了分布式系统。 Git 是采用这种理念的首批工具之一。 实际上,它使开源世界得以蓬勃发展。 Git 允许开发人员通过称为分叉的操作复制整个存储库,并引入所需的更改,而不必担心合并冲突。

随后,开发者可以创建一个 PR(Pull request),以将其更改合并到原始项目中。 如果最初的开发人员对合并其他存储库中的更改不感兴趣,那么他们可以自己将其转换 (Fork) 为单独的项目。 由于没有中央存储的概念,因此一切皆有可能。

Git-flow

https://i.loli.net/2020/02/23/evmkayH8PSZfoCl.png

在 Git-flow 开发模型中,你有一个主分支 (master branch),从主分支创建开发分支 (develop branch),所有开发工作提交都基于开发分支。主分支和开发分支在 git-flow 的整个生命周期中都是一直存在的。

开发人员从该开发分支创建功能分支 (Feature branch) 并对其进行 Coding。完成后,它们将创建 PR。在审查 (Review) PR 过程中,其他开发人员会对更改发表评论,并可能进行讨论,讨论时间也许会很长。

对 PR 评审完成后,PR 将被接受并 merge 到开发分支。 一旦确定开发分支已经成熟到可以发布,就会创建一个单独的分支 (release branch) 来准备最终版本。 该分支的应用程序已经过测试,并且在准备好将其发布给最终用户之前会应用错误修复 (bugfixs)。 完成此操作后,我们会将最终产品合并到主 (master branch) 分支,并打标签 (Tag)。 同时,可以在 develop 分支上继续开发新功能。 Git 流的优点之一是严格控制。仔细查看更改后,只有授权的开发人员才能批准更改。它可以确保代码质量,并有助于尽早消除错误。

但是,你需要记住,这也可能是一个巨大的劣势。它会形成一个瓶颈,从而减慢软件开发速度。如果速度是你的首要考虑,那么这应该是一个严重的问题。单独开发的功能可以创建长期存在的分支,这些分支可能很难与主项目结合。

此外,PR 仅将代码重点放在新代码上。他们只查看新引入的更改,而不是整体查看代码并进行改进。在某些情况下,它们可能会导致过早的优化,因为总有可能实现某些功能以使其更快地执行。

还有,PR 可能会导致权利泛滥,在这种情况下,牵头开发人员实际上会管理每行代码。如果你有经验丰富的开发人员可以信任,他们可以处理,但是你可能会浪费他们的时间和技能。它还可能严重削弱开发人员的动力。

在较大的组织中,PR 也可能会导致办公室政治或者以权谋私的事情发生。

Git-flow 的适用情况分析

git-flow 在什么时候最有效

  • 当你在运营一个开源项目时

这种场景是开源社区,在这里效果最好。 由于每个人都可以做出贡献,因此你希望能够非常严格地访问所有更改。 你希望能够检查每一行代码,坦率地说,你不能相信贡献者。 通常,这些不是商业项目,因此开发速度不是问题。

  • 当你有很多初级开发人员的时候

如果你主要与初级开发人员一起工作,那么你希望有一种方法来仔细检查他们的工作。 你可以为他们提供更多有关如何更有效地 Coding, 并帮助他们更快地提高编程技能。 接受 PR 的人员对重复发生的更改具有严格的控制权,因此可以防止代码质量下降。

  • 当你已经有现成的产品的时候

当你已经有成功的产品时,这种方式也可以很好地发挥作用。 在这种情况下,通常将重点放在应用程序性能和负载功能上。 这种优化需要非常精确的更改。 通常,时间不是限制,因此这种控制在这里效果很好,尤其大型企业非常适合这种风格(因为他们不想破坏自己数百万的投资,他们需要严密控制每个变更)。

git-flow 会在什么情况下会有问题

  • 当你启动一个新项目时

你可能希望快速创建最小可行的产品 (MVP),提 PR 会产生巨大的瓶颈,这会大大降低整个团队的速度而你负担不起。Git 流程的问题在于,PR 可能会花费很多时间。

  • 当你需要快速迭代

达到产品的第一个版本后,你很可能需要几次调整以满足你客户的需求。 同样,多个分支和 PR 会极大地降低开发速度,因此不建议这样做。

  • 当你与高级开发人员一起工作时

如果你的团队主要由相互合作了较长时间的高级开发人员组成,那么你实际上就不需要上述的 PR 。你应该信任你的开发人员,并且知道他们是专业人士,让他们做好自己的工作,不要让所有 Git-Flow 的流程拖慢开发进度。

Github-flow

https://i.loli.net/2020/02/23/obvq1wuliJNczU9.png

Github-flow 是在 git-flow 的基础上衍生而来的。他简化了 git-flow 的复杂模型,并且与 Github 可以很好的结合,在此就不赘述了。

Trunk-based Development(TBD)

https://i.loli.net/2020/02/23/5JeLIEG2uxNokS4.png

在基于主干的开发模型中,所有开发人员都在一个具有开放访问权限的分支上工作。通常它只是 master 分支。他们将代码提交给它并运行它,非常简单。

在某些情况下,它们会创建短暂的功能分支。 分支上的代码编译并通过所有测试后,便将其直接合并到 master。 它可确保开发真正连续进行,并防止开发人员创建难以解决的合并冲突。

用这种方法检查代码的唯一方法是进行完整的源代码检查。 通常,冗长的讨论是有限的。 没有人能严格控制源代码库中正在修改的内容,这就是为什么拥有可强制执行的代码样式很重要的原因。 以这种风格工作的开发人员应具有丰富的经验,以便你知道他们不会降低源代码的质量。

当你与经验丰富的软件开发人员团队一起工作时,这种工作方式可能会很棒。 它使他们能够快速引入新的改进,而无需不必要的官僚作风。 它还显示了你对它们的信任,因为它们可以将代码直接引入 master 分支。 此工作流程中的开发人员非常自治-他们直接交付并检查工作产品中的最终结果。 这种方法绝对没有办公室管理的微观管理和可能性。

另一方面,如果你没有经验丰富的团队,或者由于某种原因不信任他们,则不应该采用这种方法,而应选择 Git flow。它将为你节省不必要的后顾之忧。

TBD 的适用情况分析

TBD 的适用情况与 git-flow 的适用情况恰好相反,可自行脑补。

我有话说

在我上个项目中,我们的版本控制策略则更激进。

我们所有的开发没有特性分支,所有的 Code 都在 Master 分支上开发,原因有如下:

  • 我们的每张卡都拆的非常细(因为有老 BA)
  • 我们每个人各自负责前端、移动端和后端
  • 最重要的是我们的 CICD 完全一条龙操作,环境有 local、DEV、UAT 和 Prod, 在前一个环境 QA 验证不通过,是进入不到下一个环境的

如果开发速度比较快,有些内容是要在下个版本才要上,那么团队就需要启用 FeatureToggle 了, 关于这部分可参考之前的 《FeatureToggle 引起的。… 总结》

软件开发是一场人、语言和工具的故事,但愿你在合适的场景选择合适的工具。

Refs


https://cdn.staticaly.com/gh/guzhongren/data-hosting@master/20210819/wechat.ae9zxgscqcg.png