merge - Gerrit:使用多个分支并传播更改

Question

我正在尝试确定在 Gerrit 上与我们的工作流程相匹配的多个分支的正确工作方式。

我们现在使用分支的方式是:我们有 master 和 feature 分支。 Master 是我们想要打磨并准备发布的分支，而 feature 显然是一个密集工作的领域。现在，在我们的特殊情况下，每当有人进行错误修复时，他们:

创建针对 master 分支的更改

选择它到功能分支目标更改

gerrit 代码审查完成后，提交两个更改。

现在我理解cherry-pick的方式，它选择单个提交并将其合并到当前更改。如果是这种情况，我希望最终不会有合并冲突，实际上这个工作流程仅适用于 GIT。然而，Gerrit 很可能由于其性质(分支不会像本地那样远程合并并获得不同的 sha 标签)最终列出了大量冲突的文件。

现在，我通过应用合并策略解决了所有这些问题(我们在功能上，他们在主上)，但感觉不对:如果没有传播任何东西，它就会被丢弃。

我的问题是:是否有一个安全的工作流程，类似于上面的工作流程，最终会与 gerrit 产生干净的合并？

Answer 1

我会说，在这种情况下，合并比挑选更好。

樱桃选择添加相同的更改但不相同的提交。因此，虽然在cherry pick和merge上的源是相同的，但git树是不同的。当树不同并且您稍后进行合并时，git 会认为您之前选择的提交丢失并尝试合并该更改，即使实际代码已经存在。这可能就是为什么你会遇到很多冲突的原因。

我会提出另一种工作方式。

当您进行正常工作时，您会在 上开发功能 并像往常一样推送到 Gerrit。

当您在稳定的生产环境上打补丁(即错误修复)时，您可以直接在 上执行此操作。大师 (或本地分支机构，如果您喜欢但不在 功能 上)

当补丁在 Gerrit 中获得批准后，它就会合并到真正的 中。大师并且您可以发出拉取请求以将该更改添加到您的本地副本。您的版本 大师现在与 Gerrits 相同 大师

现在您将合并 上的所有新更改大师进入 功能 .确保您进行了 rebase，以便补丁在您已经在 上完成的任何操作之前结束。功能

一旦需要部署所有新功能，您可以合并 功能 进入 大师 , 推送到 Gerrit(如果你有权限，你可以通过直接推送到 master 而不是 refs/for/master 来传递 gerrit，因为这些更改已经过审核)

一旦所有更改都在 Gerrits 上完成 大师你拉你的大师并合并到 功能 与 rebase 制作 功能 一个干净的分支来工作。拥有一个新的当然是完全有效的。功能 每次发布。两者都工作正常。