回答:
サイズは重要ではありませんが、コミットはできるだけアトミックである必要があります。つまり、コミットによってビルドが中断されてはならず、特定のバグが1つ修正されるか、特定の機能が1つ追加され、他のコミットから独立している必要があります。機能に多くのコードが必要な場合は、そうする必要があります。しかし、通常、この戦略は小さな頻繁なコミットを自然に生成します。
制限はありますが、私は小さなアトミックなコミットを好みます。
まず、変更が加えられた理由を参照すると、作業が簡単になります。第二に、ミスを犯すコストを大幅に削減します。
ただし、次の2つの注意点があります。
集中型VCSを使用している場合は、コードのビルドとテストの実行時にのみコミットしてください。(DVCSを使用している場合は、「commit」を「push」に置き換えます。)
あるコミットコメントを別のコメントから暗黙的に参照しないでください。
351: pdr: Stop foo from grommiting.
352: pdr: Ooops, got that wrong, let's try again.
353: dan: New launch page.
354: pdr: Third time lucky.
そういうこと。しないでください。5分前に行ったコミットを覚えていて、コメントは自分との会話のように感じ始めるため、頻繁にコミットしていると非常に魅力的です。しかし、あなた自身を制御してください。与えられたファイルの最後のコミットを検索する、2年後の貧しい人には意味がありません。