基于主干的开发与 Git 流程

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

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

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

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

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

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

让我们来看看它们：

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

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

另一个相当大的改进是引入了分布式系统。 Git 是最早融入这一理念的工具之一。 它确实使开源世界蓬勃发展。 Git 允许开发人员在称为分叉的操作中复制整个存储库，并引入所需的更改，而无需担心合并冲突。

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

发展方式

如今，最流行的版本控制系统当属 Git，2016 年市场份额约为 70%。

Git 随着 Linux 的兴起和一般的开源场景而普及。 GitHub 是目前最流行的公共项目在线存储，也是其流行的重要因素。 我们将易于管理的拉取请求的引入归功于 Git。

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

收到反馈后，创建者可以对其做出回应、创建讨论，或者只是跟随它并相应地更改他们的代码。

Git 只是一个工具。 您可以通过许多不同的方式使用它。 目前，您可以遇到的两种最流行的开发风格是 Git 流和基于主干的开发。 很多时候，人们熟悉其中一种风格，而他们可能会忽略另一种风格。

让我们仔细看看它们，并了解我们应该如何以及何时使用它们。

Git 流程

在 Git 流开发模型中，您有一个可以严格访问它的主要开发分支。 它通常被称为develop分支。

开发人员从这个主分支创建功能分支并对其进行处理。 完成后，他们会创建拉取请求。 在拉取请求中，其他开发人员对更改发表评论并可能进行讨论，通常是很长的讨论。

就变更的最终版本达成一致需要一些时间。 一旦达成一致，拉取请求就会被接受并合并到主分支。 一旦确定主分支已经达到足够成熟可以发布，就会创建一个单独的分支来准备最终版本。 来自该分支的应用程序经过测试，并在准备发布给最终用户之前应用错误修复。 完成后，我们将最终产品合并到master分支并使用发布版本对其进行标记。 同时，可以在develop分支上开发新功能。

下面，你可以看到 Git 流程图，描绘了一个一般的工作流程：

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

但是，您需要记住，这也可能是一个巨大的劣势。 它创建了一个减缓软件开发的漏斗。 如果速度是您最关心的问题，那么它可能是一个严重的问题。 单独开发的功能可以创建可能难以与主项目结合的长期分支。

更重要的是，拉取请求仅将代码审查重点放在新代码上。 他们没有将代码视为一个整体并努力改进它，而是只检查新引入的更改。 在某些情况下，它们可能会导致过早的优化，因为总是可以实现一些更快的执行。

此外，拉取请求可能会导致广泛的微观管理，其中首席开发人员实际上管理每一行代码。 如果您有经验丰富的开发人员您可以信任，他们可以处理它，但您可能会浪费他们的时间和技能。 它还可能严重削弱开发人员的积极性。

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

Git Flow 的优缺点

如您所见，执行拉取请求可能并不总是最佳选择。 它们应仅在适当的情况下使用。

Git Flow 什么时候工作得最好？

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

• 当你有很多初级开发人员时。
  如果您主要与初级开发人员一起工作，那么您希望有一种方法可以密切检查他们的工作。 您可以向他们提供有关如何更有效地做事的多种提示，并帮助他们更快地提高技能。 接受拉取请求的人可以严格控制重复性更改，以防止代码质量下降。

  

• 当您拥有成熟的产品时。
  当你已经有一个成功的产品时，这种风格似乎也能很好地发挥作用。 在这种情况下，重点通常是应用程序性能和负载能力。 这种优化需要非常精确的更改。 通常，时间不是约束，所以这种风格在这里很有效。 更何况大型企业非常适合这种风格。 他们需要密切控制每一个变化，因为他们不想破坏他们数百万美元的投资。

Git Flow 何时会导致问题？

• 当你刚刚开始。
  如果您刚刚开始，那么 Git 流程不适合您。 您可能想快速创建一个最小的可行产品。 执行拉取请求会造成巨大的瓶颈，从而大大减慢整个团队的速度。 你根本买不起。 Git 流程的问题在于拉取请求可能需要大量时间。 以这种方式提供快速开发是不可能的。

• 当您需要快速迭代时。
  达到产品的第一个版本后，您很可能需要对其进行几次调整以满足客户的需求。 同样，多个分支和拉取请求会显着降低开发速度，在这种情况下不建议这样做。

• 当您主要与高级开发人员一起工作时。
  如果你的团队主要由长期合作的高级开发人员组成，那么你真的不需要前面提到的 pull request 微管理。 您信任您的开发人员并且知道他们是专业人士。 让他们做他们的工作，不要因为所有的 Git 流程官僚主义而拖慢他们的速度。

基于主干的开发工作流程

在基于主干的开发模型中，所有开发人员都在一个可以开放访问的分支上工作。 通常它只是master分支。 他们向它提交代码并运行它。 超级简单。

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

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

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

当您与经验丰富的软件开发人员团队合作时，这种工作方式会非常棒。 它使他们能够快速引入新的改进，而没有不必要的官僚作风。 它还向他们表明您信任他们，因为他们可以将代码直接引入master分支。 此工作流程中的开发人员非常自主——他们直接交付并检查工作产品中的最终结果。 在这种方法中，办公室政治的微观管理和可能性肯定要小得多。

另一方面，如果您没有经验丰富的团队，或者由于某种原因您不信任他们，那么您不应该使用这种方法——您应该选择 Git 流。 它将为您省去不必要的后顾之忧。

基于主干的开发的优缺点

让我们仔细看看成本的两个方面——最好的和最坏的情况。

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

• 当你刚刚开始。
  如果您正在开发最小可行产品，那么这种风格非常适合您。 它以最少的形式提供最大的开发速度。 由于没有拉取请求，开发人员可以以光速交付新功能。 一定要聘请有经验的程序员。

• 当您需要快速迭代时。
  一旦你到达你的产品的第一个版本并且你注意到你的客户想要一些不同的东西，那么不要三思而后行，并使用这种风格转向一个新的方向。 您仍处于探索阶段，您需要能够尽快更改您的产品。

• 当您主要与高级开发人员一起工作时。
  如果您的团队主要由高级开发人员组成，那么您应该信任他们并让他们完成他们的工作。 此工作流程为他们提供了所需的自主权，并使他们能够掌握自己的专业知识。 只需给他们目标（要完成的任务）并观察您的产品如何发展。

基于主干的开发何时会导致问题？

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

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

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

为正确的工作使用正确的工具

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

Git 流程通过拉取请求管理所有更改。 它为所有更改提供严格的访问控制。 它非常适合开源项目、大型企业、拥有成熟产品的公司或缺乏经验的初级开发人员团队。 您可以安全地检查源代码中引入的内容。 另一方面，它可能导致广泛的微观管理，涉及办公室政治的纠纷，以及发展显着放缓。

基于主干的开发给予程序员充分的自主权，并对他们和他们的判断表达出更多的信心。 访问源代码是免费的，因此您确实需要能够信任您的团队。 它提供了出色的软件开发速度并减少了流程。 这些因素使其在创建新产品或将现有应用程序转向全新方向时变得完美。 如果您主要与经验丰富的开发人员一起工作，它会产生奇迹。

尽管如此，如果您与初级程序员或您不完全信任的人一起工作，Git flow 是一个更好的选择。

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