Git工作流程和Gerrit

Question

我正在尝试使用Gerrit实现类似于'git-flow'的工作流程，但似乎无法解决最后一个难题。

我的问题有两个前提条件：

• Gerrit只会执行到一个分支的合并操作
• 我不允许将合并提交推送到Gerrit。在经过审核后，必须由Gerrit进行合并操作

我想要解决的问题是如下的Git情况：

Master 0 
        \
         \
Develop   0-----0-----0-----0

有一个主分支(master branch)，包含一次提交(commit)，还有一个develop分支，是从master分支衍生出来的，并添加了多个附加提交。过一段时间，将develop分支合并回master分支，以创建下一个生产发布版本。开发人员使用develop主题分支(topic branches)严格地进行变基(rebasing)操作。在推送之前，他们的提交(commit)总是在最新的上游develop分支之上进行变基。这应该会导致线性历史(linear history)和仅快进提交(fast forward commits)。

现在假设有人从master分支创建了一个热修复分支(hotfix branch)，并将其合并回master分支:

Master 0--------0 HF 
        \
         \
Develop   0-----0-----0-----0

这个提交现在只合并到了主干分支，但开发人员需要将这个提交合并到他们的开发分支中，以整合这个错误修复。通常情况下，您会将主干分支合并到开发分支，但考虑到我的前提条件，这是不可能的，因为它会创建一个本地合并提交。我的问题是：我该如何将主干分支中的新提交合并到本地开发分支中，以便开发人员的任何新更改都包含这个错误修复？理想情况下，我希望修改我的脚本，首先将错误修复更改应用于本地开发分支（合并但不产生合并提交），然后再变基开发者的提交并进行推送。这样，错误修复将自动添加到他们的新更改中，并被视为他们的新提交的一部分，而不是单独的提交。

我一直在思考可能的解决方案：

- 将提交选择到开发分支。我认为，这将始终导致当开发分支下一次与主分支合并时出现重复提交。有什么办法可以解决这个问题吗？ - 如此描述的变基：http://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commits/。这可能会引起问题，因为开发分支已经发布了，或者不会吗？

我希望我的问题很清楚。如果需要进一步说明，请告诉我。我知道我的工作流程非常严格，但与 Gerrit 结合使用会非常理想。如果不能做到这一点，那么我可能会允许合并提交...

- Ivo

Answer 1

在考虑了各种选项后，我决定放弃这种方法。在我看来，Gerrit主要针对单一集成分支开发。

当需要将更改合并到两个分支时（例如需要发布到master和develop的热修复），它会让你跳过所有种类的障碍，这导致额外的工作/审核。我决定坚持只使用一个分支。

我认为Git flow模型并不适用于Gerrit的设计。如果其他人已经将Gerrit与Git flow集成，请分享他们的方法。

- Ivo

Answer 2

你应该能够将热修补合并到你的开发分支中，不需要合并主分支。我们使用这个工作流程来处理这个问题（热修补被认为是另一个版本发布，并且我们在其之上重新构建工作）。

链接：https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

- Adam Dymitruk

Answer 3

最好的解决方案是将主分支（master）或热修复分支（hotfix）合并到您的开发分支。我不确定您“无合并提交”这个前提条件的目的是什么，但它可能会带来更多麻烦而不值得。另一方面，如果您使用 cherry-pick，git通常会在合并过程中检测到重复提交，并自动合并它们，而没有任何问题。但是当出现问题时，情况就不太好了。此外，使用 cherry-pick 不太清楚哪些修复已经被挑选并哪些没有，而合并则非常清晰明了。

- Brad

---

没有“合并提交”的原因是我不希望本地开发人员将开发分支（带有新提交）与主分支合并，并将结果推送到规范存储库。在 Gerrit 中审查后，开发分支上的新提交必须仅合并到主分支中。 - Ivo

请记住，您的开发人员所做的任何合并提交也必须在 Gerrit 中进行审查/批准。这有助于我的团队避免任何问题。 - Brad