基于中继的开发与Git Flow

本文概述

• 版本控制系统如何改变世界
• 发展风格
• Git流
• Git Flow的优缺点
• 基于主干的开发流程
• 基于主干的开发的利与弊
• 使用合适的工具完成合适的工作

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

此外, 主要得益于这些工具, 可以在分布式团队中工作。它们使多个人可以同时处理项目的不同部分, 然后将其结果合并为一个产品。让我们仔细看看版本控制系统, 并说明基于主干的开发和Git流是如何形成的。

版本控制系统如何改变世界

在创建版本控制系统之前, 人们依靠手动备份项目的先前版本。他们手工复制修改过的文件, 以便将多个开发人员的工作合并到同一项目中。

它花费了大量时间, 硬盘空间和金钱。

当我们回顾历史时, 我们可以大致区分三代版本控制软件。

让我们看看它们：

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

最具突破性的更改之一是从锁定文件转变为合并更改。它使程序员能够更有效地工作。

另一个重大改进是引入了分布式系统。 Git是采用这种理念的首批工具之一。从字面上看, 它使开源世界得以蓬勃发展。 Git允许开发人员通过称为分叉的操作复制整个存储库, 并引入所需的更改, 而不必担心合并冲突。

稍后, 他们可以启动拉取请求, 以将其更改合并到原始项目中。如果最初的开发人员对合并其他存储库中的更改不感兴趣, 那么他们可以自己将其转换为单独的项目。由于没有中央存储的概念, 因此一切皆有可能。

发展风格

如今, 最受欢迎的版本控制系统肯定是Git, 2016年其市场份额约为70％。

随着Linux的兴起和一般开源环境的出现, Git受到了广泛的欢迎。 GitHub是当前最受欢迎的公共项目在线存储, 也是其流行的一个重要原因。我们应该向Git引入易于管理的请求请求。

简而言之, 拉取请求是由软件开发人员创建的将其创建的更改与主项目结合在一起的请求。它包括审查这些更改的过程。审阅者可以在他们认为可以改进的每一个地方插入评论, 或者认为是不必要的。

收到反馈后, 创建者可以对其进行响应, 创建讨论, 或者只是关注它并相应地更改其代码。

Git仅仅是一种工具。你可以通过多种不同方式使用它。当前, 你可以遇到的两种最流行的开发样式是Git流和基于主干的开发。人们经常会熟悉其中一种样式, 而可能会忽略另一种样式。

让我们仔细研究一下两者, 并了解如何以及何时使用它们。

Git流

在Git流开发模型中, 你有一个主开发分支, 可以对其进行严格访问。通常称为开发分支。

开发人员从该主分支创建功能分支并对其进行处理。完成后, 它们将创建拉取请求。在请求请求中, 其他开发人员会对更改发表评论, 并可能进行讨论, 讨论时间通常很长。

同意最终版本的更改需要花费一些时间。商定后, 拉取请求将被接受并合并到主分支。一旦确定主分支已经成熟到可以发布, 就会创建一个单独的分支来准备最终版本。该分支机构的应用程序已经过测试, 并且在准备好将其发布给最终用户之前会应用错误修复。完成此操作后, 我们会将最终产品合并到master分支, 并用发行版标记它。同时, 可以在开发分支上开发新功能。

在下面, 你可以看到Git流程图, 它描述了一般的工作流程：

Git流的优点之一是严格控制。仔细查看更改后, 只有授权的开发人员才能批准更改。它可以确保代码质量, 并有助于尽早消除错误。

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

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

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

在较大的组织中, 拉动请求期间的办公室政治是另一个问题。可以想象, 批准拉取请求的人可能会利用自己的位置故意阻止某些开发人员对代码库进行任何更改。他们可能会因为缺乏信心而这样做, 而有些人可能会滥用其职位来解决个人分数。

Git Flow的优缺点

如你所见, 执行拉取请求可能并不总是最佳选择。仅在适当的地方使用它们。

Git Flow什么时候最有效？

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

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

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

Git Flow何时会引起问题？

• 当你刚刚启动时。
  如果你只是启动, 那么Git flow不适合你。你可能希望快速创建最小可行的产品。提出请求会产生巨大的瓶颈, 这会大大降低整个团队的速度。你负担不起。 Git流程的问题在于, 拉取请求可能会花费很多时间。那样不可能提供快速的发展。

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

• 当你主要与高级开发人员一起工作时。
  如果你的团队主要由相互合作了较长时间的高级开发人员组成, 那么你实际上就不需要上述的请求请求微管理。你信任你的开发人员, 并且知道他们是专业人士。让他们做好自己的工作, 不要让所有Git Flow官僚机构放慢脚步。

基于主干的开发流程

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

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

让我们看一下基于主干的开发工作流程。

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

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

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

基于主干的开发的利与弊

让我们仔细研究一下成本的两个方面-最好的情况和最坏的情况。

什么时候基于主干的开发效果最好？

• 当你刚刚启动时。
  如果你正在开发最低限度的可行产品, 那么此样式非常适合你。它以最小的形式提供了最快的开发速度。由于没有拉取请求, 开发人员可以以光速交付新功能。只要确保雇用有经验的程序员即可。

• 当你需要快速迭代时。
  当你到达产品的第一个版本时, 你发现客户希望有所不同, 那么就不要三思而后行, 并使用这种风格向新的方向发展。你仍处于探索阶段, 你需要能够尽快更改产品。

• 当你主要与高级开发人员一起工作时。
  如果你的团队主要由高级开发人员组成, 那么你应该信任他们并让他们完成工作。该工作流程为他们提供了所需的自主权, 并使他们能够掌握自己的专业知识。只需给他们目标(要完成的任务)并观察产品的增长方式即可。

基于主干的开发何时会引起问题？

• 当你运行一个开源项目时。
  如果你正在运行一个开源项目, 那么Git flow是更好的选择。你需要对变更进行非常严格的控制, 并且你不能信任贡献者。毕竟, 任何人都可以做出贡献。包括在线巨魔。

• 当你有很多初级开发人员时。
  如果你主要雇用初级开发人员, 那么最好严格控制他们的工作。严格的拉取请求将帮助他们提高技能, 并更快地发现潜在的错误。

• 建立产品或管理大型团队时。
  如果你已经拥有繁荣的产品或在大型企业中管理大型团队, 那么Git flow可能是一个更好的主意。你想对价值数百万美元的成熟产品所发生的事情进行严格控制。应用程序性能和负载功能可能是最重要的。这种优化需要非常精确的更改。

使用合适的工具完成合适的工作

如我之前所说, Git只是一种工具。像所有其他工具一样, 它需要适当使用。

Git流通过拉取请求管理所有更改。它提供对所有更改的严格访问控制。非常适合开源项目, 大型企业, 拥有成熟产品的公司或经验不足的初级开发人员团队。你可以安全地检查源代码中引入了什么。另一方面, 这可能会导致广泛的微观管理, 涉及办公室政治的纠纷, 并显着减慢发展速度。

基于主干的开发为程序员提供了充分的自主权, 并对他们及其判断表达了更多的信心。免费获取源代码, 因此你确实需要能够信任你的团队。它提供了出色的软件开发速度并减少了流程。这些因素使它在创建新产品或使现有应用程序向全新方向发展时非常理想。如果你主要与经验丰富的开发人员一起工作, 它会产生奇迹。

不过, 如果你与初级程序员或不完全信任的人一起工作, 那么Git flow是一个更好的选择。

有了这些知识, 我希望你能够选择与你的项目完全匹配的工作流程。