プロジェクトで作業する場合、コードは1日でかなり高速に開発される場合もあれば、数週間/月/年の長期にわたって少しずつ開発される場合もあります。コードコミットはプロジェクト開発の指標と見なされるようになっているため、コミットが少ないプロジェクトよりも多くのコードが記述されているという意味ではありません。
では、問題は、いつコミットを正当化できるようにリポジトリに実際にコミットするかです。
アドオンとして：コミットに基づいてプロジェクトの開発を測定することは正しい習慣ですか？
回答:
覚えておきたいコードベース状態に達したらコミットします。特定のコードベースの状態を覚えておきたい理由はたくさんあります。そのため、いつコミットするかについての厳格なルールはありません。ただし、コミット数は間違いなく品質や進行状況の指標ではありません。
この文脈では、コーディングをロッククライミングと考えるのが好きです。少し登ってから、岩にアンカーを置きます。万が一落下した場合、最後に植えたアンカーはあなたを固定するポイントなので、数メートル以上落下することはありません。ソース管理と同じ。少しコーディングし、ある程度安定した位置に到達したら、リビジョンをコミットします。ひどく失敗した場合でも、いつでもその最後のリビジョンに戻ることができ、安定していることがわかります。
とは言っても、チームで作業する場合、コミットするものはすべて完了し、理にかなっており、クリーンにビルドし、他の人のものを壊さないことを確認するのが一般的です。他の人の作業を妨げる可能性のある大きな変更を加える必要がある場合は、他の人を邪魔することなくコミットできるようにブランチを作成します。
また、使用しているSCMシステムによっても異なります。分散システムは通常、マージとフォークを簡単かつ迅速に行い、ローカルでコミットできます。これは、多くのコミットを行い、かなりの量の作業を行ったらプッシュ/マージする必要があることを意味します。svnやcvsなどの集中型システムでは、コミットのコストが高くなり、すべての人に影響します。分岐はこの問題を部分的に解決しますが、サーバーで発生するため、非常に遅くなる可能性があり、マージは面倒です。そのため、集中型SCMでは、多くの場合、かなりの量の作業を行った後にコミットするだけの、より慎重な文化があります。
アドオンについて：どうか、しないでください。コードの行、コミットの数、発見/解決されたバグの数などはすべて、品質または量の非常に悪い測定です。
git rebase -i）。
MercurialやGitなどのDVCSを使用している場合は、かなりの量の作業を行ったときにローカルリポジトリにコミットする必要があります。ただし、テストされた自己完結型の変更が機能してからのみ、共有リポジトリにプッシュしてください。
非分散型VCS（SVNなど）の場合、同じロジックが適用されます。ローカルリポジトリの代わりに、プッシュの代わりにプライベートブランチを使用して、メインブランチにマージします。
早く、頻繁にコミットする必要があります。
90秒ごとにコミットする人を知っています。真剣に。彼らのために働くようです。ファイルを保存するたびにコミットしてみましたが、おそらく90秒よりも頻繁です。今日、私はおそらく15分ごとにコミットします。複数のコミットを1つにまとめることができ、ローカルコミット（gitなど）を許可するVCSにより、これが非常に簡単になります。
どのくらいの頻度でコミットする必要がありますか？言うのは難しいですが、おそらくあなたよりも頻繁になります。ますます頻繁にコミットを続け、それがあまりにも頻繁にあるように感じられるポイントを見つけてから、少し離れてください。合理的なものになってしまう可能性があります。
ユーザーに提供される価値に基づいて製品の開発を測定します。他の正確な測定値はありません。
コミットは、バージョン管理されたデータ/コードの構成要素です。各コミットは、次のいずれかを正確に実行する必要があります。
また、ブランチで作業する場合は、より適切なブランチにコミットする必要があります。2つのコミットは、同じコミットメッセージ（同様の変更を意味する）を持たず、共同作業者を混乱させるため、異なるブランチにする必要があります。より良い方法は、メインブランチにコミットし、機能ブランチにマージすることです。
コミッターが上記の規則に従うと、次のことが簡単になります。
コミットに基づいてプロジェクトの進捗を測定することに関して、コミットのリファクタリングとバグ修正のコミットが考慮されていない場合は可能です。
特定の機能/モジュール/機能の単体テストが正常に完了し、統合またはシステムテストの準備ができていることが合理的に保証されている場合にのみコミットしてください。
そして、アドオンの質問に答えるために-いいえ!! プロジェクトがどこにあるかの尺度は、コミットの数によって決定されるべきではありません...実際にコミットされたものを誰が知っていますか？システムテストやユニットテストに成功しましたか。コミットされているからといって、それが生産準備が整っているという意味ではありません。
アドオンとして：コミットに基づいてプロジェクトの開発を測定することは正しい習慣ですか？
いいえ。なぜそれが恐ろしいアイデアであるかについて、毎日のWTFがありました。
コードのコミットに関する一般的な経験則は、コードのチャンクを完了してコンパイルしたときにチェックインすることです。チャンクは実際には定義されていません。小さなタスクの場合、完了するまでチェックインしない場合があります。大きい場合は、各論理部分が完了した後にチェックインする場合があります。
ただし、コンパイルできない場合はチェックインしないでください。実際に大声で言うのは愚かなことのように思えますが、以前に人々に説明しなければなりませんでした。
コードを他のユーザーと共有する準備ができたとき、つまりコードが比較的安定しており、安全で、適切にテストされているときにコミットを行います。
いいえ、コミットはプロジェクトの開発にとって優れた指標ではないと思います。なぜなら、小さな小さな変更をすべてコミットする開発者と、機能に対する大きな大きな変更のみをコミットする開発者を知っているからです。あるコミットの価値を別のコミットよりも定量的にどのように測定しますか？
あなたが何かを壊すとは思わないすべての重要な変更をコミットします。コミットすべきではない唯一のものは、スタイルの変更です。これは、ロジックの変更を具体化しないためです。しかし、そうでなければ、コミットする変更が小さければ小さいほど良いです。
コミットが小さければ小さいほど、思考プロセスをより詳細に文書化できます。これは、優れたコミットログの1つの側面です。適切なコードレビューは、コードの結果だけでなく、思考プロセスについても行う必要があります。
また、小さなコミットを多数行うと、二分するのが簡単になります。これは、バージョン管理の機能の使用が少なすぎるため、haystackコードベースの針のバグを探すのに多くの時間を節約できました。
要するに二分します。現在のコードベースで問題を発見してください。次に、変更ログで特定の問題が存在しないことを確認するコミットを選択します。「良い」バージョンと「悪い」バージョンの中間にあるコミットをチェックアウトすることから始めます。問題がまだ存在するかどうかをテストします。もしそうなら、「良い」と以前にテストされたコミットの途中で、さらに振り返る必要があります。問題がなくなった場合、この特定の変更後に導入されたため、「不良」コミットと以前にテストしたコミットの中間を確認する必要があります。繰り返す。最終的には、問題を引き起こしたコミットになります。しかし、小さなコミットがある場合にのみ、そうでなければ、どの大きな変更の山に問題が存在するようになったかがわかります。
ここでは、それはGitリポジトリで動作しますが、本人が任意のバージョンコントロールに適用する方法です。