|
作者:佚名
时间:2020-03-21 03:00:00
浏览:2614
|
|
|
<p>Git-flow 是一种分支和合并方法。十年前，因为一篇名为「一个成功的 Git 分支模型」的文章，Git-flow 变得广为人知。</p><p>在过去的十年里，无数团队被这篇博文蒙在鼓里。但我敢说，这篇文章撒谎了。</p><p>如果你读过这篇博文，你就会注意到，尽管作者声称他们在项目中成功使用了 Git-flow ，但却故意避开了让项目成功的细节。</p><p>很多人会相信看到的博文，这其实是错误的。并非所有的策略都适用于所有情况，这是一个真理。我将同样的逻辑应用于这个分支模型。</p><p>好吧，你们当中的一些人不相信这个真理，所以让我们深入研究为什么 Git-flow 分支模型应该葬身火海。</p><p><strong>Git-flow 的界面很复杂</strong></p><p>Git-flow 特别复杂，甚至在考虑微服务或连续交付之前就已经如此了。下面的直观地展示了这一点：<br/></p><p><img alt="抛弃 Git Flow 的 8 大理由" src="static.leiphone.com/uploads/new/images/20200318/5e71bb3be567d.png?imageView2/2/w/740"/></p><p>来源：nvie.com/posts/a-successful-git-branching-model/</p><p>这里有特性分支、发布分支、master 分支、dev 分支、一个紧急修复分支和 git 标记。这些都是在构建和发布过程中必须跟踪、理解和考虑的事情。</p><p>更重要的是，你还需要随时跟踪每个分支，这造成了很高的认知负荷。我已经使用 git 10 年了，我甚至不确定自己是否能在精神上跟上这里的发展。</p><p><strong>Git-flow 违反了「短命」分支规则</strong><br/></p><p>在 git 中，随着在某个分支上工作人数的增加，发生合并冲突的次数将大大增加。在 Git-flow 中，这个数字增加得更多，因为还有三个具有不同生命周期的其他分支合并到中：特性分支、发布分支和紧急修复。合并冲突发生的可能性并不是线性变化的，它可能会使合并冲突的概率增加三倍。<br/></p><p>这太糟糕了。<br/></p><p>虽然我不敢说不采用 Git-flow 这样的分支策略就可以避免合并冲突，但是当所有这些分支组合在一起时，引入的潜在复杂性太大了，无法忽略。如果你们公司的代码提交速度很慢，那就没关系。但是对于任何快速迭代的组织或初创企业来说，情况并非如此。<br/></p><p><strong>Git-flow 放弃了 rebase</strong></p><p>重新合并节点是一个复杂的话题，但它很重要。如果你使用 Git-flow，你将不得不放弃 rebase。记住，rebase 取消了合并提交，你再也看不到两个分支组合在一起的节点。由于 Git-flow 的视觉复杂性，你需要可视化地跟踪分支，这意味着如果你想解决问题，就不需要 rebase。<br/></p><p><strong>Git-flow 使连续交付变得不可能</strong></p><p>持续交付是一种实践。在这种实践中，团队以自动化的方式直接发布到生产中（实际上是合并到 master）。看看混乱的 Git-flow，你能解释一下如何持续地交付吗？</p><p>整个分支模型是根据可的、长期的发布周期进行的。如果每隔几分钟或几小时发布一次新代码，开销就太大了，更不用说 CD 的中心实践之一是向前滚动修复。Git-flow将修补程序视为一个单独的实体，需要小心地控制，并与其他工作分离开来。<br/></p><p><strong>在多个存储库中不可能使用 Git-flow</strong></p><p>随着微服务的出现，micro-repo 的理念也得到了更多的推动，各个团队可以控制他们的存储库和工作流，他们还可以控制谁进入了他们的存储库以及其工作流是如何工作的。</p><p>你有没有尝试过这样一个复杂的分支模型：它有多个团队，并且希望它们都在同一个页面上？这是不会发生的。很快，这个系统就变成了不同 repo 的不同版本的一个清单，只有敲出 YAML 来更新清单的人知道所有东西在哪里。如果你不够细心，「在生产什么」就变成了一个存在主义的问题。<br/></p><p><strong>Git-flow 也不可能在 monorep 中使用</strong><br/></p><p>因此，如果由于协调发布的困难而取消了 micro-repo，那为什么不让所有微服务团队都遵守一个大的发布分支工作流呢？</p><p>这个过程大约持续 3.2 秒。如果团队是的，micro-repo 应该是部署的，这样就不能很好地将你的工作流程与你在 mono repo 中创建的集中式分支模型联系起来。</p><p><strong>谁应该/不应该使用 Git-flow？</strong><br/></p><p>如果你的团队每月或每季度发布一次，并且是一个并行处理多个发布的团队，那么 Git-flow 可能是一个不错的选择。如果你的团队是一个初创企业，或者是一个面向 internet 的网站或 web 应用程序，同一天可能发布多个版本，那 Git-flow 对你来说就不合适了。如果你的团队是一个不到 10 人的团队，Git-flow 会给你的工作带来太多的规矩和开销。<br/></p><p>另一方面，如果你的团队有 20 多人进行并行发布，那么 Gitflow 可以确保不会把事情搞砸。<br/></p><p><strong>如果不应该使用 Git-flow，那应该用什么？</strong></p><p>我不能回答。并非所有分支模型都适用于所有团队和所有情况。如果你练习 CD，你需要一些尽可能简化过程的东西。</p><p>关键在于，团队需要反思：这个分支模型将帮助我们解决哪些问题？会产生什么问题？这种模型将鼓励什么样的发展？我们想鼓励这种行为吗？使用分支模型的最终目的都是方便软件过程中的合作，因此，需要考虑使用它的特定人群的需求，而不是互联网流传的「成功」的东西。</p><p>via：georgestocker.com/2020/03/04/please-stop-recommending-git-flow/ </p><p>雷锋网雷锋网(公众号：雷锋网)雷锋网</p><p><br/></p>
|
|
|
|
|
|
|
|
|
 |
一周最热 _ 一周热点的美文文章 |
|
