我们长期运行的git分支机构是 Master ， UAT 和 Prod ，以便新功能最初可用于Master并提升到UAT（准备好UAT时）然后升级到Prod（准备好生产时）。我们现在需要能够在生产中创建修补程序。我们计划创建一个修补程序分支，该分支与 Prod 分支相关联。除了长时间运行之外，这些分支是彼此分离的，因为合并是使用“非快进”合并来保持分支分开（这样我们可以很容易地看到每个分支上发生了什么活动，例如代码升级从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的自动合并可能没有意义。因此，对于从UAT到PROD，从PROD到HOTFIX，从HOTFIX到PROD的合并，我们将不会进行常规git合并，而是使用 git merge -s theirs strategy 如此处所述：git command for making one branch like another（我们将专门做模拟＃3）。
这个策略的作用是说“请合并从上游到下游的所有变化，并消除下游的状态，并将其替换为来自上游的确切内容”。因此，当我们使用这种策略从UAT转到PROD时，我们基本上会说“让PROD看起来像UAT一样”。这确保了生产中的内容正是UAT中代码的状态。
当你有两个分支将生产中的变更（一个用于常规版本，一个用于修补程序）这样的时候，git合并 - 他们的策略是执行此类合并策略的正确方法吗？
如果我们没有修补程序分支，我们只需要执行从master到uat到prod的常规（非快进）合并，而不是使用git merge -s theirs策略，因为它不需要。
答案 0 :(得分：1)
您有三种选择：
如果可以从PROD到master进行定期合并，请执行此操作。否则与--ours合并并在master上手动执行相应的更改。
答案 1 :(得分：0)
请考虑一下您的分支策略。对于某种项目而言，完美的策略可能是另一个项目的真正负担。
在你的情况下，我会建议一个开发分支（例如master）与正常的开发，并为每个版本建议一个单独的分支（基于发布的名称）。
发布分支从master开始并进入UAT。可以对此阶段发现的问题应用小修复。然后它进入生产，可以直接应用任何修补程序。
在您的案例中，没有充分理由将两个不同版本的提交链接起来。