我正在努力确定在Gerrit上使用多个分支的正确方式，以匹配我们的工作流程。
我们现在与分支机构合作的方式是：我们有master&功能分支。Master是我们想要打磨并准备发布的分支，而特性显然是一个密集的工作领域。现在，在我们的特殊情况下，每当有人修复错误时，他们：
- 创建针对master分支的更改
- cherry pick it to the feature branch targeted change
- gerrit代码审查完成后，提交两个更改
现在，按照我理解cherry-pick的方式，它选择单个提交并将其合并到当前更改中。如果是这样的话，我希望最终不会有合并冲突，事实上，这个工作流只适用于GIT。然而，Gerrit很可能是由于其性质（分支并不像本地那样远程合并，并获得不同的sha标记），最终列出了大量冲突文件。
现在，我通过应用合并策略解决了所有这些问题（我们的策略在功能上，他们的策略在主策略上），但感觉不对：如果任何东西没有传播，它就会被丢弃。
我的问题是：是否有一个安全的工作流，类似于上面的工作流，最终会产生与gerrit的干净合并？
我想说，在这种情况下，合并比樱桃采摘更好。
cherry pick添加相同的更改，但不添加相同的提交。因此，虽然cherry pick和merge上的源代码相同，但git树不同。当树不同并且您稍后进行合并时，git会认为您之前精心挑选的提交丢失，并尝试合并该更改，即使实际代码已经存在。这可能就是为什么你会遇到很多冲突的原因。
我会提出另一种工作方式。
- 当你做正常的工作时，你会开发功能，并像往常一样推动Gerrit
- 当你在稳定的生产环境上进行补丁（即bug修复）时，你可以直接在master上进行（如果你喜欢，也可以在功能的本地分支上进行）
- 当补丁在Gerrit中获得批准时，它会被合并到真正的主中，您可以发出pull请求，将更改更改添加到您的本地副本中。您的master版本现在与Gerritsmaster相同
- 现在，您可以将master上的所有新更改合并到功能中。请确保您执行重新基本，以便补丁在您对功能执行任何操作之前结束
- 一旦到了部署所有新功能的时候，您就可以将功能合并到主中，推送到Gerrit（如果您有权限，您可以通过直接推送到主机而不是refs/for/master来传递Gerrit，因为这些更改已经过审查）
- 一旦所有更改都在Gerritsmaster上，您就可以对master进行拉取，并通过rebase合并到功能中，使特性成为一个干净的分支。当然，每次发布都有一个新的特征是完全有效的。两者都很好
我有点困惑，因为这个流应该可以正常工作。如果其他用户在审查/验证/提交您的错误修复之前提交了更改，这可能会导致合并冲突，但这种情况应该很少见。
如果您：
- 修复master上的错误
- 推动审查（在gerrit中创建更改A）
- cherry-pick特性分支顶部的更改A（解决从主特性到特性的任何冲突）
- 将精心挑选的更改推送审查（创建更改B）
- 审查/验证/提交更改A&B
一切都会好起来的。发生合并冲突的唯一方法是其他用户在步骤1和步骤5之间上传和提交更改。你看到了不同的行为吗？你能提供更多细节吗？