3

我们长期运行的 git 分支是Master、UAT和Prod，这样新的功能就开始工作并最初提交给 Master，然后提升到 UAT（准备好进行 UAT），然后提升到 Prod（准备好进行生产）。我们现在需要能够在生产中创建修补程序。我们计划创建一个与Prod分支链接的Hotfix分支。除了长时间运行之外，这些分支彼此分开，因为合并是使用“非快进”合并完成的，以保持分支分开（这样我们可以很容易地看到每个分支上发生了什么活动，例如从 Master 到 UAT 的代码提升等）。

下面显示了一个最终需要修补程序的常规开发版本的提交流程。由于开发一直在发生，Master 拥有大部分提交。UAT 和 Prod 仅具有代表代码提升的提交。当需要修补程序时，我们从 prod 合并到修补程序，在修补程序分支上进行更改，在修补程序环境中对其进行测试，然后将其合并到 prod 中。

hotfix ----------------------o-o----------   [1 commit for the merge prod->hotfix to get the latest state of prod into the hotfix environment, 1 commit of a bugfix to the hotfix environment]
prod   --------------------o-----o--------   [1 commit for the promotion uat-> prod to get the latest uat-tested code into prod, 1 commit for the promotion of the bugfix hotfix->prod]
uat    -----------------o-----------------   [1 commit for the promotion of master->uat of 4 master commits]
master --o---o---o---o----o-o--o---o-o--o-   [10 commits of new functionality]

请注意，在修补程序之后，修补程序更改会手动合并到主分支中。这是因为根据 hotfix 发布的时间和当前开发线的状态（可能是几个月后），Master 和 Hotfix 之间的代码可能过于分歧，从 Hotfix 到 Master 的自动合并可能没有意义. 因此，对于从 UAT 到 PROD、从 PROD 到 HOTFIX 以及从 HOTFIX 到 PROD 的合并，我们不会进行常规的 git 合并，而是使用git merge -s theirs 策略，如此处所述：git使一个分支像另一个分支的命令（我们将专门进行模拟#3）。

该策略的作用是说“请合并从上游到下游的所有更改，并消除下游的状态并用来自上游的确切内容替换它”。因此，当我们使用这种策略从 UAT 转到 PROD 时，我们基本上会说“让 PROD 看起来完全像 UAT”。这确保了进入生产环境的正是 UAT 中的代码状态。

当您有两个分支将更改引入生产（一个用于常规版本，一个用于修补程序）时， git merge -s theirs 策略是执行这种合并策略的正确方法吗？

如果我们没有修补程序分支，我们将简单地从 master 到 uat 再到 prod 进行常规（非快进）合并，而不使用 git merge -s theirs 策略，因为它不需要。

4

2 回答 2

1

你有三个选择：

  • 要么你只是将你的分支重置为新版本。（在您的情况下似乎没有选择。）
  • 你用你的“他们的策略”告诉 git “扔掉旧版本并用新版本替换它”（但 git 并不容易支持这一点）
  • 或者您通过使用 --ours 选项将 PROD 合并到 master 来“使”master 的修补程序更改“无效”。

如果可以从 PROD 定期合并到 master，请执行此操作。否则与 --ours 合并并手动对 master 进行相应的更改。

于 2013-03-02T18:40:00.587 回答
0

请考虑您的分支策略。对于一种项目来说完美的策略可能会成为另一个项目的真正负担。

在您的情况下，我会建议一个具有正常开发的开发分支（例如 master），并为每个发布一个单独的分支（基于发布的名称）。

发布分支从 master 开始，进入 UAT。在此阶段发现的问题可以应用小修复。之后它进入生产阶段，可以直接应用任何修补程序。

在您的情况下，确实没有充分的理由链接两个不同版本的提交。

于 2013-03-02T20:44:26.820 回答