增强的Git流程模型

使用Git的最佳方式一直存在争议。那是因为Git本身只指定了基本的分支操作，这使得它的使用模型：分支模型——经常成为用户争论的焦点。虽然Git分支模型可以帮助开发人员在更改代码库时减少冲突。GitFlow，是一种经常推荐给Git用户的分支模型。也许你一开始对GitFlow的逻辑很感兴趣，但是直到你在实践中遇到了一些障碍。毕竟，有无数变数在起作用，没有一种单一的分支模型适用于所有情况。不过，值得高兴的是，作为经典GitFlow模型的变种，增强版GitFlow模型简化了GitFlow中较为常见的操作，同时保留了主要优势。经典GitFlow模型的荣耀和苦难自从我发现GitFlow在开发具有重要价值的产品时有多么伟大之后，我就一直是GitFlow的坚定拥护者。价值的显着增加需要花费大量时间来证明，例如基于scrum的开发中通常使用的两周以上的冲刺。当产品还处于初期开发阶段，即没有产品，也没有产品的真正用户时，团队可以把所有的东西都放在master分支上。其实这样很好：这种策略可以实现最快的开发速度。但是在生产环境中情况会发生变化。例如，如果生产中有一个关键问题需要立即修复，那么对于开发团队来说，必须回滚现有已完成的代码才能部署修复的代码。在没有适当测试的情况下部署代码，无论代码被认为是不成熟的还是开发良好的，显然都是不可取的。这是分支模型的标志，包括GitFlow。任何复杂的分支模型都应该回答这样的问题：如何将下一个版本与人们当前使用的版本隔离开来；如何用下一个版本更新那个版本；以及如何将任何关键错误修复代码引入当前版本。GitFlow通过分离“main”（生产或“当前版本”分支）和“dev”（开发或“下一版本”分支）分支来解决这些问题，并提供使用功能/发布/修补程序分支的所有规则基本场景。它有效地解决了发布开发工作流程中的许多令人头疼的问题。然而，即使是非常适合经典GitFlow模型的项目，我也遇到了它可能带来的典型问题：GitFlow很复杂，有两个长期存在的分支，三个临时分支，以及分支之间的严格规则。这种复杂性更容易出错并增加修复它们所需的成本。release和hotfix分支需要“双重合并”——合并到主分支，然后合并到devlop分支。有时你会忘记两者都做。您可以使用脚本或VCSGUI客户端插件来简化GitFlow分支，但您必须首先为参与给定项目的每个开发人员的每台机器设置它们。在CI/CD工作流中，一个发布通常有两个最终版本——一个来自发布分支本身的最新提交，另一个来自合并提交到主分支。严格来说，应该使用main中的一个。但这两个通常是相同的并且可能会造成混淆。增强的Git流程在产品首次公开发布之前，为了开发工作流程的速度和简单性，将所有更改直接提交到主分支绝对是有意义的。因为还没有产品，所以团队不太可能需要尽快修复产品错误。因此，在这个阶段，按照传统GitFlow模型的建议执行分支管理是多余的。然后我们接近初始版本，之后我们将不再愿意直接提交到主分支。我们进展迅速，业务优先级并没有为建立坚如磐石的开发流程留出太多空间。它有足够的自动化测试让我们有信心将我们的主要分支保持在发布就绪状态。这似乎是经典GitFlow模型的有效案例。拥有独立的主分支和开发分支。然而，后来我做了一些改变。起初在我看来，对GitFlow做一些“补丁”有点过于激进了。我觉得这可能会打破GitFlow的主要思想，从而达不到目的。但经过进一步思考，我意识到这些调整实际上并没有破坏GitFlow。同时，他们解决了上述所有问题，使其成为更好的Git分支模型。下面，我将这套方法分享给大家，帮助开发者克服传统GitFlow的不足。与传统GitFlow的相似之处：开发隔离对于增强GitFlow中的工作隔离，仍然有两个长期存在的分支：main和development。经典GitFlow功能分支没有正式的命名方案。当功能准备就绪后，只需从devlop分支出来并合并回来进行开发即可。团队可以使用他们喜欢的任何命名约定，或者只是希望开发人员使用比“我的分支”更具描述性的东西。增强的GitFlow也是如此。挤压合并我强烈建议在特性分支中使用挤压合并，以在大多数情况下保持良好的线性历史记录。没有它，当团队一次处理少量功能分支时，gitgraph(gitlog-graph)日志可能看起来很草率：但在这种情况下，即使您对视觉效果也很好。没有压缩，提交的历史视图-包括正常的git日志（没有-graph）和一些相当不连贯的日志，即使对于最简单的合并场景也是如此：使用压缩合并你需要知道的是原始功能分支提交历史将是丢失的。与经典Git流程的区别：发布和修补程序让我们看一下发布周期，因为这是您要做的主要事情。当我们想要发布我们在开??发中积累的内容时，它严格来说是main的超集。在此之后，经典Git流程和增强版Git流程之间的最大区别开始了。增强版GitFlow中的发布分支在发布方面，使用增强版GitFlow的每一步都与经典GitFlow不同：发布是基于主分支，而不是devlop分支。您可以用有意义的东西标记主分支的当前提示。我采用了ISO8601格式的基于当前日期的标签，前缀为“v”——例如：v2020-09-09。如果一天内碰巧有多个版本（例如修补问题），则可以根据需要在格式后附加连续的数字或字母。请注意，标签通常与发布日期不对应。它们只是在那里强制Git在下一个发布过程开始时保留对主分支的引用。使用gitPushorigin推送标签。在此之后，可能会出现意外：如果要删除本地主分支。所有提交给main的操作仍然是安全的——我们通过在上一步中标记main来保护它们不被垃圾收集。每个提交（甚至修补程序）都是开发的一部分。只要确保团队中只有一个人在做这件事：这就是所谓的“发布经理”角色。发布经理通常是最有经验和/或最资深的团队成员，但团队最好避免任何特定的团队成员永久担任此角色。在develop分支的tip提交处创建一个新的本地master分支。使用gitpush-force来推送这个新结构，因为远程存储库不会轻易接受这样的“戏剧性变化”。同样，在这种情况下，它并不像看起来那么不安全，因为：我们只是将主分支指针从一个提交移动到另一个提交。一次只有一个特定的团队成员进行此更改。日常开发发生在develop分支上，因此以这种方式移动main不会干扰任何人的工作。将其部署到您的环境并进行测试。任何修复都直接指向master分支，因此它会开始从develop分支中分离出来。同时，您可以在开发分支中开始开发新版本，具有在经典GitFlow中看到的相同优势。当您的新版本被认为足够稳定时，将最终版本部署到生产环境并进行主-开发合并以获取所有修复。在GitFlow模型中增强修补程序修补程序的情况是双重的。例如，如果你正在做一个修补程序，团队正在开发分支准备一个新版本，当他们准备好时，他们需要部署到生产。作为最后一步，从main到develop中选择提交，以确保下一个版本将包含所有修复。如果您需要提交多个修补程序，您可以通过创建和应用一个补丁而不是多次选择补丁来节省精力——尤其是如果您的IDE或其他Git工具可以帮助它。初次发布后试图将master分支合并到develop分支中，很可能会与develop分支的单独进程发生冲突，所以不推荐。在发布期间处理补丁。例如，当您只是暴力破解主分支并仍在准备新版本时，这是增强型GitFlow中最薄弱的环节。根据发布周期的长短和需要解决的问题的严重性，始终以在新版本中包含修复为目标——这是最简单的方法，根本不会中断整个工作流程。如果那是不可能的，你必须快速引入一个修复，你不能等待一个新版本-然后准备一个有点复杂的Git过程：创建一个分支-我们称之为“新版本”，但你的团队这里可以采用任何命名约定。在您之前为当前版本创建的标记提交时删除并重新创建本地master分支。对main引入必要的修复，部署到环境，然后进行测试。准备就绪后，部署到生产环境。补丁从当前主要版本更改为新版本。然后重做release流程：在当前trunk之上打tagpushtag，在新的release分支之上删除并重新创建本地master分支，强制push。您可能不需要前面的标记，因此可以将其删除。新发布的分支现在是多余的，所以你也可以删除它。您现在应该可以像往常一样使用新的发行版了。这是通过cherrypick或主开发的补丁通过传播紧急修复来完成的。增强的GitFlow模型中的CI/CD设置不需要为每个项目提供专用的开发环境。在每台开发人员机器上设置复杂的本地开发环境可能很容易。在开发分支上运行测试、测量测试覆盖率和计算复杂性指标通常可以通过在错误进入执行阶段之前及时发现它们来降低错误成本。我发现一些CI/CD模式在与增强的GitFlow结合时特别有用：如果您需要一个开发环境，请设置CI以在每次提交到开发分支时进行构建、测试和部署。如果你有E2E测试，并且它对你的情况有意义，那么也在这里进行E2E测试。设置CI以在每次提交到master分支时构建、测试和部署到环境。在这一点上，端到端测试也是非常有益的。在两个地方都使用端到端测试似乎是多余的，但请记住，修补程序不会在开发过程中发生。在提交到main时触发E2E将测试修复和日常更改，但在提交到dev时触发会更早地发现错误。以允许您的团队根据手动请求将构建从主部署到生产的方式配置CI。这些模式相对简单，但提供了强大的机制来支持日常开发操作。改进和可能的限制EnhancedGitFlow并不适合所有人。它确实使用了有争议的武力推动主要分支的策略，因此纯粹主义者可能会反感它。不过，从实际的角度来看，这并没有错。如前所述，修补程序在发布期间更具挑战性，但仍有可能。适当注意QA、测试覆盖率等，这些不应该经常发生，因此在我看来，与传统Git流程相比，增强Git流程的整体优势是一个有效的权衡。我很想知道增强的Git流程如何与更大的团队和更复杂的项目一起工作，在这些项目中，修补程序可能会更频繁地出现。我对增强的GitFlow模型的积极体验也主要围绕闭源商业项目展开。这对于开源项目来说可能是个问题，因为拉取请求通常是基于源代码树的旧版本进行分叉的。解决这个问题没有技术障碍，只是可能需要比预期更多的努力。我非常欢迎在开源世界拥有丰富经验的读者提供反馈，因为您了解增强型GitFlow在这种情况下的适用性。