1

我在一个使用 Git/Gerrit 作为源代码控制/代码审查的小团队中工作。
当团队中的开发人员想要提交他们的工作时，他们提交/推送到 gerrit 并开始开发新功能。
此外，鼓励开发人员尽可能推动他们的工作，他们通常在已经提交的更改（通过挑选相关更改）之上工作，这些更改目前正在审查中。

问题是，当开发人员尝试推送更改时，他们也会推送更改的历史记录。作为副作用，这些更改会获得与相同更改的先前版本没有区别的新版本。此外，开发人员现在必须获得“伪造”许可（假设某些精心挑选的更改不是他的）

示例：假设亚当的一个分支的历史看起来像这样（更高的变化是最新的）：

Change 3（作者：Adam，目前在职）
Change 2（Athhor：Charlie）
Change 1（作者：Bath）
大师

现在，更改 1,2 是从 gerrit 中挑选出来的，并且没有更改。
当亚当推送他的补丁时，他必须能够在更改 1,2 上伪造提交者，并且他们会获得更新的版本（与之前的推送没有任何区别）

有人可以建议如何避免这种行为吗？我们做错了什么吗？

4

2 回答 2

2

Gerrit 正在创建这些补丁集的新版本，因为它们发生了变化——当开发人员精心挑选出待审查的变化时，它会修改 git 提交。提交现在具有不同的父级和不同的 SHA1。

有两种方法可以避免这种情况：

  1. 花时间正确审查/验证/合并仍在审查中的更改，然后再对其进行更多工作
  2. 与其在本地挑选更改，不如使用结帐。这将使现有的补丁集保持原样，因此顶部的任何提交都可以正常上传，而无需修改现有的补丁集。但是，这会将您在存储库中的位置移动到创建补丁集时所在的位置 - 自上传补丁集以来，您不会有任何已合并的提交。

在 dayjob，我们会根据情况结合使用这两种方法。祝你好运！

于 2012-10-22T21:47:50.513 回答
1

我们公司也有类似的问题。Gerrit 附带一个脚本，您应该将其添加到本地存储库（它在 windows、mac 和 linux 下工作）。当对本地存储库进行提交时，它会自动运行并生成提交 ID（将其添加到提交消息的末尾）。

如果稍后提交的 SHA1 发生更改（例如由于修改），Gerrit 将看到它是相同的提交并且不会创建新的入口点，如果提交仍在审查中，它只会更新文件。

要将脚本复制到您的存储库并执行以下操作：

scp -p -P 29418 username@path.gerrit.server.com:hooks/commit-msg .git/hooks/
于 2012-10-22T17:02:43.613 回答