为了开发高质量的软件, 我们需要能够跟踪所有的变化，并在必要时逆转它们. 版本控制系统通过跟踪项目历史和帮助合并多人所做的更改来填补这个角色. 它们大大加快了工作速度，使我们能够更容易地找到bug.

此外，在分布式团队中工作主要要感谢这些工具. 它们使几个人能够同时在一个项目的不同部分工作，然后将他们的结果合并到一个产品中. 让我们进一步了解版本控制系统，并解释基于主干的开发和Git流是如何产生的.

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

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

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

当我们 看看历史，我们可以大致区分三代版本控制软件.

让我们来看看它们:

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

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

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

之后，他们可以启动一个pull请求，以便将他们的更改合并到原始项目中. 如果最初的开发人员对合并来自其他存储库的这些更改不感兴趣, 然后他们可以把它们变成独立的项目. 由于没有中央存储的概念，这一切都成为可能.

开发风格

现在, 最流行的版本控制系统绝对是Git, 2016年的市场份额约为70%.

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

简单地说, 拉请求是由软件开发人员创建的请求，用于将他们创建的更改与主项目结合起来. 它包括一个审查这些变化的过程. 审稿人可以在他们认为可以改进或认为不必要的任何地方插入评论.

收到反馈后, 创造者可以对此做出回应, 创建讨论, 或者简单地遵循它并相应地更改他们的代码.

Git仅仅是一个工具. 你可以用很多不同的方式来使用它. 目前，您可能遇到的两种最流行的开发风格是 Git流 和 trunk-based发展. 通常，人们对其中一种风格很熟悉，而忽略了另一种.

让我们仔细看看 两个都是 并学习如何以及何时使用它们.

Git流

在Git流开发模型中，您有一个对其具有严格访问权限的主要开发分支. 它通常被称为 开发 分支.

开发人员从这个主分支创建功能分支并对其进行处理. 一旦完成，它们就会创建拉请求. 拉取请求, 其他开发人员对更改发表评论并可能进行讨论, 通常都很长.

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

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

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

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

更重要的是，pull请求只关注新代码的代码审查. 而不是把代码作为一个整体来看待，并努力改进它, 它们只检查新引入的更改. 在某些情况下，它们可能会导致 过早优化 因为总是有可能实现一些更快执行的东西.

此外, Pull请求可能导致广泛的微观管理, 由首席开发人员管理每一行代码. 如果你有经验丰富的开发者，你可以信任, 他们能处理好, 但你可能在浪费他们的时间和技能. 它还会严重削弱开发人员的积极性.

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

Git流的优缺点

正如您所看到的，进行拉取请求可能并不总是最好的选择. 它们应该只在适当的地方使用.

什么时候Git流工作最好?

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

• 当你有很多初级开发人员时.
  如果您主要与初级开发人员一起工作，那么您希望有一种方法来密切检查他们的工作. 你可以给他们多种提示，告诉他们如何更有效地做事，帮助他们更快地提高技能. 接受拉取请求的人对反复出现的更改有严格的控制，这样他们就可以防止代码质量恶化.

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

什么时候Git流会导致问题?

• 当你刚起步的时候.
  如果您刚刚起步，那么Git流不适合您. 你可能想要快速创造一个最小可行的产品. 拉取请求造成了巨大的瓶颈，极大地降低了整个团队的速度. 你根本负担不起. Git流的问题在于，pull请求可能会花费很多时间. 以这种方式提供快速发展是不可能的.

• 当你需要快速迭代时.
  一旦你达到了产品的第一个版本, 你很可能需要调整几次来满足客户的需求. 再一次。, 多个分支和拉取请求会显著降低开发速度，在这种情况下不建议这样做.

• 当你主要与高级开发人员一起工作时.
  如果你的团队主要由高级开发人员组成，他们彼此合作了很长时间, 那么你就不需要前面提到的pull request微管理了. 你信任你的开发者，知道他们是专业人士. 让他们做自己的工作，不要让Git流程的官僚作风拖慢他们的速度.

基于主干的开发流程

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

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

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

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

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

If, 另一方面, 你没有一个经验丰富的团队，或者你出于某种原因不信任他们, 您不应该使用这种方法—您应该选择Git流. 这会省去你不必要的烦恼.

基于主干的开发的利弊

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

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

• 当你刚起步的时候.
  如果你正在做你的最小可行产品，那么这种风格对你来说是完美的. 它以最少的形式提供最大的开发速度. 由于没有拉取请求，开发人员可以以光速交付新功能. 只是要确保雇佣有经验的程序员.

• 当你需要快速迭代时.
  一旦你完成了产品的第一个版本，你注意到你的客户想要一些不同的东西, 然后不要犹豫，用这种风格转向一个新的方向. 你仍然处于探索阶段，你需要能够尽快改变你的产品.

• 当你主要与高级开发人员一起工作时.
  如果你的团队主要由高级开发人员组成, 那么你应该相信他们，让他们做好自己的工作. 这个工作流程给了他们所需的自主权，使他们能够掌握自己的专业知识. 只要给他们目标(要完成的任务)，然后观察你的产品如何发展.

基于主干的开发何时会产生问题?

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

• 当你有很多初级开发人员时.
  如果你雇佣的大多是初级开发人员，那么最好严格控制他们的工作. 严格的pull请求将帮助他们提高技能，并更快地发现潜在的漏洞.

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

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

如前所述，Git只是一个工具. 像所有其他工具一样，它需要被恰当地使用.

Git流通过拉请求管理所有更改. 它为所有更改提供严格的访问控制. 这对于开源项目来说非常棒, 大型企业, 有既定产品的公司, 或者是一群没有经验的初级开发人员. 您可以安全地检查源代码中引入的内容. 另一方面, 这可能会导致广泛的微观管理, 办公室政治纠纷, 发展速度明显变慢.

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

仍然, 如果你和初级程序员或你不完全信任的人一起工作, Git流是一个更好的选择.

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