git にはさまざまなファイル状態の概念があることを知りました: 1. 新規 2. 変更済み 3. ステージング済み 4. コミット済み
たくさん検索した結果、コード レビューのために任意のツールに送信したい場合は、ローカル リポジトリにコミットし、それをコード レビュー用の中央リポジトリ セットにプッシュする必要があることがわかりました (Gerrit などのコード レビュー ツールによって)。 .
ここで、ファイルがコード レビュー プロセスを開始する前に状態 A であり、さらに 10 回のレビューのやり直し、つまりさらに 10 回の変更、つまりローカル リポジトリへのさらに 10 回のコミットを経て、最終的にファイルが状態 B になり、最終的にコミットされるべきであるとします。
状態 A から B まで 10 件のコミットが行われました。
これらの 10 のうち、4 つのコミットがファイルの同じセクション/部分にあったと仮定します。
したがって、最後に、レビューされ承認されたファイルの最終状態 B をメインの中央リポジトリにプッシュするとき、10 個のコミットを作成する必要があります。そのうちのいくつかの中間コミットはやり直し、つまり不要なコミットです。
しかし、私はそれらの不要なコミットを望んでいません。
私が考えることができるのは、最終状態 B が 1 つのコミットだけでリポジトリにプッシュされることに興味があるということです。
そのため、git ステージングされた変更をレビューのために送信できるようなアプローチ/ツールを探しています。レビュアーがレビューします。彼が拒否していくつかの変更を提案した場合、私は以前の変更をアンステージします。提案された変更を適用し、それらの変更をステージングして、レビューのために再度送信します。
したがって、最終的にコードのレビューが承認されたら、ステージングされた変更を 1 回コミットし、1 回の最終プッシュのみが必要になります。