仍在努力学习如何使用Gerrit及其过程。我在哪里做的步骤
- 先推
change1 对HEAD进行评论：refs / for / develop
- 在同一个分支上处理其他事情并推送
change2 对HEAD进行评论：refs / for / develop
两个提交都有gerrit Change-ID行
所以现在我想解决问题 change1 所以我做了
git checkout -b change1 <change 1's commit id>
做出我的更改并提交（将Change-ID添加到提交消息）
git add .
git commit
现在当我这样做
git push origin HEAD:refs/for/develop
我明白了
! [remote rejected] HEAD -> refs/for/develop (squash commits first)
error: failed to push some refs to 'ssh://adrian@192.168.7.100:29418/CommunicationsLibrary'
如何解决堆叠评论中的问题并将其发布到gerrit而无需创建另一个评论？
如果您在Gerrit中有依赖性评论（也就是说，评审中的一个更改取决于同时审核的早期更改），并且您需要对之前的更改进行修改，则您实际上必须重新提交这两个更改（因为第二次更改取决于不同的“父”提交）
所以情况是你在主开发分支的一个分支中有两个提交，如下所示：
o master
\
o Commit A (in review, requires change)
o Commit B (in review, no changes required)
在这种情况下，我通常做的是在第三次提交中进行Commit A请求的更改。我们的提交图现在看起来像这样：
o master
\
o Commit A (in review, requires change)
o Commit B (in review, no changes required)
o Commit C (modifications to Commit A)
现在我做 git rebase -i master 并且在提交A之后但在提交B之前重新排序提交C，然后将其压缩到提交A.提交图现在看起来像这样：
o master
\
o Commit A' (Commit A, incorporating the changes from Commit C)
o Commit B' (the same changes made in Commit B, but applied to Commit A' instead of A)
最后， git review （或者您用来向gerrit提交更改的任何命令）将这两个提交重新提交给Gerrit。
正是由于这样的复杂性，大多数人强烈建议在单独的分支中处理每个不同的更改，然后在提交给Gerrit之前压缩到单个提交，而不是需要处理这些类型的情况，其中您有依赖的更改被审查与此同时。
我认为你的问题与第一次提交的修正案现在将第二次提交作为依赖关系这一事实有关。这是我个人会做的，但可能有更好的方法。我看看它，因为你想改变你的提交方式，你正在处理最后的3.所以运行'git rebase -i HEAD~3'。这允许您通过切换顺序或将它们彼此融合来重新定义最后3次提交。您应该知道它以最早的顺序列出了提交。这是一个例子：
git日志如下：
提交信息：......
消息：foo2
提交信息：......
消息：bar1
提交信息：......
消息：foo1
运行上面的命令后，编辑器应弹出以下内容：
选择foo1。
选择吧1。
选择foo2。
（这假设您的第二个foo更改没有更改bar1更改的任何文件，因为这可能不起作用，如果您这样做，您应该已经修改了提交。）然后将列表更改为：
选择foo1
fixup foo2
选择吧1
之后，你将把foo1和foo2压缩成一个提交，bar1将是后面的提交。然后我会运行'git reset --soft HEAD~1'重置最新的提交，然后是'git commit --amend'，它允许你更改第一次审核的提交消息，并确保包含change-id 。然后尝试你的推动。之后，您应该设置一个新的补丁，第二次更改的所有文件将被修改并仍在您的工作目录中。
只需git commit --amend然后git review