我正在尝试使用Gerrit实现'git-flow'类型的工作流程，但我似乎无法弄清楚最后一块拼图。
我的问题有两个先决条件：
我想解决的问题如下。考虑一下这种情况：
Master 0
\
\
Develop 0-----0-----0-----0
有一个master分支，其中包含一个commit和一个develop分支，它是从master分支出来的，还有几个额外的提交。过了一会儿，开发分支被合并回master，以创建下一个生产版本。开发人员使用开发和严格变基的主题分支。在推动之前，他们的承诺总是在最新的上游开发之上进行重新设计。这应该会产生线性历史记录，并且只会提前快进。
现在假设某人从master创建了一个修补程序分支并合并回master：
Master 0--------0 HF
\
\
Develop 0-----0-----0-----0
此提交现在仅合并到主分支，但开发人员需要在其开发分支中进行此提交，以将错误修复合并到其更改中。通常你会合并master分支来开发develop分支，但考虑到我的前提条件，这是不可能的，因为它会创建一个本地合并提交。
我的问题是：如何将主分支中的新提交合并到本地开发分支中，以便开发人员的任何新更改都包含错误修复？理想情况下，我会修改我的脚本，首先将bugfix更改应用于本地开发分支（合并但没有合并提交），然后重新设置dev的提交并推送。这样，错误修复程序将自动添加到他们的新更改中，并将作为新提交的一部分，而不是单独的提交。
我一直在考虑可能的解决方案：
我希望我的问题很明确。如果需要进一步澄清，请告诉我。我知道我的工作流程非常严格，但与Gerrit结合使用会非常理想。如果无法完成，那么我可能会允许合并提交......
答案 0 :(得分：6)
在考虑了选项后，我决定放弃这种方法。在我看来，Gerrit主要针对单一集成分支开发。
当需要将更改合并到两个分支（例如，需要掌握和开发的修补程序）时，它会让您跳过所有类型的箍，这相当于额外的工作/审查。我决定坚持一个分支。
我认为Git流模型并不适合Gerrit设计。如果其他人将Gerrit与Git流程整合在一起，我很乐意听到他们的方法。
答案 1 :(得分：4)
您应该能够将此修补程序合并到您的开发分支中。您不需要合并master。我们通过这个工作流来处理这个问题（一个修补程序被认为是另一个版本，我们在它上面重新开始工作）：
https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
答案 2 :(得分：3)
最好的解决方案肯定是将master或hotfix分支合并到您的开发分支中。我不确定你的“没有合并提交”的先决条件是什么试图解决，但它可能会造成比它更值得的麻烦。
另一方面，如果你选择樱桃，git通常会在合并期间检测到重复的提交，并且没有任何问题。但是当遇到问题时，他们就不会有趣。另外还不清楚哪些修复已被挑选出来，哪些修复没有，合并时哪个非常清楚。