18

仍在尝试学习如何使用 Gerrit 及其过程。我在哪里做的步骤

  1. 首先推change1送到 gerrit 以审查 HEAD:refs/for/develop
  2. 在同一分支上处理其他事情并推change2送到 gerrit 以供 HEAD 审查：refs/for/develop

两个提交都有 gerrit Change-ID 行

所以现在我想解决问题，change1所以我做到了

git checkout -b change1 <change 1's commit id>

进行更改并提交（将更改 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 而无需创建另一个评论？

4

6 回答 6

19

当您在 Gerrit 中有依赖评审（即评审中的一个更改依赖于同时处于评审中的较早更改），并且您需要对较早的更改进行修改时，您实际上必须重新提交这两个更改（因为第二个更改取决于不同的“父”提交）

所以情况是您在主开发分支的一个分支中有两个提交，如下所示：

o master
\
 o Commit A (in review, requires change)
 o Commit B (in review, no changes required)

在这种情况下，我通常做的是在第三次提交中对提交 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提交 C 重新排序到提交 A 之后但在提交 B 之前，然后将其压缩到提交 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 之前压缩成一个提交，而不是需要处理这些类型的情况，即您需要审查相关的更改同时。

于 2012-09-19T02:55:22.670 回答
2

我认为您的问题与第一次提交的修改现在将第二次提交作为依赖项有关。这是我个人会做的，但可能有更好的方法。我看着它，因为你想重新调整你的提交方式并且你正在处理最后 3 个。所以运行'git rebase -i HEAD~3'。这允许您通过切换顺序或将它们相互融合来重新调整最后 3 次提交。您应该知道它以最旧的优先顺序列出提交。这是一个例子：

git日志如下：

提交信息：......

消息：foo2

提交信息：......

消息：bar1

提交信息：......

消息：foo1

运行上述命令后，编辑器应弹出以下内容：

选择 foo1。

选择栏1。

选择 foo2。

（这是假设您的第二次 foo 更改没有更改 bar1 更改的任何文件，因为这可能不起作用，如果您这样做了，您应该已经修改了提交。）然后将列表更改为：

选择 foo1

修复 foo2

选择栏1

之后，您将 foo1 和 foo2 压缩为一个提交，而 bar1 将是以下提交。然后我会运行'git reset --soft HEAD~1'来重置最新的提交，然后是'git commit --amend'，它允许你更改第一次审查的提交消息并确保包含change-id . 然后试试你的推。之后，您应该设置一个新补丁，并且第二次更改的所有文件都将被修改，并且仍然在您的工作目录中。

于 2012-09-19T03:17:21.020 回答
0

称呼

commit --ammend

而不是你的第二次改变

于 2016-03-15T06:49:18.480 回答
0

情况与@Trevor 解释的完全一样。rebase -i当你有这种情况时，这是一个很好的方法。

就个人而言，我也使用这个命令，但有一点不同：

1. 使用 --fixup 和 --autosquash

你有两个提交：

old commit
new commit

当您想更改旧提交时，然后

 git commit --fixup <old_commit_id>

然后用 autosquash 变基，

git rebase -i --autosquash <commit_id_before_old_commit>

如果不清楚我的评论，您可以查看详细信息： https ://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html

或者

2. 利用 Gerrit

在您提交两个更改后，您的 GUI 上将有两个公开评论更改。

然后转到您的“旧更改”，选择下载->签出此更改，实际上在您签出后，您将转到此更改的分支，然后修复您的代码，修改，变基，推送......就像您所做的那样通常。

于 2020-01-23T10:53:08.013 回答
-1

只需 git commit --amend 然后 git review

于 2018-01-05T09:44:48.553 回答
-2

我尝试了这些尝试

  1. git rebase -i master
    没用
  2. 然后最后我做了什么，我备份了文件。删除了整个项目。然后再次克隆它。从备份中将文件粘贴到所需文件夹中，然后再次重新提交，然后推送。有效 。
于 2017-05-19T10:20:22.737 回答