git - Git 分支管理和测试

Question

在 git 分支管理系统中有一些我不太了解的东西，这似乎是这里描述的规范或最简单的版本。

我们如何确定正在测试的代码（由测试环境中的人）实际上与我们交付的代码相同？

我的理解如下：

我有一个永恒的主分支，它反映了生产中的代码。

在任何给定时间，我都可以创建一个 Hotfix 分支 ( Hotfix_A) 来修复错误。在这个分支上，我将执行一个或多个提交来解决问题，然后我将编译这个分支以创建一个交付物（deliverable_A），供客户测试。我现在无法合并这些修改master，因为代码不在生产中。然后有一种情况，在这段时间内，当客户实现测试以证明我可以在生产中交付此更改时，另一个修补程序 ( Hotfix_B) 正在生产中交付（遵循相同的过程但更快）。

我处于我的可交付成果_A 已经过测试和认证的情况，但master此后分支已经发展。我无法交付 Deliverable_A，因为它不包含 Hotfix_B 拥有且已经投入生产的代码修改。

我可以合并修改并创建一个包含这两个修改的可交付成果 C。问题是没有人会在投入生产之前测试这个版本。即使我找到了可以测试这个 delivrable_C 的人，也可以在此期间完成另一个修补程序，我只是推迟了这个问题。

有人可以向我解释我对系统的理解有什么问题吗？

标签： gitbranch

Answer 1

我不认为你有一个必然的错误理解，因为你提出了一个有效的问题 - 如何处理多个修补程序分支？

在您给出的场景中， wherehotfix-A被延迟并hotfix-B在 A 之前应用，那么您已经做出了一些假设。您必须回答这些问题 - 是否hotfix-B取决于hotfix-A不同客户端测试的不同修补程序分支？

看起来，如果hotfix-B通过的速度比 快hotfix-A，那么这些修复（必须或总是，在这里要小心）无关。如果它们是相关的，那么也许你必须强加一个规则，你必须先严格合并before 。如果这两个修复不相关，那么您不必提供 A和B 一起测试的测试用例（原因是因为它们不相关并且修复不同的问题，并且预计不会有任何冲突彼此之间）。这就是为什么我们称其为热修复，因为我们正在急于求成（至此，请参阅策略 #1，因为它解决了这个问题）。hotfix-A hotfix-B

此外，请记住，不同的公司采用不同的策略来管理多个修补程序。策略如：

1. 例如，在每个修补程序之后，应用程序的服务版本都会发生碰撞，并且所有修补程序分支都rebased在最新的服务版本上。通过重新定位您的修补程序分支，您会自动将以前的修补程序合并到当前的修补程序中。对每个修补程序执行此操作。（注意：在这种情况下，您的测试人员可能需要重新测试软件......不是最好的情况，但您能做什么）。

2. 每个 hotfix 分支都单独合并到 master 中，因为每个 hotfix 分支都在一个单独的问题上工作，与其他分支无关。彼此相关的修补程序在同一个修补程序分支上工作，即hotfx-A是主修补程序，我们可以从中分出hotfix-A1,hotfix-A2和hotfix-A3. 我们将这些合并到hotfix-A，然后我们准备好合并到 master。

3. 每个修补程序都基于一个主修补程序分支，然后所有内容都被转储到 master 中。

所有这些方法都有优点和缺点。选择一个，看看它是否适合你。根据您的喜好和工作流程进行调整。