2
歴史の中で一貫性のないコミットを維持し、私は次のように（私の知る限り、それは、単一の開発者のための非常に一般的なワークフローです）、それを使用しようとしている：機能ブランチを作成gitのワークフロー：私はgitのでは初心者だ
- いくつかのWIPコミットを伴い、いくつかの作業を行います。
- 完了したら、これらのWIPコミットを、整合性のとれたもの（コンパイルとテストに合格したもの）に再編成して、履歴をクリアします。
- マージ機能は、マスターに分岐します。
私はいくつかのプロジェクト（1つのワークスペース、つまり作業ツリーに関連する）を新しいバージョンのコンパイラに移行しようとしています。機能ブランチでmsvc90私は多くの作業を準備しました。
- 大きなコミット（-m "MSVC 9.0への移行"）を1つ作成します。
- 新しいプロジェクトファイルの作成、古いプロジェクトの削除、コンパイラの警告を取り除くためのソースコードのチューニング、バグの修正など、履歴の移行のいくつかのステップを維持するためのコミットをいくつか作成します。これらのコミットは、一貫性がありません（例えば、新しいプロジェクトファイルを使用して、未調整のソースコードを使用すると、コンパイルエラーが発生します）。
私の質問はかなり哲学的です。 2番目の選択肢は、私が少し歴史的に詳細を保持しているので、私にとってはやや好ましいようです。一方、私は、一貫性のあるコミットを維持することを推奨するいくつかのgitチュートリアルを読んでいます（例えば、bisectを使用するなど）。
この種の矛盾したコミットを（ブランチ上で）保持することを許可する大きなプロジェクトの例を知っている人はいますか？