どのくらいの頻度でコミットする必要がありますか？
私は最近（昨日現在）大卒で、コンピュータサイエンスの学士号を取得しています。自分が取り組んでいる課題に夢中になって、ゼロから始めたばかりで、数時間分の実際の良い作業を一掃して以来、バージョン管理の大ファンでした。おっと！
それ以来、私はBazaarとGit（およびソフトウェアエンジニアリングクラスの場合はSVN）を使用してきましたが、ほとんどすべてのプロジェクトでバージョン管理を行うためにGitを使用しています。通常、私はコミットの頻度にかなり忠実ですが、新しいコミットを書く前にしばらく（いくつかの関数など）行くことがあります。
だからあなたへの私の質問は、どれくらいの頻度でコミットするべきですか？厳格な規則はないはずですが、どのようなガイドラインに従っていますか（試してください）。
機能するものがある場合（つまり、他の誰にとっても何も壊さないこと）、チェックインを行います。私は最初にスタッフテストのほとんどを記述します。つまり、新しいテストに合格するたびにチェックインします。
実際には、1時間に数回という意味です。 1時間に少なくとも数回、5はかなりの数です。
時間ベースではなく、機能ベースでコミットする必要があります。コミットする価値のある新機能を追加したら、必ずコミットしてください。作業方法を追加しましたか？コミット。タイプミスを修正しましたか？コミット。間違ったインデントを修正しましたか？コミット。コミットが適切であれば、小さな変更をコミットすることに問題はありません。
何が問題なのかは、相互に関係がない状態で膨大な数の変更をコミットすることです。特定の回帰のコミットソースを検出することは非常に困難になります。
変更されたコードの量によっては、1時間に20回コミットすることもあれば、1日1回コミットすることもあります。
小さなコミットを行うと、git-bisectなどの非常に強力なツールを使用できます。
コミッターのルールn°1を忘れないでください。決してトランクを壊さないでください。トランクを壊す可能性が高い複数のコミットを行う必要がある場合は、代わりにブランチを作成します。
それは、開発環境が何であるかに少し依存します。
コードベースに貢献しているのがあなただけの場合、遅延コミットはそれほど重要ではありません。ただし、複数の開発者のチームで、全員が「まあ、少しコミットを待つ」と思っていると、多くの場合、多くの競合を処理して多くの時間を失うことになります。
一般的なルール（両方のシナリオ）は次のようになります。できるだけ頻繁にコミットします。 「まだ準備ができていない」と思われる場合は（ビルドが壊れるか、まだ完了していないため）、ブランチを作成してそのブランチにコミットしますが、必ずコミットしてください。
少なくとも1日に1回は、休憩を取るたびにコミットする傾向があるため、通常は3〜4回です。私は自分で作業しているので、他の人をめちゃくちゃにする心配はありません。間違ったパスを下ったと思った場合は、いつでもファイルを元に戻すことができます。
定期的にコミットを行っていなかったときに一度は悪い経験をしていて、ハードドライブがクラッシュして数時間の作業を失いました。私のリポジトリは別のマシンにあり、定期的にバックアップされているため、何かを失ったはずがありません。
Gitブランチとその管理方法のおかげで、私はよくコミットします。あなたが重要だと感じ、後で何かを構築することにつながる可能性のある何かを追加するときはいつでも、コミットする必要があります。
また、新しいコードの前にリファクタリングを行い、新しいテストを追加することがよくあるので、この場合、テストを実行するたびにコミットし、失敗するのを観察して、再度パスしてリファクタリングします。
また、バグの修正後は、それがどれほど小さいか重要でないように見えても、.
私は時々、「コンパイルしたらすぐにコミットする」という道もたどります。
DVCSでは、元に戻せない場合に本当に煩わしい変更を開始するとき、他の人と共有する必要があるとき、またはその時点から変更した内容を確認することが本当に役立つときは、基本的にコミットします。これは、1時間に数回から1日に数回の範囲です。また、ビルドが少なくともsegfaultなしでコンパイルおよび実行されない場合にコミットすることはほとんどありませんが、特定のバグの修正だけを分離して共有したい場合にも役立ちます。
ジョブで使用する必要がある可能性が非常に高い集中型のバージョン管理に注意してください。そうすることで怒っている電子メールが大量に発生しないことを確信できるまで、通常はコミットしません。行っている変更の独立性と、会社が継続的インテグレーションの教義にどの程度同意しているかに応じて、1日1回から、おそらく1か月に1回という大きな新機能に沿ったものになります。
この周波数の違いが、会社の公式集中型VCSに加えてgitを使用する主な理由の1つです。
ビルドサーバーを使用してチーム環境で作業している場合、ビルドするものがある場合にのみコミットする必要があります。それ以外の場合は、チームの他のメンバーにとって非常に迷惑です:)
これを見て Joel On Software-FogBugz/Kiln プレゼンテーションを最近見て、質問によく関連していると思います。
一部のバージョン管理では、分散型VCSでは「コミット」は「公開」（または「他人に苦痛を与える」）と同義ですが、それらはしばしば分離されています。
したがって、いつコミットするかは、使用するVCSによって異なる場合があります。
ビルドが成功するたびに自動的にコミットします。
以前のバージョンに戻したい場合で、戻したいポイントのおおよその実時間を覚えている場合は、そのリビジョンを調べればよいと思います。
もちろん、TDDを使用する場合は、より優れた統合ソリューションがあります。
毎晩家に帰ると、すべてのブランチを自動的に通過してコミットするスクリプトがあります（すべての開発者がこれらの変更を取得しないことに注意してください。これは私の個人的なブランチです）。このように私はそれについて考える必要はありません。
また、朝に自動的に更新を実行するスクリプトもあります。私はこれを使用して、夜にラップトップで作業する場合、変更が朝に自動的にそこにあるようにします。
日中に行った変更のロールバックについては、エディターにはすべての変更の履歴があり、すべての保存/コンパイルでコミットを実行するよりもはるかに高速です。
私は一人で働いています。私の開発環境はノートブックです。コミット環境はWeb上のサーバーです。
クライアントがWebサーバーを使用して進行状況を追跡する場合。だから、ほぼ毎日、何が新しいのかをメールでアップロードしながらアップロードしています。
コミット環境が本番環境である場合、コミット前にテストされるすべての変更についてより注意する必要があります。しかし、それでも、新しい機能が計画されているのか、それとも既に完了しているのか誰も疑わないので、しばしばより良いように見えます。彼らはできるだけ早く求めるものを手に入れます。