14

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

我的问题有两个先决条件：

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

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

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

有一个带有一个提交的 master 分支和一个从 master 派生的带有几个附加提交的开发分支。一段时间后，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 结合使用将是理想的选择。如果它不能完成，那么我可能会允许合并提交......

4

3 回答 3

7

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

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

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

于 2011-12-08T23:09:19.423 回答
4

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

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

于 2011-12-06T20:02:41.643 回答
3

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

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

于 2011-12-06T20:54:55.230 回答