14

我发现当在Gerrit Web 界面中单击“提交补丁集”时，它要么只是向该分支添加一个提交，要么在之前提交另一个提交时创建一个合并提交。

创建 2 次提交的示例：实际提交和合并提交：

  1. 用户根据提交 O 提交补丁集 A
  2. 用户根据提交 O 提交补丁集 B
  3. 提交补丁集 A
  4. 提交补丁集 B --> 在 O -> A 和 O -> B 之间创建合并提交

有一个“Rebase Change”按钮很棒，但这意味着提交补丁集每个人都应该这样做：

  1. 单击变基更改
  2. 单击提交更改集

我认为合并提交有用的唯一原因是保留提交的日期（但我确实理解为什么在没有变基的情况下需要它）。

是否没有自动变基或至少检查以避免生成不希望的合并提交？

4

2 回答 2

14

是的。将项目的提交操作更改为 Cherry Pick。这与按下提交按钮时的 rebase 大致相同。提交更改时，它将保留您正在寻找的干净历史记录，而无需合并提交。

于 2012-07-25T15:12:44.663 回答
0

您可以通过访问项目设置页面并选择“必要时变基”而不是“必要时合并”来更改项目的默认提交类型。

有关提交类型的完整文档，请参阅：https ://gerrit-review.googlesource.com/Documentation/config-project-config.html#submit-type

任何项目所有者都可以通过项目控制台（Projects > List > my/project）修改 Gerrit 用来提交项目更改的方法。通常，仅当所有依赖项也都提交时才合并提交的更改，下面记录了例外情况。支持以下提交类型：

  1. 继承

    这是新项目的默认设置，除非被全局 defaultSubmitType 选项覆盖。

    从父项目继承提交类型。在 All-Projects 中，这相当于 Merge If Necessary。

  2. 仅快进

    使用这种方法，Gerrit 不会在提交更改时创建合并提交。仍然可以提交合并提交，但必须在上传到 Gerrit 进行审查之前在客户端上创建它们。

    要提交更改，更改必须是目标分支的严格超集。也就是说，更改必须在提交时已经包含目标分支的尖端。

  3. 必要时合并

    如果提交的更改是目标分支的严格超集，则该分支将快速转发到更改。如果没有，则自动创建合并提交。这与经典的 git merge 行为或 git merge --ff 相同。

  4. 始终合并

    始终生成合并提交，即使更改是目标分支的严格超集。这与 git merge --no-ff 的行为相同，如果项目需要使用 git log --first-parent 跟随提交，这可能会很有用。

  5. 樱桃采摘

    总是选择补丁集，忽略父血统，而是在当前分支头上创建一个全新的提交。

    当挑选更改时，Gerrit 会自动在提交消息的末尾附加更改批准的简短摘要，以及返回 Web 上更改的 URL 链接。提交者头也设置为提交者，而作者头保留原始补丁集作者。

    请注意，Gerrit 在使用此提交类型时会忽略更改之间的依赖关系，除非启用了 change.submitWholeTopic 并且依赖的更改共享相同的主题。所以一般提交者在使用这种提交类型时必须记住以正确的顺序提交更改。如果您想要的只是提交消息中的额外信息，请考虑使用 Rebase Always submit 策略。

  6. 必要时变基

    如果提交的更改是目标分支的严格超集，则该分支将快速转发到更改。如果不是，则更改会自动重新定位，然后分支会快速转发到更改。

    当 Gerrit 尝试进行合并时，默认情况下只有在没有路径冲突的情况下合并才会成功。当同一文件在合并的另一侧也已更改时，会发生路径冲突。

  7. 总是变基

    基本上，与 Rebase If Necessary 相同，但即使可以快进，它也会创建一个新的补丁集，并且像 Cherry Pick 一样，它确保诸如 Change-Id、Reviewed-On 等页脚存在于合并的结果提交中。

    因此，Rebase Always 可以被认为类似于 Cherry Pick，但重要的区别是 Rebase Always 不会忽略依赖项。

于 2019-10-29T19:38:27.640 回答