18

Gerritとそのプロセスの使い方をまだ学ぼうとしています。私が行った手順

  1. change1HEAD：refs / for/developへのレビューのために最初にgerritにプッシュします
  2. 同じブランチで他の何かchange2に取り組み、HEAD：refs / for/developへのレビューのためにgerritにプッシュします

両方のコミットにgerritChange-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に投稿するにはどうすればよいですか？

4

6 に答える 6

19

Gerritに依存レビューがある場合（つまり、同時にレビューされている以前の変更に依存するレビューの1つの変更）、以前の変更に変更を加える必要がある場合は、両方の変更を効果的に再送信する必要があります（ 2番目の変更は、別の「親」コミットに依存するようになります）

したがって、次のように、メインの開発ブランチから離れた1つのブランチに2つのコミットがある場合があります。

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

この状況で私が一般的に行うことは、3番目のコミットでコミット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

あなたの問題は、1番目のコミットの修正に2番目のコミットが依存関係として含まれているという事実に関連していると思います。これは私が個人的に行うことですが、もっと良い方法があるかもしれません。コミットの方法をリベースしたいので、最後の3を処理しているので、「git rebase -iHEAD〜3」を実行します。これにより、順序を切り替えるか、相互にマージすることで、最後の3つのコミットをリベースできます。コミットが最も古いものから順にリストされていることに注意してください。次に例を示します。

gitログは次のとおりです。

コミット情報：.....。

メッセージ：foo2

コミット情報：.....。

メッセージ：bar1

コミット情報：.....。

メッセージ：foo1

上記のコマンドを実行した後、エディターは次のようにポップアップするはずです。

foo1を選択します。

bar1を選択します。

foo2を選択します。

（これは、2番目のfooの変更で、bar1が変更したファイルが変更されなかったと想定しています。これは機能しない可能性があるためです。変更した場合は、とにかくコミットを修正する必要があります。）次に、リストを次のように変更します。

foo1を選ぶ

修正foo2

ピックバー1

その後、foo1とfoo2が1つのコミットに押しつぶされ、bar1が次のコミットになります。次に、「git reset --soft HEAD〜1」を実行して最新のコミットをリセットし、続いて「git commit --amend」を実行して、最初のレビューのコミットメッセージを変更し、change-idを含めるようにします。 。次に、プッシュしてみてください。その後、新しいパッチを設定する必要があります。2番目に変更されたすべてのファイルが変更され、作業ディレクトリに残ります。

于 2012-09-19T03:17:21.020 に答える
0

電話

commit --ammend

代わりに2回目の変更

于 2016-03-15T06:49:18.480 に答える
0

状況は@Trevorが説明したのとまったく同じです。rebase -iあなたがこの状態にあるときに行うための良い方法です。

個人的には、このコマンドも使用しますが、少し異なります。

1.--fixupと--autosquashを使用します

2つのコミットがあります：

old commit
new commit

古いコミットを変更したい場合は、

 git commit --fixup <old_commit_id>

次に、オートスカッシュでリベースします。

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を利用する

2つの変更をコミットすると、GUIで2つのオープンレビューの変更が行われます。

次に、「古い変更」に移動し、[ダウンロード]-> [この変更をチェックアウト]を選択します。実際にチェックアウトした後、この変更のブランチに移動し、コードを修正し、修正し、リベースし、プッシュします...いつもの。

于 2020-01-23T10:53:08.013 に答える
-1

git commit --amend then gitreview

于 2018-01-05T09:44:48.553 に答える
-2

私はこれらの試みで試しました

  1. git rebase-imaster
    それは機能しませんでした
  2. それから最後に、ファイルのバックアップを取りました。プロジェクト全体を削除しました。その後、再度クローンを作成しました。バックアップから必要なフォルダにファイルを貼り付けてから、再度コミットしてからプッシュします。機能した 。
于 2017-05-19T10:20:22.737 に答える