時々、ソフトウェアのコミット履歴を確認すると、実際には大きなコミットがいくつかあることがわかります。数百のソースコード行（デルタ）が変更された10または20のファイルが変更される場合があります。このようなBIGコミットには一般的に使用される用語がありますが、その用語が何であるかを正確に思い出すことはできません。誰も私を助けることができますか？プログラマーがこのようなBIGと巨大なコミットを指すために通常使用する用語は何ですか？

ところで、たくさんの変更をまとめてコミットするのは良い習慣ですか？

更新：感動的な議論をありがとう！しかし、「コードボム」は私が探している用語だと思います。

（1）Ben Collins-Sussman： "..." code bombs "。つまり、誰かが書くのに数か月かかった巨大な新機能を備えたオープンソースプロジェクトに現れたら、あなたはどうしますか？数千行のコード？...」

（2）Dan Fabulich：「コード爆弾、または：ビッグアイデアを持つ初心者... コード爆弾は、誰もレビューできないほど大きいパッチです。」

（3）Google Summer of Code：ガイドライン：「早期にコミットし、頻繁にコミットする...終日作業せずに、すべてを1つのコード爆弾で押し出してください。代わりに、すべてのコミットは1つのタスクのみに含まれますログメッセージに要約する必要があります。」

（4）ジェフ・アトウッド：「コード爆弾...ルール＃30：暗くなるな ...」

おそらくそれを悪いコミットと呼ぶでしょう。:)

悪い練習

そして、はい、それは一般的に悪い習慣とみなされます：

• 確認するのが難しくなる、
• コミットの元の意図を簡単かつ迅速に把握することを困難にします。
• それは作りにくいそれが明示的に問題を修正または対処するためのコードに影響を与えたかを確認するために、
• コミットのサイズが、おそらく関係のない他の変更のノイズによるものかどうか（たとえば、小さなクリーンアップや他のタスク）によるものかどうかを知ることを困難にします。

許容されるケース

ただし、大規模なコミットが完全に受け入れられる場合があります。例えば：

• ブランチ間でマージする場合、
• バージョン管理されていない別のコードベースから新しいソースを追加する場合、
• 大きな機能をインプレースで置き換える場合（ただし、ブランチでそれを行い、変更のさまざまな部分に対応する小さなコミットを行い、全体をマージして戻すことにより、機能と途中で発生した可能性のある問題）、
• 多くの子孫およびコンシューマクラスに影響するAPIをリファクタリングするとき。

そのため、可能な限り、「外科的ストライク」タイプのコミットを優先します（そして、それらを課題追跡のタスクIDにリンクします！）。正当な理由がある場合は、先に進んでください。

それとは別に、私は実際には知らないし、大規模なコミットの特別な名前を聞いたこともないと思います。モンスターコミット？ファットコミット？

更新： David Caryの回答は、「コード爆弾」という用語を使用して有名なIT関係者にリンクしています（最も重要なのは、Subversionの元の作成者であるCollins-Sussman ）。そのように（これまでのところ、頻繁に聞いたとは言えませんが）。

ところで、たくさんの変更をまとめてコミットするのは良い習慣ですか？

まあ、長い間変更を保持し、さまざまな機能とバグ修正を実装してからコミットするのは良い習慣ではありません。これは大きなコミットが起こる可能性のある方法の1つです。

これが発生する可能性のある別の方法は、リファクタリングが広く使用されている関数のシグネチャを変更し、それらすべてを変更する必要がある場合です。これは必ずしも悪いことではなく、開発者が何らかのしきい値を超えることを恐れてコードをクリーンアップすることを控えたくありません。

そのため、コミットで触れられたファイルの数を見るだけではありません。

私が聞いた用語は「分厚いチェックイン」です。そして、私は彼らのファンではありません。私は、プロジェクトの合理的なステップで他に何も壊れないようにする小さなコミットが好きです。通常、大きなコミットには、それが発生したときからしばらくの間反響する問題がたくさんあります。

「典型的なSVNコミット」または「明日はリリース日コミット」と呼びます

SVNが大好きなのと同じように、ローカルコミットを実行できないという事実によって、私はオフになっています。

編集：通常、コミットメッセージに「スタッフ」と「ビール」という言葉があります。

もう一度編集：多くの変更をコミットすることは、必ずしも悪い習慣ではありませんが、可能な限り避けるべきです。短く簡潔なリビジョン/コミットを確認する方が簡単だと思います。（よく書かれたコミットメッセージとペアになっています。悪い例については以前の編集を参照してください）

「ホットスチーミングコードの塊」。:-)

• 初期コミット -SVNにスローされたリビジョン管理下になかったプロジェクト
• リファクタリング -アーキテクトは、クラス名をSmurf Naming Conventionとの間で変更したり、パッケージ階層のルートを変更したりするという素晴らしいアイデアを持っています。
• コード形式 -アーキテクトは、コードのインデントを4スペースから3スペースに変更するか、行末をUnixからWindowsに変更する（または元に戻す）ことを決定しました
• 金曜日のコミット -ジョーは常に金曜日の16:30に1週間の仕事をコミットしています
• uuups commit -Tedは誤ってルートディレクトリを削除し、それをコミットしました。そして今、彼は再びファイル階層全体をSVNに送り込みます。

通常、多くの人々は集中型VCSを使用して大きなコミットを行う傾向があり、特にサーバーは適切なコミットポリシーを実施します。つまり、コミットはすべてのテストに合格する必要があり、テストには時間がかかります（数秒より長くなります）。したがって、開発者は、何度もコミットして変更を複数の小さなコミットに分解するのにそれほど長く待つことを望みません。

また、VCSに環境に優しい開発者は、変更を複数の小さなコミットに分解するのを忘れることがあります。彼らはプログラムをQAチームにリリースするときにのみコミットすることを覚えています。さらに悪いことに、他の人がバグのあるコードを見るのを避けるために、QAテストに合格するまでコミットしません。最後に、彼らは実際に「大きな」コミットを生成する出力バイナリ、一時ファイル、およびリンカー出力をコミットしたことを認識していませんでした。