コミットは小さすぎると考えられますか？
ソース管理の使用方法は、開発者によって、またプロジェクトによって大きく異なります。非常に頻繁にコミットする人もいます。他の人は、コミットせずに1日または数日過ごすことができます（特に、プロジェクトだけで作業する場合、または他のチームメンバーがプロジェクトの非常に異なる部分で作業していることを知っている場合）。
例
ときどき、実生活とWebキャストやその他の学習資料の両方で、非常に小さなコミットを見たことがあります。いくつかの例は、主に実生活からのものです：
バグを解決するコミット＃...またはコードの1行を変更することで機能＃...を実装する。
私見、これはコミットの完全に有効なケースです。特に、バグ追跡システムがバージョン管理にリンクされていて、リビジョンに従って自動的に更新される場合はそうです。このリンクがなくても、バグの解決や機能の実装に必要な変更の数に関係なく、どのコミットが何を解決したかを追跡することは有用です。
単一の構成設定を変更するコミット（コンテキスト内では、構成設定はソース管理にある必要があります）。
私見、前の設定がビルドを壊したり、バグを引き起こしたり、他の開発者に影響を与えたり（たとえば、テストデータベースサーバーの移行後に変更された接続文字列）したりしない限り、これは別のコミットとマージされることがあります。
たとえばユーザーに表示される文字列内のWordのスペルを修正するコミット。
私見、ほとんどの場合、これは別のコミットとマージできます（ただし、ビルドが壊れない限り）。 HTTP refererのように、マージできない場合の唯一のケースは、残された場合、間違ったスペルがコードを通じて伝播され、後で変更するのが複雑または不可能になる場合です。ヘッダー 。
メソッドにコメントを追加する（メソッドがすでに十分明示的であった場合）、またはスタイルに関連する別のマイナーなルールを解決するコミット。
例：.NET Frameworkでは、StyleCopはすべてのメソッドを文書化する必要があり、コンストラクター（メソッドでもある）のXMLDocコメントは次で始まる必要があります。
<ここにクラス名>クラスの新しいインスタンスを初期化します。
コミットにより、この最後のルールを適用して、レガシーコードのコメントを置き換えることができます。
指定された数の車輪を持つ新しい車両を作成します。
沿って：
指定された数のホイールを使用して、Vehicleクラスの新しいインスタンスを初期化します。
つまり、改訂は、コードベースで使用されているスタイル標準にコードを適合させること以外に意味はありません。
私見、これはあらゆる場合に別のコミットとマージできます（結局、いくつかの場所でいくつかの変更がない限り、スタイル関連のルールをコミット時に適用して、それらに一致しないコードのコミットを拒否する必要があります）。
ご質問
それらの点で私は間違っていますか？
コミットが小さすぎるなどのことはありますか、それとも非常に頻繁にコミットすることがベストプラクティスですか？
リビジョンログを「汚染」し、誰も気にせず、ビルドを中断または解除せず、他に影響を及ぼさない小さな変更の中から関連する変更を見つけるのが難しくなることを考えると、小さすぎる変更をコミットする価値はありますか開発者？
これはスタイル/好みの問題なので、間違った言葉は強すぎます。しかし、私の好みは明らかにあなたのものと正反対です。
コーディングスタイルの編集と小さなドキュメントの変更が自分のコミットで行われるのを見るのが私はとても好きです。コードレビューを行っている場合、またはバグが発生した場所を特定しようとしている場合、各コミットが6ダースのランダムな問題に触れないようにすると、muchより簡単になります。私の世界では、理想的なコミットによって1つのバグが修正されるか、1つの機能が完了します。そうすることで、修正や新しい機能に深刻な問題があることが判明した場合、それを取り消すのははるかに簡単です。問題に関係のない変更を手に取り、もつれを解く必要はありません。
ここで、ドキュメント/フォーマットの問題のみである変更のバッチがある場合は、それらを一緒にバンドルしてください。コミットコメントは、「フォーマット/ドキュメントの変更のみ」を示す必要があります。
まず、この質問に対するone回答はないと思います。ご指摘のとおり、個人とプロジェクトでは大きく異なります。
SoC（懸念の分離）のようなものをコミットに適用します。つまり、私は「タスクごと」にコミットしようとします。または、言い換えると、「作業のいくつかの領域」を一度にコミットしないようにします。その意味では、コミットが小さすぎるということはありません。
小さなコミットは素晴らしいです。私見、小さいほど良い。特に、小さなコミットは簡単にレビューできるので良いです。私は、それらすべてを組み込んだ1つの大きな変更ではなく、5つの小さな独立した変更を確認したいと思います。
コメントが正確である限り、コミットが小さすぎるとは思いません。コミットコメントの欠如または誤解を招くコメントは非難されます。
個人的には、論理グループの変更をコミットすることを好みます。論理的な変更を行う前にリファクタリングを行うコミットと、バグを修正するための変更をコミットするコミットです。
また、コメントにはある程度の詳細を含めることを好みます。そのため、同じコメントでカバーできる関連変更を収集するために、変更されたすべてのファイルを調べ、他のファイルには適用されない詳細が必要なものを分離します。