从两个不同的代码行(常规发布分支和修补程序分支) merge 到 Prod 分支的 Git 策略

Question

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

以下显示了一个常规开发版本的提交流程，最终需要一个修补程序。 Master 拥有大部分提交，因为开发一直在进行。 UAT 和 Prod 只有代表代码提升的提交。当需要修补程序时，我们从 prod merge 到 hotfix，在 hotfix 分支上进行更改，在 hotfix 环境中对其进行测试，然后将其 merge 到 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]

请注意，在修补程序之后，修补程序更改会手动 merge 到 master 分支中。这是因为根据修补程序发布的时间和当前开发线的状态(可能是几个月后)，Master 和 Hotfix 之间的代码可能差异太大，从 Hotfix 到 Master 的自动 merge 可能没有意义.因此，对于从 UAT 到 PROD、从 PROD 到 HOTFIX 以及从 HOTFIX 到 PROD 的 merge ，我们不会进行常规的 git merge ，而是使用 git merge -s theirs strategy 如此处所述:git command for making one branch like another (我们将专门进行模拟#3)。

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

当您有两个分支将更改引入生产(一个用于常规版本，一个用于修补程序)时，git merge -s theirs 策略是否是执行此类 merge 策略的正确方法？

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

Answer 1

你有三个选择:

• 或者您只是将您的分支重置为新版本。 (这似乎不是你的选择。)
• 你用你的“他们的策略”告诉 git “扔掉旧版本并用新版本替换它”(但 git 并不轻易支持这个)
• 或者您通过使用 --ours 选项将 PROD merge 到 master 来“使”master 的修补程序更改“无效”。

如果从 PROD 到 master 的常规 merge 是可能的，那就去做吧。否则与 --ours merge 并手动对 master 进行相应的更改。