我在一个小团队中工作，使用Git / Gerrit作为源代码控制/代码审查 当团队中的开发人员想要提交他们的工作时，他们会提交/推动gerrit并开始研究新功能 此外，鼓励开发人员尽可能地推动他们的工作，他们通常在已提交的更改（通过挑选相关更改）之上工作，这些更改目前正在审核中。
问题是，当开发人员试图推动变革时，他们也会推动变革的历史。作为副作用，这些更改获得的新版本与同一更改的先前版本没有区别。此外，开发人员现在必须获得'伪造'许可（假设一些樱桃选择的变化不是他的）
实施例： 假设Adam的一个分支的历史看起来像这样（更高的变化是最新的）：
改变3（作者：亚当，目前正在工作）
改变2（Ahthor：Charlie）
改变1（作者：巴斯）
现在，改变1,2是从gerrit挑选出来的，并没有改变 当Adam推送他的补丁时，他必须能够在更改1,2上伪造提交者并且他们获得更新的版本（与之前的推送没有任何区别）
有人可以建议如何避免这种行为吗？我们做错了吗？
答案 0 :(得分：1)
我们公司遇到了类似的问题。 Gerrit带有一个脚本，您应该将其添加到本地存储库（它可以在windows，mac和linux下运行）。它在向本地存储库提交时自动运行并生成提交ID（在提交消息的末尾添加它）。
如果稍后提交的SHA1发生更改（例如由于修改），Gerrit将看到它是相同的提交并且不会创建新的入口点，如果提交仍然存在，它将只更新文件正在审查中。
要复制脚本，请转到存储库并执行以下操作：
scp -p -P 29418 username@path.gerrit.server.com:hooks/commit-msg .git/hooks/
答案 1 :(得分：1)
Gerrit正在创建这些补丁集的新版本，因为是更改 - 当开发人员挑选出需要审核的更改时，会修改git提交。提交现在具有不同的父级和不同的SHA1。
有两种方法可以避免这种情况：
在dayjob，我们根据情况使用这两种方法的组合。祝你好运！