敏捷 Git 与 GitWorkflows 集成

在本文中，我们将探讨如何使用基于GitWorkflow的功能分支，仅在功能和修复完全准备就绪时才进行集成。虽然这种工作流程不如其他工作流程那么知名，但它提供了相当大的自由度和灵活性。

我们不会在本文中介绍 GitWorkflow 的全部内容，而是介绍一个简化的变体，专注于使用单个持久分支、单个集成分支和各个功能分支。

注意：对于熟悉GitFlow的朋友，我需要指出的是，虽然名称相似，但这是两个完全不同的工作流程。本文仅介绍 Git 核心团队的工作流程。如果您想比较和对比，我推荐这篇HackerNoon文章。

动态 Git 策略的必要性

在我描述这个工作流程之前，让我们先看几个场景：

• 想象一下，你在一个大型组织内负责一个应用程序。你为它添加功能，并修复出现的问题。你的组织喜欢频繁发布新版本，你可能直到接近最终的预发布测试周期才知道哪些工作项会被纳入其中。

• 或者，您正在开发同类型的应用程序，并且您的某个功能在测试后期发现了一个模糊的错误，需要从发布版本中删除。

• 或者想象一下，开发人员实现了一个新功能，该功能会导致测试环境停止，并且必须将其删除，直到修复后才能恢复测试。

在任何这些场景中，都需要一定程度的开发敏捷性。你的核心需求是能够快速地从版本中删除功能或修复，而不会引入重大风险。

这就是工作流程的全部内容——能够根据需要快速向分支添加或删除功能。

只使用开发分支怎么样？

那么，为什么需要这样做呢？难道我们不能让所有开发人员在一个持久的开发分支上编写代码，然后定期拆分出主要功能的分支，然后再将它们合并回去吗？

嗯，也许吧，但是如果您在发布之前发现开发分支中两周前的功能提交存在问题，您会怎么做？

• 推迟发布以修复
• 进行新的提交以禁用该功能，希望您正确禁用它并且这是唯一引入的新问题
• 有缺陷的版本

在我看来，这些都不是什么好选择。你被迫承担不必要的风险，或者推迟原本不必要的日期。

分支机构结构概述

使用 Git 核心团队的工作流程，您只需根据不包含引入问题的分支的组合来自定义发布顺序。

在此工作流程下，您将拥有功能分支，这些分支代表正在更改的各个工作项。这些是您的单独修复和新功能。

每个功能分支都从master 分支分支出来。除了它所代表的含义之外，这没什么特别的。Master分支代表可发布的代码。这些代码已经过全面测试，并由产品管理部门审核，并且不会引入任何回归问题。

该工作流程的有趣之处在于其“建议更新分支”（通常简称为pu）的概念。“建议更新”分支包含已完成的功能或修复，这些功能或修复已准备好进行协同评估，以形成最终版本。

注意：GitWorkflows 也提倡使用next分支maint。next相当于预发布环境，而 则maint基于最新的生产版本。您可能需要也可能不需要这些分支。

测试与集成

因此，所有测试和产品评审都基于提议的更新分支进行。一旦该集成测试分支被认证为良好，则在合并之前，将功能分支 rebase 到 master 分支，并将包含各个更改的功能分支合并到 master 分支。

这对我们来说有几件事：

• 保持版本历史记录干净整洁
• 它确保功能分支不会相互渗透，这样你就不会依赖于你不想依赖的代码
• 如果集成分支损坏，我们可以随意重新生成它

我可以在这里更详细地解释这些，但最好向您展示单个功能的生命周期。

案例研究：添加深色主题

因为每个应用程序都需要一个黑暗主题，所以让我们在案例研究中以此为例。

Priya 查看了团队的敏捷看板，决定接手工单系统中 ID 为“FOO-123”的“添加深色主题”故事。她查看了用户故事和验收标准，觉得信息足够了，可以开始了，于是就把这个故事分配给了自己，并创建了一个分支。

她通过切换到master分支然后运行来创建此分支git checkout -b FOO-123

这将根据工作项的标识符（FOO-123）在当前分支上创建一个分支，然后切换到该分支。

Priya 会花时间测试和修改，直到对功能满意为止。准备就绪后，她会向FOO-123（pu建议更新）分支提交合并请求（也称为拉取请求）。

Jerome 在分支上进行了代码审查，对工作感到满意并批准了合并请求，因此 Priya 将其合并到pu。

持续集成服务器检测到分支的变更pu，从而触发构建。构建成功后，会将其部署到测试环境。

随后，质量保证部门审核了该功能，没有发现任何问题。产品管理部门也同样感到满意。

从建议的更新中删除项目

遗憾的是，Landon 一直在开发一个新页面，但该页面并未考虑到新引入的主题。深色主题在该页面上的渲染效果不佳，因此当产品管理和质量保证审核 Landon 的页面时，出现了问题。

由于开发周期仅剩一天，而 Landon 的新页面对业务至关重要，因此团队决定从此版本中删除深色主题，并将其移至下一个版本。

为了实现这一点，团队决定pu从当前master分支重新创建分支。他们要么删除pu最新master提交，然后重新创建分支，要么硬重置pu以匹配最新master提交，然后强制推送。

注意：强制推送非常危险且具有破坏性，可能会抹去分支上的更改。在这种情况下，我们希望移除分支上的更改pu，并从原始状态开始。如果让几个经验丰富的人员pu定期执行强制推送来重置分支让您感到不快，我建议您考虑删除pu分支并重新创建分支，但这样做可能会增加额外的开销。

一旦pu分支可用，所有应该集成到其中的功能分支都会合并回该分支，并生成新的构建并将其部署到测试环境中。

我喜欢将其视为一个高度可配置的菜单，您可以在其中选择每个功能是否属于某个分支的一部分。

集成到 Master

下一个冲刺，发布审核通过后，Priya 对 FOO-123 做了一些额外的调整，以便暗色主题能够在 Landon 的新功能上正确呈现。准备就绪后，她又提交了另一个拉取请求，并在pu获得批准后将其合并。

这次一切顺利，FOO-123 已获批准并加入到发布版本中。现在需要将该功能合并到master分支中。

虽然pu直接合并到master分支中是可行的，但它也有一些缺点：

• 您需要检查pu分支，确保与其集成的每个功能都已通过测试并获得发布批准。如果您犯了错误，则意味着您将未经测试的内容添加到了可用于生产的分支中。
• 将整个集成分支合并到一起，master会使单个提交历史的阅读和理解变得更加困难，因为功能会从一个分支转移到另一个分支。虽然查看单个功能可能有意义，但阅读实际的整个分支历史记录会更加困难。

因此，我们需要将功能分支合并到 master 中，而不是将建议的更新合并到 master 中。

这是人们在理解 Git Core 团队工作流程时遇到的首要问题，因此强调这一点很重要。

相反，我们首先切换到功能分支，然后git rebase master将该功能 rebase 到 master 的最新版本。这有助于保持版本历史记录的完整性，并允许我们在分支内部（而不是在我们要集成的分支内部）解决合并冲突。

完成后，合并被提交，我们切换到master分支，然后通过git merge FOO-123（分支名称）合并主题分支。

随着合并的提交和推送，它现在是下一个版本的正式部分，如果您愿意，可以删除单个功能分支。

万一主人有问题怎么办？

如果代码进入master需要移除的分支，那么现在就有问题了。这个工作流程不太适合处理这个任务，因为master它应该是持久化的。

因此，master如果您有任何疑问，我强烈建议您推迟合并，因为在以后合并到主版本中要容易得多，而不是尝试从主版本中删除某些内容或修补主版本。

你可以做的一件事是制定一条规则，一旦工作项目获得产品管理部门的批准，就将其关闭并合并master，任何调整都需要一个新的工作项目，而不是重新打开旧的。根据我的经验，这通常会产生良好的效果，但具体情况可能因人而异。

如果您确实需要进行调整，master那么我认为您有以下几种选择：

• 要求新的工作项通过管道并进入master分支，并进行您想要的任何更改。
• 恢复master到已知的良好状态，然后强制推送并合并该状态之后的项目。
• 使用恢复提交将特定提交恢复为主提交并稍后重新集成。

这些都不是好的选择：

• 您总是希望master能发布，因此等待新项目的到来会限制您的灵活性。
• 除非在极端情况下，强制推送在您的分支上进行操作太危险了master，所以它不应该成为您正常工作流程的一部分。
• 恢复提交会混淆您的版本历史，并且如果后续提交修改了相同的代码区域，则可能甚至不起作用。

总而言之，最好在集成之前花一些额外的时间来确保功能确实可用。

其他建议

我强烈建议您在master分支上标记发布，因为标签的存在允许您快速创建maint分支，以便稍后根据需要提供修补程序，而不必猜测或搜索与您的上一个生产版本相对应的提交哈希。

我建议你在每个冲刺开始时重置pu分支。这有助于在比较功能分支和分支时保持分支比较的准确性。这也使得你能够轻松识别分支中哪些内容尚未完成。masterpupu

某些版本控制工具（例如 GitHub 的 Web 用户界面）会通过将您尝试集成的分支合并到功能分支来处理合并冲突。当您尝试将功能分支合并到 时，这会带来问题，pu因为您肯定不希望其他功能在您不知情的情况下进入功能分支。建议您使用命令行或外部工具（例如GitKraken）来解决 中的合并冲突pu。

如果您不喜欢这个名字pu，我建议您将分支命名为qa。我个人releases更喜欢使用master而不是 和qa而不是pu，但无论使用哪种术语，概念都是相同的。

维护版本怎么样？

此模型不太适合长期维护的分支。如果您在不频繁发布的环境中工作，则应该考虑 GitFlow 或其他 Git 方法。

一般来说，在 Git 核心团队的工作流程下，您会发现自己想要更频繁地发布master而不是在生产中提供修补程序。

但是，如果您确实master需要进行修补，则可以通过切换到在给定版本的分支上创建的标签并在该位置创建代表生产补丁的新分支来完成此操作。

或者，您可以始终拥有一个maint分支，并在每次发布时更新该分支以指向最新的生产版本提交。

创建修补程序分支后，您可以从此分支分支出一个单独的功能分支，用于发布生产补丁。然后，您可以将功能分支合并到修补程序分支中，生成构建版本，并由 QA 和产品部门验证该构建版本，然后将其应用于生产环境。

这种不同的工作流程是为了防止master比生产标签更新的更改进入生产。

一旦应用了生产补丁，该功能也应该合并到pu，然后master在 中进行测试pu。如果不这样做，将导致回归问题，即应用的生产补丁在下一个版本中不再存在。

虽然您可以通过这种方式处理维护问题，但如果您确实习惯性地需要生产补丁和维护分支，则应该考虑更频繁地发布，以便在计划的发布中更容易地实现缺陷解决，并将补丁保留给那些真正可怕的高严重性错误。

如果您的团队经常遇到严重到需要发布生产补丁的情况，那么您还应该仔细审视您的开发和测试实践。

结论

这种工作流程并不适合所有人，但如果您想要完全控制哪个版本中包含哪些功能，那么这是一个值得认真考虑的工作流程。

这只是 GitWorkflow 的一个版本。如果您想了解更多，我建议您阅读以下资料：

• Git 的创建者如何创建分支
• GitWorkflows文档

Agile Git 与 GitWorkflows 的集成一文首先出现在Kill All Defects上。