我发现当在 Gerrit 网页界面中点击“提交补丁集”时，它要么简单地向该分支添加一个提交，要么在之前提交另一个提交时创建一个合并提交.
创建 2 个提交的示例：实际提交和合并提交：
有一个“Rebase Change”按钮很棒，但这意味着提交补丁集每个人都应该这样做：
我认为合并提交有用的唯一原因是保留提交的日期（但我确实理解为什么在没有变基的情况下需要它）。
是否有自动变基或至少检查以避免生成不希望的合并提交？
【问题讨论】：
git config branch.autosetuprebase不相关。
标签： merge submit gerrit rebase
是的。将项目的提交操作更改为 Cherry Pick。这与按下提交按钮时的 rebase 大致相同。提交更改时，它将保留您正在寻找的干净历史记录，而无需合并提交。
【讨论】：
您可以通过访问项目设置页面并选择“必要时变基”而不是“必要时合并”来更改项目的默认提交类型。
有关提交类型的完整文档，请参阅：https://gerrit-review.googlesource.com/Documentation/config-project-config.html#submit-type
Gerrit 用来提交项目变更的方法可以修改 由任何项目所有者通过项目控制台，项目 > 列表 > 我的项目。通常，提交的更改仅在其所有 还提交了依赖项，但下面记录了例外情况。这 支持以下提交类型：
继承
这是新项目的默认设置，除非被全局 defaultSubmitType 选项覆盖。
从父项目继承提交类型。在 All-Projects 中，这相当于 Merge If Necessary。
仅快进
使用此方法，Gerrit 不会在提交更改时创建合并提交。合并提交可能仍会提交，但它们 必须在上传到 Gerrit 进行审核之前在客户端上创建。
要提交更改，更改必须是目标分支的严格超集。也就是说，更改必须已经包含提示 提交时的目标分支。
必要时合并
如果提交的更改是目标分支的严格超集，则该分支将快进到更改。 如果没有，则自动创建合并提交。这是 与经典的 git merge 行为或 git merge --ff 相同。
始终合并
始终生成合并提交，即使更改是目标分支的严格超集。这与行为相同 git merge --no-ff，如果项目需要遵循，可能会很有用 使用 git log --first-parent 提交。
樱桃采摘
始终选择补丁集，忽略父沿袭，而是在当前分支头之上创建一个全新的提交。
在挑选更改时，Gerrit 会自动在提交消息的末尾附加更改的简短摘要 批准，以及返回 Web 上更改的 URL 链接。提交者 标头也设置为提交者，而作者标头保留 原始补丁集作者。
请注意，Gerrit 在使用此提交类型时会忽略更改之间的依赖关系，除非启用了 change.submitWholeTopic 并且 依赖的变化共享相同的主题。所以通常提交者必须 使用此提交时记得按正确的顺序提交更改 类型。如果您想要的只是提交消息中的额外信息， 考虑使用 Rebase Always submit 策略。
必要时变基
如果提交的更改是目标分支的严格超集，则该分支将快进到更改。 如果没有，那么更改会自动重新定位，然后分支 快进到更改。
当 Gerrit 尝试进行合并时，默认情况下，只有在没有路径冲突的情况下合并才会成功。路径冲突发生时 合并的另一端也更改了相同的文件。
总是变基
基本上，与 Rebase If Necessary 相同，但它会创建一个新的补丁集，即使快进是可能的并且像 Cherry Pick 它一样 确保存在 Change-Id、Reviewed-On 等页脚 在合并的结果提交中。
因此，Rebase Always 可以被认为类似于 Cherry Pick，但具有 Rebase Always 不会忽略的重要区别 依赖关系。
【讨论】：