作者都是各自领域经过审查的专家,并撰写他们有经验的主题. 我们所有的内容都经过同行评审,并由同一领域的Toptal专家验证.
无意中对Git造成损害是非常容易的. 然而,最好的方法是使用 Git 总是有争议的.
这是因为Git本身只详细说明了基本的分支操作,这就留下了它的使用模式.e.分支模型——这是用户意见的问题. Git分支模型承诺通过组织软件开发人员对其代码库进行更改时不可避免地出现的混乱来减轻痛苦.
像许多开发者一样, 您想要一些“刚刚工作”的东西,这样您就可以继续进行实际的软件开发. 所以你拿起了 Git流,这是Git用户经常推荐的分支模型. 也许您一开始就熟悉Git流的逻辑, 直到你在实践中遇到了一些障碍——与Git流的多个发布分支搏斗, 计算Git流暂存选项, 等. 或者也许Git流看起来不够好,不适合您采用它. 毕竟, 有无数的变量在起作用, 没有哪一种分支模式能适用于所有情况.
一个好消息! 经典Git流模型的一个变体, 增强的Git流 简化了Git流工作流中更常见的操作,同时仍然保留了其主要优点.
自从我发现Git流在开发一个演进的产品时有多么出色以来,我一直是Git流的强烈拥护者 显著的价值增量 换句话说, 释放).
一个重要的增值需要大量的时间来完成, 就像两周多的冲刺,通常用在 Scrum的发展. 如果开发团队已经部署到生产环境, 如果下一个版本的范围累积在生产代码所在的位置,可能会有麻烦.g.,在他们使用的Git仓库的主分支中.
虽然该产品仍处于初始开发阶段.e., 没有产品,也没有产品的真正用户——团队可以简单地将所有内容保留在主分支中. 事实上, 这是非常好的:这种策略可以在没有太多仪式的情况下实现最快的开发速度. But things change in a production environment; then, 真正的人开始依赖产品来保持稳定.
例如, 如果在生产中有一个严重的错误需要立即修复, 对于开发团队来说,必须回滚到目前为止在主分支中积累的所有工作,只是为了部署修复,这将是一个主要的灾难. 在没有适当测试的情况下部署代码——无论代码被认为是半生不熟还是开发良好——显然不是一种选择.
这就是分支模型的亮点所在,包括Git流. 任何复杂的分支模型都应该回答有关如何 隔离 下一个发布版本从系统目前使用的人,如何 更新 该版本与下一个发布,以及如何 介绍热补丁 当前版本的任何关键错误.
Git流程通过分离“主”(生产或“当前版本”分支)和“开发”(开发或“下一个版本”分支)来解决这些基本情况,并提供有关使用特性/发布/热修复分支的所有规则. 它有效地解决了基于发布的产品的开发工作流中的许多令人头痛的问题.
但即使是非常适合经典Git流模型的项目, 我遭受了它可能带来的典型问题:
我第一次使用增强的Git流是在一个新的闭源项目上. 我和另一个开发者一起工作, 我们一直通过直接提交到主分支来处理这个项目.
注意:直到产品的第一次公开发布, 为了开发工作流程的速度和简单性,将所有更改直接提交到主分支绝对是有意义的——即使您是Git流拥护者. 因为还没有生产, 不存在需要团队尽快修复的产品bug. 因此,在这个阶段,执行经典Git流所暗示的所有分支魔法是多余的.
当我们接近最初的发行版本时,我们达成了一致, 超过这个点, 我们不会再对直接提交到主分支感到舒服. 我们走得很快, 而且业务优先级并没有为建立坚如磐石的开发过程留下太多空间.e., 一个有足够的自动化测试来给我们信心,使我们的主要分支处于发布就绪状态.
这似乎是经典Git流模型的一个有效案例. 有独立的主分支和开发分支,在重要的价值增量之间有足够的时间, 有信心大多数手工QA会产生足够好的结果. 当我提倡Git流时, 我的同事也提出了类似的建议, 但有一些关键的区别.
一开始,我拒绝了. 在我看来,一些针对经典Git流的拟议“补丁”似乎有点过于革命性了. 我想他们可能会破坏主要思想,整个方法就会失败. 但经过进一步思考,我意识到这些调整实际上并没有破坏Git流. 与此同时, 它们通过解决上面提到的所有痛点,使它成为一个更好的Git分支模型.
在该项目中使用修改后的方法取得成功之后, 我在另一个闭源项目中使用了它,背后有一个小团队, 我是代码库的永久所有者,一两个外包开发人员不时提供帮助. 在这个项目上, 我们在6个月后投入生产, 从那时起, 我们使用CI和端到端测试已经一年多了, 大约每个月都会发布.
我对这种新分支方法的总体体验是如此积极,以至于我想与我的开发人员同事分享它,以帮助他们克服经典Git流的缺点.
对于增强的Git流中的工作隔离,仍然有两个长期存在的分支:main和develop. (用户仍然拥有热修复和发布功能——强调的是“功能”,因为这些不再是树枝了. 我们将在差异部分详细介绍.)
对于经典的Git流特性分支,没有官方的命名方案. 你只需要从开发中分离出来,然后在功能准备好时再合并进来进行开发. 团队可以使用任何他们喜欢的命名约定,或者只是希望开发人员使用比“my-branch”更具描述性的名称.增强的Git流也是如此.
在开发分支中积累到某个截止点的所有特性将形成新版本.
我强烈建议对功能分支使用压缩合并,以保持历史记录在大多数情况下是线性的. 没有它,提交图形(从GUI工具或 Git日志——图
)当一个团队在处理几个功能分支时,就会显得很草率:
但即使你对这种场景的视觉效果满意,也有另一个原因. 在不压缩的情况下,提交历史视图——其中都是普通的 git日志
(没有 ——图
)和github -即使是最简单的合并场景也会讲述相当不连贯的故事:
使用压缩合并需要注意的是,原始的特性分支历史会丢失. 但这个警告甚至不适用,如果你使用GitHub,例如 揭露完整的原始历史 通过pull请求合并的特性分支, 即使在特性分支本身被删除之后.
让我们回顾一下发布周期,因为(希望)这是你将要做的主要事情. 当我们想要发布在开发过程中积累的内容时, 它是main的超集. 在此之后,经典Git流和增强Git流之间的最大区别就开始了.
使用增强的Git流发布的每一步都不同于经典的Git流流程:
git push origin
.Git push -force
因为远程回购不会轻易接受如此“剧烈的变化”. 同样,在这种情况下,这并不像看起来那么不安全,因为:
热修复的情况有两种. 如果你在做热修复 当没有主动释放时—i.e., 团队正在开发分支中准备一个新版本——这很简单:提交到主版本, 将您的更改部署并在登台阶段中进行测试,直到它们准备就绪, 然后部署到生产环境.
作为最后一步, 选择从主版本提交到开发版本,以确保下一个版本将包含所有修复. 以防您最终提交了几个热修复, 通过创建和应用一个补丁,而不是多次挑选,您可以节省精力——特别是如果您的IDE或其他Git工具可以简化这一过程的话. 试图在初始版本发布后压制merge main进行开发,很可能会以与开发分支中独立进度的冲突而告终, 所以我不建议这么做.
处理修补程序 在活动释放期间—i.e., 当您刚刚强制推入main并仍在准备新版本时,它是增强的Git流中最弱的部分. 这取决于你的发行周期的长短和你必须解决的问题的严重性, 始终致力于在新版本中包含修复程序——这是最简单的方法, 而且完全不会扰乱整个工作流程.
如果这是不允许的,你必须快速引入修复, 如果你等不及新版本准备好,那就准备好一个有点复杂的Git过程吧:
只要计划得当, 代码质量足够高, 以及健康的发展和QA文化, 您的团队不太可能使用这种方法. 为增强的Git流开发和测试这样的灾难计划是明智的, 只是以防万一,但我从来没有在实践中使用过.
并不是每个项目都需要一个专用的开发环境. 在每台开发人员机器上设置一个复杂的本地开发环境可能很容易.
但是,专门的发展环境可以促进更健康的发展文化. 运行测试, 测量测试覆盖率, 并且在开发分支上计算复杂性度量,通常可以在错误进入阶段之前很好地捕获它们,从而降低错误的成本.
我发现一些CI/CD模式在与增强的Git流结合使用时特别有用:
这种模式相对简单, 然而,提供强大的机制来支持日常的开发操作.
增强的Git流并不适合所有人. 它确实利用了有争议的武力推动主要分支的策略,因此纯粹主义者可能会怨恨它. 从实际的角度来看,这并没有什么错.
如前所述,在发布期间修补程序更具挑战性,但仍然是可能的. 适当关注QA,测试覆盖率等. 这种情况不应该经常发生, 所以在我看来, 与经典Git流相比,增强Git流的整体优势是一个有效的权衡. 我非常有兴趣了解增强的Git流程在大型团队和更复杂的项目中的表现, 在哪些地方可能更频繁地出现热修复程序.
我对增强的Git流模型的积极体验也主要围绕着闭源商业项目. 对于拉取请求通常基于源代码树的旧版本派生的开源项目来说,这可能是有问题的. 解决这个问题没有技术上的障碍——只是可能需要比预期更多的努力. 我欢迎在开源领域有丰富经验的读者就增强的Git流在这种情况下的适用性给出反馈.
特别感谢Toptal同事 安东尼·范教授 因为他在开发增强Git流背后的思想方面发挥了关键作用.
作为一个 微软金牌合作伙伴, Toptal是您的微软专家精英网络. 与您需要的专家一起建立高绩效团队-随时随地都可以!
Git流是Git版本控制系统(VCS)的分支模型。. 分支模型建立在基本的Git操作之上, 规定使用模式,以实现健壮的版本管理. Git流是Vincent Driessen在2010年的一篇博客文章中公开宣布的,从那以后一直很受欢迎.
Git流分支策略在开发以显著的价值增量演进的产品时表现出色. 它通过分离“主”(生产或“当前版本”分支)和“开发”(开发或“下一个版本”分支)并提供有关使用helper分支的所有必要规则来实现这一点.
按照指定的模式使用Git流. 这可以让您的团队获得关于如何将下一个发行版与当前生产中的系统版本隔离开来的问题的答案, 如何在下一个版本中更新该版本, 以及如何在当前版本中引入任何关键错误的热修复程序.
是否应该使用Git流取决于您的特定项目. 要回答的主要问题是, “整个开发工作流程是否有足够的自动质量保证来保持主要分支处于发布就绪状态??如果答案是否定的,那么这样的项目可能会受益于Git流.
没有最好的Git工作流,因为答案取决于特定的项目环境. 一些项目将受益于Git流或其变体, 而其他人则会更好地使用基于主干的开发方法.
世界级的文章,每周发一次.
世界级的文章,每周发一次.