Gerrit、git、ブランチ全体のレビュー

現在、Gerrit（これは私が使用する最初のコードレビューツールです）を学んでいます。Gerritは、単一のコミットで構成されるようにレビューされた変更を必要とします。私の機能ブランチには約10のコミットがあります。

メリットを優先する方法は、これらの10個のコミットを1つのコミットに押しつぶすことです。ただし、この方法でコミットがターゲットブランチにマージされる場合、その機能ブランチの内部履歴は失われます。たとえば、git-bisectこれらのコミットを二分するために使用することはできません。私は正しいですか？

私はこの状態について少し心配しています。この選択の理由は何ですか？歴史を失うことなく、Gerritでこれを行う方法はありますか？

コードレビューは、コミット前（gitの場合はプッシュ前）のフックである場合に最も効果があります。10回のコミットのうち5回目にエラーが発生した場合、どのように修正しますか（履歴を保持）？もちろん、別のトピックブランチを作成し、そのコミットを修正し、残りの5つのコミットを選択して、レビューのために差分を再送信できますが、これは非常に複雑です（ただし、スクリプトを記述できます）。

単一のリポジトリに加えられた変更は、その状態を理想的に維持する必要があります（たとえば、ビルド、テストなどを壊さないでください）。このように変更が行われた場合、それらは個別にレビューできます。矛盾。

バグトラッカーでバグを作成し、すべてのコミットに参照を含めることで、レビュー担当者や将来の読者が全体として達成しようとしていることを知ることができます。

継続的な統合についてはどうですか？機能ブランチで10回のコミットを行った場合、一度に「公開」されます。これは、それらのコミット/変更を確認する必要がある他のユーザーに大きな影響を与えることになります。

ただし、コミットに個別のコード変更が含まれている場合は、10のコミットをプッシュする価値があります。ただし、コミットに単一の機能に対する継続的な変更が含まれている場合（そのため、ほとんどのコミットは、関数定義の継続的な実装の修正または中間ステータスにすぎません）、それらを単一のコミットに押しつぶした方がよいでしょう。

一般に、レビュアーを念頭に置いて考えてください。簡単にレビューできるコード変更のサイズはどのくらいですか。

注： Gerritはコードを確認するためだけのものではありません-変更により、いくつかの受け入れテストがトリガーされます。（単体テスト、スモークテスト）そのため、これらがある場合、不良コードを公開することは困難です。したがって、この観点から見ると、コミットにはテストに値する変更が含まれているはずです。

したがって、Gerritは、小さすぎる変更や大きすぎる変更をコミットしないように強制します。（--amendレビューのためにプッシュしたいコミットを修正するのではなく、すでにGerritにプッシュされた変更を修正するためだけに使用します）