すべてのコーディング標準とグッドプラクティスはさておき、Git自体が技術的に大きなコミットと小さなコミットをどのように処理するのか。たとえば、Gitは、どちらの場合でもブランチのマージ（たとえば、競合が少ない）でよりスマートになりますか、ガベージコレクションはより効率的になりますか、それとも同様のものですか？それとも違いはありますか？
明確にするために、私はコードがAからBに変更されているシナリオを意味し、「巨大なコミット」はコードをAからBに直接変更するだけですが、「小さなコミット」には多くの中間コミットがあります（たとえば、小さな機能の変更ごとに）、最終的にはまったく同じBになります。
「多くの小さなコミット」はわずかに多くのスペースを使用しますが、その違いは失われた履歴の代償を払う価値がない可能性があります。
パックファイル自体への影響は、後で変更されなかった変更の数によって異なります。たとえば、後のコミットが前のコミットも触れた行に触れた場合、それらの行の中間状態は1つの大きなコミットで履歴に表示されないため、パックファイルにそれらを表すオブジェクトはありません。
ブランチでのコミットの数がマージの複雑さを軽減または増加させるとは想像できません。しかし、再帰による典型的なマージがどのように行われるかを正確に調べていないので、それについて権威と話すことはできません。私の理解では、それらがマージ（または分割）された最後のポイントからのdiff3と同等です。その場合、1つの大きなコミットは、多くの小さなコミットよりも効率的ではありません。
タイミングによっては、考慮すべき別の側面があります。ブランチで作業していて、自分のコミット間でアップストリームブランチを定期的にマージしている場合、アップストリームブランチとのパリティが向上し、逸脱が少なくなるため、多くの小さなコミットで競合が少なくなります。これにより、マージバックするときに問題が発生する可能性が低くなります。
どちらの場合も、どちらの方法にも固有のぶら下がっているコミットや緩いオブジェクトがないため、ガベージコレクションはほとんど影響を受けません。
ただし、全体として、パックファイルは通常、テキストを処理するときに十分に効率的であるため、完全で混じりけのない履歴を表示できるという利点は、多くの場合、余分なスペースのコストを上回ります。