本当に大きなソースコードコミットの用語は何ですか？
ソフトウェアのコミット履歴を確認すると、実際に大きなコミットがいくつかあることに気付く場合があります。それらは、何百ものソースコード行（デルタ）が変更された10または20のファイルを変更する場合があります。このようなBIGコミットには一般的に使用される用語があることを覚えていますが、その用語が正確に思い出せません。誰か助けてもらえますか？プログラマーがこのようなBIGや巨大なコミットを指すために通常使用する用語は何ですか？
ところで、多くの変更をまとめてコミットすることは良い習慣ですか？
更新：刺激的な議論をありがとう！しかし、私は「コードボム」が私が探している用語だと思います。
（1） Ben Collins-Sussman ： "..."code bombs "。つまり、何をするか誰かが巨大な新機能を備えたオープンソースプロジェクトに出て、何ヶ月もかけて作成したのですか？何千行ものコードをレビューする時間のある人はいますか？...」
（2） Dan Fabulich ： "コード爆弾、または：大きなアイデアを持つ初心者... Aコード爆弾はパッチが大きすぎて、誰も確認できないほどです。」
（3） Google Summer of Code：ガイドライン ：「早期にコミットし、頻繁にコミットする... 1日中作業せず、すべてを1つにプッシュする code bomb。代わりに、すべてのコミットは、ログメッセージに要約される1つのタスクのみに自己完結する必要があります。
（4） Jeff Atwood ： "code-bombs ... Rule＃30：Do n'tgo dark。. 。
おそらくこれをbad commitと呼びます。 :)
悪い習慣
そして、はい、それは一般的に悪い習慣と見なされます、それは以下の悪影響を持っているためです：
- レビューするのが難しい、
- コミットの元の意図を簡単かつ迅速に把握することを困難にします、
- 問題を明示的に修正または解決するためにコードにどのように影響したかを確認することは困難です、
- それをコミットのサイズが他のおそらく無関係な変更（たとえば、小さなクリーンアップまたは他のタスク）のノイズによるものかどうかを知ることは困難です。
許容できるケース
ただし、大きなコミットが完全に受け入れられる場合があります。例えば：
- ブランチ間でマージするとき、
- バージョン管理されていない別のコードベースから新しいソースを追加する場合、
- 大きな機能をインプレースで置換するとき（ブランチで変更する必要がありますが、変更のさまざまな部分に対応する小さなコミットを使用してからマージします）すべてが戻ってきたので、機能の段階的な開発と、途中で発生した可能性のある問題について、より良いウィンドウを持つことができます）、
- aPIをリファクタリングするとき、多くの子孫クラスとコンシューマクラスに影響を与えます。
したがって、可能な限り、「外科的ストライク」タイプのコミットを優先してください（そして、それらを課題追跡のタスクIDにリンクしてください！）。正当な理由がある場合は、先に進んでください。
それとは別に、私は実際に知りませんし、大規模なコミットの特別な名前を聞いたこともないと思います。モンスターコミット？ファットコミット？
更新：David Cary's 用語を使用して著名なIT俳優へのリンクに回答します "コード-爆弾 "（最も重要なのは、 Subversion の最初の作成者であるコリンズサスマン）。そうです（今のところ、頻繁に聞いたとは言えませんが）。
ところで、多くの変更をまとめてコミットすることは良い習慣ですか？
ええと、変更を長期間保持し、さまざまな機能とバグ修正を実装してからコミットすることはお勧めできません。これは大きなコミットが発生する可能性がある1つの方法です。
これが発生する可能性のあるもう1つの方法は、リファクタリングが広く使用されている関数のシグネチャを変更した場合、それらすべてを変更する必要がある場合です。これは必要に応じて悪くはありません。また、しきい値を超えないようにするために、開発者がコードをクリーンアップするのを控えたくありません。
つまり、コミットで変更されたファイルの数を確認するだけではありません。
私が聞いた用語は"分厚いチェックイン"です。そして、私はそれらのファンではありません。私はプロジェクトの妥当なステップで他に何も壊れないことを保証する小さなコミットが好きです。大きなコミットには、通常、それが発生したときからしばらくの間反響する問題が伴います。
私はそれを"typical SVN commit"または"tomorrow is release day commit"と呼びます
私はSVNが大好きですが、ローカルコミットを実行できないという事実に気を取られています。
編集：彼らは通常、コミットメッセージに「もの」と「ビール」という言葉を持っています。
再度編集：多くの変更をコミットすることは、必ずしも悪い習慣ではありませんが、できるだけ回避する必要があります。短く簡潔なリビジョン/コミットをレビューする方が簡単だと思います。 （よく書かれたコミットメッセージとペアになっています、悪い例については私の以前の編集を参照してください）
「コードのホットスチーム」。 :-)
- initial commit-リビジョン管理されていないプロジェクトがSVNにスローされました
- refactoring-アーキテクトはクラス名を/から変更することについて素晴らしいアイデアを持っています スマーフ命名規則 またはパッケージ階層のルートを変更しました
- コード形式-アーキテクトはコードインデントを4から3スペースに変更するか、行末をUnixからWindowsに変更する（または元に戻す）ことを決定しました
- Friday commit-Joeは毎週金曜日の16:30に1週間の作業をコミットしています
- uuups commit-Tedが誤ってルートディレクトリを削除し、それをコミットしました。今度は、ファイル階層全体をもう一度SVNにポンプします。
通常、多くの人々は集中型VCSを使用して大きなコミットを行う傾向があり、特にサーバーは適切なコミットポリシーを適用します。つまり、コミットはすべてのテストに合格する必要があり、テストには長い時間がかかります（数秒以上）。したがって、開発者は複数回コミットして変更を複数の小さなコミットに分解するのにそれほど長く待ちたくないのです。
また、VCSに環境に配慮した開発者は、変更を複数の小さなコミットに分解することを忘れることがあります。彼らはプログラムをQAチームにリリースするときにのみコミットすることを覚えています。さらに悪いことに、バグのあるコードを他の人に見られないようにするために、QAテストに合格するまではコミットしません。最後に、実際に「大きな」コミットを生成する出力バイナリ、一時ファイル、およびリンカー出力をコミットしたことを認識していませんでした。