Gerrit：与多个分支合作并传播更改

Question

我正在尝试确定Gerrit上的多个分支机构的适当工作方式，以符合我们的工作流程。

我们现在与分支机构合作的方式是：我们有主人&功能分支。硕士是我们想要打磨的分支，并准备发布，而功能显然是一个密集的工作领域。现在，在我们的特定情况下，每当有人工作在一个bug修正，它们：

• 创建针对主分支的变化
• 樱桃它挑到特性分支目标改变
• 一次格里特代码审查完成后，提交两个更改。

现在我明白樱桃选择的方式，它选择单个提交并将其合并到当前更改中。如果是这样的话，我希望最终没有合并冲突，事实上，这个工作流程完全适用于GIT。然而，Gerrit最有可能归因于其本质（分支机构不是以远程方式合并，而是获得不同的sha标签），最终列出了大量冲突文件。

现在，我解决了所有这些问题，通过应用合并策略（我们的功能，他们对主），但它不觉得正确：如果没有传播任何东西，它只是被丢弃。

我的问题是：是否有安全工作流程，类似于上述那样，最终会产生与gerrit的干净合并？

Answer 1

我会说，在这种情况下，合并比樱桃采摘更好。

樱桃镐增加相同的变化但不一样承诺。所以虽然来源是相同的樱桃挑选和合并git树是不同的。当树不同，你后来做一个合并git会认为你以前樱桃挑选的提交丢失，并尝试合并该更改，即使实际的代码已经存在。这可能是你为什么会遇到很多冲突的原因。

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

• 当你做正常的工作，你就功能开发和推向格里特正常。
• 当您在稳定的生产环境做一个补丁（即错误修复），你这样做，直接在主（或当地的分支机构，如果你喜欢，但不是功能）
• 当补丁在被批准Gerrit将其合并到真正的主文件中，并且您可以制作请求将该更改提供给您的本地副本。你主的版本现在一样Gerrits 主
• 现在你会合并在主所有新的修改功能。请确保你做一个变基使补丁最终你已经在功能
• 一旦它的时间来部署所有的新功能做任何事情之前，你可以合并功能到主，推到格里特（如果您有权限，您可以通过传球直接/推到主，而不是裁判对/主格里特因为这些变化已经审查）
• 一旦所有的变化都在Gerrits 主您在做一个拉主人和mer ge into feature with rebase making feature clean clean branch to work on。每个版本都有一个新的功能当然是完全有效的。两者都很好。

Answer 2

我有点困惑，因为这个流程应该工作得很好。如果其他用户在您的错误修复被审查/验证/提交之前提交了更改，则可能导致合并冲突，但这应该很少见。

如果您：

1. 修复
2. 上主的错误推到审查（创造格里特改变A）的特性分支的顶部
3. 摘樱桃的变化A（解决任何冲突主人为特色）
4. 推樱桃采摘变化审查（创建改变B）
5. 评论/验证/提交变化的&乙

一切都会正常工作。合并冲突发生的唯一方法是其他用户上传并在步骤1和5之间提交更改。您是否看到不同的行为？你能提供更多细节吗？