我正在尝试确定在Gerrit上使用多个与我们的工作流程匹配的分支的正确方法。
我们现在使用分支的方式是：我们拥有master＆Feature分支。 Master是我们要完善并准备发布的分支，而功能显然是一个工作量很大的领域。现在，在我们的特殊情况下，只要有人进行错误修复，他们就会：
创建针对主分支的更改
樱桃选择它到功能分支有针对性的更改
Gerrit代码审核完成后，请提交两个更改。
现在，按我理解的方式，它将选择单个提交并将其合并到当前更改中。如果真是这样，我希望最终不会有合并冲突，而实际上，此工作流程仅与GIT完美配合。然而，Gerrit最有可能由于其性质（分支不会以本地方式合并并获得不同的sha标签的方式进行远程合并）最终列出了大量冲突文件。
现在，我通过应用合并策略解决了所有这些问题（功能使用我们的功能，母版使用我们的策略），但是感觉不对：如果没有传播任何内容，则将其丢弃。
我的问题是：是否有一个安全的工作流程，类似于上面的工作流程，最终会与gerrit产生干净的合并？
最佳答案
我想说，在这种情况下，合并要比选择樱桃更好。
樱桃选择会添加相同的更改，但不会添加相同的提交。因此，尽管樱桃采摘和合并中的来源相同，但git树却不同。当树不同时，您稍后进行合并，git会认为您先前选择的提交丢失了，即使实际的代码已经存在，也尝试合并该更改。这可能就是为什么您会遇到很多冲突的原因。
我会提出另一种工作方式。
当您完成正常工作时，便会开发功能并像往常一样使用Gerrit。
当您在稳定的生产环境上打补丁（即错误修复）时，您可以直接在master（或本地分支，如果您愿意，但不对功能）上进行补丁
当Gerrit批准该补丁后，该补丁将合并到真正的主服务器中，您可以发出请求请求以将更改更改为本地副本。您的master版本现在与Gerrits master相同
现在，您将把master上的所有新更改合并到feature中。确保您进行了基准调整，以使补丁在您完成对功能的任何操作之前就结束了
是时候部署所有新功能了，您可以将功能合并到master中，推送到Gerrit（如果您具有权限，则可以通过直接推送到master而不是refs / for / master来传递gerrit，因为这些更改已被审核）
一旦所有更改都在Gerrits master上，您就可以对master进行拉动，并合并到具有rebase的功能中，从而使该功能成为一个干净的分支可以使用。每个发行版都有一个新功能当然是完全有效的。两者都很好。
关于merge - Gerrit:与多个分支机构合作并传播变更，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/11700246/