ここ StackOverflow には別のスレッドがあり、ソース管理への変更をコミットする頻度を扱っています。これを、git や mercurial などの DVCS を使用するコンテキストに入れたいと思います。
どのくらいの頻度で、いつコミットしますか?
正しくビルドされた場合にのみ変更をコミットしますか?
変更をプッシュする (またはプル リクエストなどを提出する) 頻度と時期は?
複雑な機能を開発したり、多くの場所に手を加える必要がある複雑なリファクタリングを行ったりするには、どのようにアプローチしますか? ビルドしない「プライベートコミット」は大丈夫ですか? 完了したら、それらをマスター リポジトリにもプッシュしますか、それとも、プッシュする前にすべての変更を 1 つの変更セットにバンドルしますか?
それはあなたが取り組んでいるブランチ（「開発ライン」）の性質に依存します。
これらのDVCS（gitまたはmercurial）の主な利点は、次のことができることです。
それで：
1 /どのくらいの頻度でいつコミットしますか？
2 /変更が正しくビルドされた場合にのみ変更をコミットしますか？
プライベートブランチで必要な回数（たとえば、コンパイルする場合）。
単体テストに合格した場合にのみコミットする方法は適切ですが、「公式」（「公開または「プッシュ」可能」など）ブランチにのみ適用する必要があります。プライベートブランチでは、次の場合にガジロン時間をマージします。する必要があります。
唯一のことは、いくつかのテストに合格できるメインの開発ブランチでそれらを再生する前に、いくつかのマージ--interactiveを実行して、プライベートブランチで多くのコミットを再編成することです。
3 /変更をプッシュする（またはプルリクエストなどを提出する）頻度と時期は？
公開は別の問題であり、「明確な」履歴（コヒーレントなマージ、コンパイルしていくつかのテストに合格するコンテンツを表す）を使用して実行する必要があります。
公開するブランチは、履歴が決して書き換えられず、常に更新されるブランチである必要があります。
出版物のペースは、遠隔地の支部の性質とその支部を引っ張っている人口の性質によって異なります。たとえば、別のチームの場合は、かなり頻繁にプッシュできます。システム全体の統合テストチームの場合は、プッシュする頻度が大幅に少なくなります。
4 /複雑な機能の開発/多くの場所に触れる必要のある複雑なリファクタリングの実行にどのようにアプローチしますか？ビルドされない「プライベートコミット」は問題ありませんか？終了したら、それらをマスターリポジトリにもプッシュしますか、それともプッシュする前にすべての変更を1つのチェンジセットにバンドルしますか？
1.および2を参照してください。最初に独自のプライベートブランチでパッチを適用してから、公式の（公開された）パッチブランチでコミットを再編成します。パッチに複数の異なる「アクティビティ」（またはバグ修正）が含まれている場合、1つのコミットが常に最良のオプションであるとは限りません。
私は自分の DVCS (自分のトピックまたはタスク ブランチ) に変更を非常に頻繁にコミットしていました。このようにして、「変更を配信する」ためだけでなく、作業中に私を助けるためにも使用できます。数分前で、もう機能していませんか?」頻繁にコミットする場合は、単に差分を実行できます。
また、私が非常に優れていると感じたテクニックは、「自己文書化リファクタリング」に使用することです。説明させてください: トピック ブランチで大きなリファクタリングを行い、変更全体を確認する必要がある場合 (適切なファイル セットを変更した後)、おそらく道に迷ってしまうでしょう。しかし、すべての「中間ステップ」をチェックインし、コメントを付けて文書化すると、自分が行ったことを説明するのに役立つ、独自の変更のある種の「ムービー」を作成することになります! レビュアーにとっては巨大です。
私はたくさんコミットします。関数を追加したり、ソースを再フォーマットしたりするとき。
私はgitを使用しており、ほとんどの作業は非共有ブランチで行っています。そして、ブロックとしてカウントされる十分な小さな変更を追加したら、git rebase関連する小さな変更を大きなチャンクに収集し、それをメインブランチにコミットするために使用します。
このように、コミットされたコードのすべての利点があり、前後に移動できますが、すべての間違いをコミットする必要はなく、メインの履歴に戻ることができます。
どのくらいの頻度で、いつコミットしますか?
非常に頻繁に。私が行った変更が機能し、適切なパッチが作成された場合は、1 時間に数回かかる可能性があります。または、デバッグに長い時間を費やしているか、危険な変更を試しているかによって、数時間ごとになる可能性があります。
正しくビルドされた場合にのみ変更をコミットしますか?
はい、ほとんどの場合。正しくビルドされなかったコードをチェックインする正当な理由が思いつきません。ただし、(ブランチで) 正しく実行されないコードをチェックインする理由はたくさんあります。
変更をプッシュする (またはプル リクエストなどを提出する) 頻度と時期は?
通常、機能が完成し、統合テストの準備が整った場合のみ。これは、単体テストおよびその他の関連テストに合格したことを意味し、コード/パッチは十分にクリーンであり、レビューの準備ができていると考えています.
複雑な機能を開発したり、多くの場所に手を加える必要がある複雑なリファクタリングを行ったりするには、どのようにアプローチしますか? ビルドしない「プライベートコミット」は大丈夫ですか? 完了したら、それらをマスター リポジトリにもプッシュしますか、それとも、プッシュする前にすべての変更を 1 つの変更セットにバンドルしますか?
その機能用の名前付きブランチを作成します (設計ドキュメントと問題追跡システム全体の追跡可能性があります)。ビルドされないコミットは、中間ステップとしてプライベート ブランチでのみ問題ありませんが、それでも例外的です。現在、機能ブランチ全体を 1 つの変更セットにリベースおよびマージすることはしていませんが、将来的にはそうするつもりです。変更は、適切なテストがすべて合格した場合にのみプッシュされます。
私はこの種のフロー
代替テキストに従いますhttp://img121.imageshack.us/img121/3272/versioncontrolsysbestpr.png
私はこれがかなりすべてを言っていると思います。基本的に、完全に機能するユースケース/ユーザーストーリーを実装した後にチェックインを行います（ソフトウェアプロセスによって異なります）。最も重要なことは、コンパイルするという意味で機能するものをチェックインすることです。ビルドを壊さないでください！
各ユーザーストーリー/ユースケースの後にコミットを実行すると、過去のバージョンをより適切に追跡でき、変更を元に戻すのがはるかに簡単になるという利点があります。
