Git 工作流程和 Gerrit

Question

我正在尝试使用 Gerrit 实现“git-flow”类型的工作流，但我似乎无法弄清楚最后一块拼图。

我的问题有两个前提：

• Gerrit 只会合并到一个分支
• 我不允许将合并提交推送到 Gerrit。更改获得批准后，必须由 Gerrit 完成合并

我要解决的问题如下。考虑这种 git 情况：

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

有一个带有一个提交的 master 分支和一个从 master 派生的带有多个附加提交的 develop 分支。一段时间后，develop 分支合并回 master 以创建下一个生产版本。开发人员使用来自开发的主题分支和严格的变基。在推送之前，他们的提交总是基于最新的上游开发。这应该会导致线性历史记录，并且只会快进提交。

现在假设有人从 master 创建了一个 hotfix 分支并合并回 master：

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

这个提交现在只合并到主分支，但开发人员需要在他们的开发分支中提交这个提交来将错误修复合并到他们的更改中。通常你会合并主分支来开发开发分支，但考虑到我的先决条件，这是不可能的，因为它会创建一个本地合并提交。

我的问题是：如何将主分支的新提交合并到本地开发分支中，以便开发人员的任何新更改都包含错误修复？理想情况下，我会修改我的脚本以首先将错误修复更改应用于本地开发分支（合并但没有合并提交），然后重新设置开发人员的提交并推送。这样，错误修复将自动添加到他们的新更改中，并将被视为新提交的一部分，而不是单独的提交。

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

• Cherry 选择提交到开发分支。我相信下次开发与 master 合并时，这将始终导致重复提交。有没有办法解决这个问题？
• 按照此处所述进行变基：http://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commits/。自从开发分支发布以来，这可能会导致问题，还是不会？

我希望我的问题很清楚。如果需要进一步澄清，请告诉我。我知道我的工作流程非常严格，但与 Gerrit 结合使用将是理想的选择。如果它不能完成，那么我可能会允许合并提交......

Answer 1

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

当需要将更改合并到两个分支（例如，需要掌握和开发的修补程序）时，它会让您跳过各种难关，这相当于额外的工作/审查。我决定坚持一个分支。

我认为 Git 流模型并不真正适合 Gerrit 设计。如果其他人已将 Gerrit 与 Git 流程集成，我很想听听他们的方法。

Answer 2

您应该能够将修补程序合并到您的开发分支中。你不需要合并主人。我们通过这个工作流程来处理这个问题（修补程序被认为是另一个版本，我们在此基础上重新工作）：

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

Answer 3

最好的解决方案肯定是将 master 或 hotfix 分支合并到您的开发分支中。我不确定您的“不合并提交”前提是要解决什么问题，但它可能会带来比其价值更多的麻烦。

另一方面，如果你选择樱桃，git 通常会在合并期间检测到重复提交并自动合并它而不会出现任何问题。但是当出现问题时，它们就不会很有趣。此外，还不清楚哪些修复已经被挑选出来，哪些没有被挑选出来，而合并则非常清楚。