7

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

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

  • 创建针对主分支的更改
  • 樱桃选择它到特性分支的目标更改
  • gerrit 代码审查完成后，提交这两项更改。

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

现在，我通过应用合并策略解决了所有这些问题（我们的在 feature 上，他们的在 master 上），但感觉不对：如果没有传播任何东西，它就会被丢弃。

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

4

2 回答 2

9

我想说，在这种情况下，合并比挑选樱桃要好。

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

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

  • 当你做正常的工作时，你会开发功能并像往常一样推送到 Gerrit。
  • 当您在稳定的生产环境中进行补丁（即错误修复）时，您可以直接在master （或本地分支，如果您喜欢，但不是在feature）上执行此操作
  • 当补丁在 Gerrit 中获得批准时，它会被合并到真正的master中，您可以提出拉取请求以将该更改添加到您的本地副本。您的master版本现在与 Gerrits master相同
  • 现在您将master上的所有新更改合并到feature中。确保你做了一个rebase，以便补丁在你已经完成的任何功能之前结束
  • 一旦需要部署所有新功能，您可以将功能合并到master中，推送到 Gerrit（如果您有权限，您可以通过直接推送到master而不是 refs/for/master 来传递 gerrit，因为这些更改已经过审核）
  • 一旦所有更改都在 Gerrits master上，您可以拉上您的master并合并到具有rebase的功能，使功能成为一个干净的分支来工作。当然，每个版本都有一个新功能是完全有效的。两者都工作正常。
于 2013-02-04T19:02:39.113 回答
0

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

如果你：

  1. 修复master上的一个bug
  2. Push to review（在 gerrit 中创建变更 A）
  3. 特性分支顶部的cherry-pick change A（解决从主到特性的任何冲突）
  4. 推送精心挑选的变更以进行审查（创建变更 B）
  5. 查看/验证/提交更改 A 和 B

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

于 2012-07-31T19:35:48.130 回答