gitflow开发流程_基于中继的开发与GitFlow

git flow开发流程

注意&＃xff1a;我最初是在Toptal博客上发表此文章的。

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

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

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

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

它花费了大量时间&＃xff0c;硬盘空间和金钱。

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

让我们看看它们&＃xff1a;

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

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

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

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

发展风格

如今&＃xff0c;最受欢迎的版本控制系统肯定是Git&＃xff0c;2016年的市场份额约为70&＃xff05;。

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

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

收到反馈后&＃xff0c;创建者可以对其进行响应&＃xff0c;创建讨论&＃xff0c;或者简单地关注它并相应地更改其代码。

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

让我们仔细看看它们&＃xff0c;并学习如何以及何时使用它们。

Git流

在Git流开发模型中&＃xff0c;您有一个主要的开发分支&＃xff0c;可以对其进行严格访问。 通常称为开发分支。

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

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

在下面&＃xff0c;您可以看到Git流程图&＃xff0c;其中描述了一般的工作流程&＃xff1a;

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

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

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

此外&＃xff0c;拉取请求可能会导致广泛的微管理&＃xff0c;在这种情况下&＃xff0c;首席开发人员可以从字面上管理每行代码。 如果您有经验丰富的开发人员可以信任&＃xff0c;他们可以信任他们&＃xff0c;但是您可能会浪费他们的时间和技能。 它还可能严重削弱开发人员的动力。

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

Git Flow的优缺点

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

Git Flow什么时候最有效&＃xff1f;

• 当您运行一个开源项目时。
  这种风格来自开源世界&＃xff0c;在这里效果最好。 由于每个人都可以做出贡献&＃xff0c;因此您希望能够非常严格地访问所有更改。 您希望能够检查每一行代码&＃xff0c;因为坦率地说&＃xff0c;您不能相信贡献人员。 通常&＃xff0c;这些不是商业项目&＃xff0c;因此开发速度不是问题。
• 当您有很多初级开发人员时。
  如果您主要与初级开发人员一起工作&＃xff0c;那么您希望有一种方法来仔细检查他们的工作。 您可以向他们提供有关如何更有效地做事并帮助他们更快地提高技能的多种提示。 接受请求请求的人员对重复发生的更改具有严格的控制权&＃xff0c;因此可以防止代码质量下降。
• 当您拥有既定产品时。
  当您已经拥有成功的产品时&＃xff0c;这种样式似乎也可以很好地发挥作用。 在这种情况下&＃xff0c;通常将重点放在应用程序性能和负载功能上。 这种优化需要非常精确的更改。 通常&＃xff0c;时间不是限制&＃xff0c;因此此样式在这里效果很好。 而且&＃xff0c;大型企业非常适合这种风格。 他们需要严密控制每个变更&＃xff0c;因为他们不想破坏他们数百万美元的投资。

Git Flow何时会引起问题&＃xff1f;

• 当您刚刚启动时。
  如果您只是启动&＃xff0c;那么Git flow不适合您。 您可能希望快速创建最小可行的产品。 提出请求会产生巨大的瓶颈&＃xff0c;这会大大降低整个团队的速度。 您根本买不起。 Git流程的问题在于&＃xff0c;拉取请求可能会花费很多时间。 这样就不可能提供快速的开发。
• 当您需要快速迭代时。
  达到产品的第一个版本后&＃xff0c;您很可能需要将其旋转几次才能满足客户的需求。 同样&＃xff0c;多个分支和请求请求会极大地降低开发速度&＃xff0c;因此不建议这样做。
• 当您主要与高级开发人员一起工作时。
  如果您的团队主要由相互合作了较长时间的高级开发人员组成&＃xff0c;则您实际上并不需要上述的请求请求微管理。 您信任您的开发人员&＃xff0c;并且知道他们是专业人士。 让他们做好自己的工作&＃xff0c;不要让所有的Git Flow官僚机构放慢脚步。

基于中继的开发流程

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

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

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

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

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

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

基于主干的开发的利与弊

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

什么时候基于主干的开发效果最好&＃xff1f;

• 当您刚刚启动时。
  如果您正在开发最低限度的可行产品&＃xff0c;那么此样式非常适合您。 它以最少的形式提供了最快的开发速度。 由于没有拉取请求&＃xff0c;开发人员可以以光速交付新功能。 只要确保雇用有经验的程序员即可。
• 当您需要快速迭代时。
  当您到达产品的第一个版本时&＃xff0c;您发现客户想要一些不同的东西&＃xff0c;那么就不要三思而后行&＃xff0c;并使用这种风格向新的方向发展。 您仍处于探索阶段&＃xff0c;需要能够尽快更改产品。
• 当您主要与高级开发人员一起工作时。
  如果您的团队主要由高级开发人员组成&＃xff0c;那么您应该信任他们并让他们完成工作。 该工作流程为他们提供了所需的自主权&＃xff0c;并使他们能够掌握自己的专业知识。 只需给他们目标&＃xff08;要完成的任务&＃xff09;并观察您的产品如何增长。

基于主干的开发何时会引起问题&＃xff1f;

• 当您运行一个开源项目时。
  如果您正在运行一个开源项目&＃xff0c;那么Git flow是更好的选择。 您需要对变更进行非常严格的控制&＃xff0c;并且您不能信任贡献者。 毕竟&＃xff0c;任何人都可以做出贡献。 包括在线巨魔。
• 当您有很多初级开发人员时。
  如果您主要雇用初级开发人员&＃xff0c;那么最好严格控制他们的工作。 严格的拉取请求将帮助他们提高技能&＃xff0c;并更快地发现潜在的错误。
• 建立产品或管理大型团队时。
  如果您已经拥有繁荣的产品或在大型企业中管理大型团队&＃xff0c;那么Git flow可能是一个更好的主意。 您想对价值数百万美元的成熟产品所发生的事情进行严格控制。 应用程序性能和负载功能可能是最重要的。 这种优化需要非常精确的更改。

使用正确的工具完成正确的工作

如前所述&＃xff0c;Git只是一种工具。 像所有其他工具一样&＃xff0c;它需要适当使用。

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

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

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

有了这些知识&＃xff0c;我希望您能够选择与您的项目完全匹配的工作流程。

了解基础

什么是软件主干&＃xff1f;

在软件开发领域&＃xff0c;“主干”是指版本控制系统下的主要开发分支。 这是项目的基础&＃xff0c;所有改进都被合并到一起。

什么是代码分支和合并&＃xff1f;

分支是从基础项目创建的&＃xff0c;目的是开发新功能&＃xff0c;修复错误或仅进行一些重构。 它们可防止软件开发人员相互干扰&＃xff0c;并使他们能够并行工作。 更改完成并经过测试后&＃xff0c;分支将合并回主干。

什么是版本控制中的分支&＃xff1f;

版本控制系统中的分支是基础项目的副本。 创建它是为了使更改可以在其他分支之间并行发生。 它从根本上解决了同时处理相同文件的问题。

什么是功能分支&＃xff1f;

功能分支具有明确且高度集中的目的-为项目添加特定功能。 它不应包含任何其他可修复错误&＃xff0c;引入其他功能或属于重构的更改。

什么是版本控制系统&＃xff1f;

版本控制系统跟踪项目中文件中发生的更改。 它们可以在以后被召回或查看。 对于恢复以前的版本也非常有用。 这使开发人员可以更轻松地查找错误&＃xff0c;因为他们可以看到并跟踪发生的所有更改。

翻译自: https://hackernoon.com/trunk-based-development-vs-git-flow-b1b23044dfb

git flow开发流程