バージョン管理のコミットが大きすぎるのはいつですか？[閉まっている]

「大規模なコミットをしないでください」と聞いたことがありますが、「大規模な」コミットとは何かを実際に理解したことがありません。関連していても大量のファイルを扱う場合、それは大きいですか？プロジェクトのどの部分を一度に作業する必要がありますか？

私にとって、他の何かを作成する何かを作成することを忘れたり作成したりするため、「小さなコミット」をしようとするのに苦労しています。その後、次のようなものになります。

カスタム発信キューを作成しました

ボット
-SingleThreadExecutorにすぎない新しいフィールドmsgQueue
-sendMsgは、メッセージが送信されるまでブロックし、メッセージが取得されるまで待機します
送った
-adminExist呼び出しが更新されました（コントローラーを参照）
-sendMessageの呼び出しを削除

コントローラ
-新しいフィールドmsgWaitは、メッセージ間の待機時間を示します
-サービスプラグインの開始はreloadPluginsに移動しました
-adminExistsは、グローバル管理者のためにサーバーから移動しました。チャンネルで確認し、
サーバー、およびグローバルレベル

管理者
-適切なオブジェクトAdminを取得する新しいメソッドgetServerおよびgetChannel
属する

BotEvent
-toString（）もextraとextra1を表示します

チャネル
-nameに名前が変更されたチャネルフィールド
-channel（int）のタイプミスを修正

サーバ
-管理者をコントローラーに移動しました

PluginExecutor
-マイナーテストが追加され、後で削除されます

JSプラグイン
-フレームワークの変更を更新
-InstanceTracker.getController（）をController.instanceに置き換え
-VLCトークは独自のファイルで

さまざまなNBプロジェクトの更新と変更

---

影響を受けるファイル
/trunk/Quackbot-Core/dist/Quackbot-Core.jarを変更します
/trunk/Quackbot-Core/dist/README.TXTを変更します
/trunk/Quackbot-Core/nbproject/private/private.propertiesを変更します
/trunk/Quackbot-Core/nbproject/private/private.xmlを変更します
/trunk/Quackbot-Core/src/Quackbot/Bot.javaを変更します
/trunk/Quackbot-Core/src/Quackbot/Controller.javaを変更します
/trunk/Quackbot-Core/src/Quackbot/PluginExecutor.javaを変更します
/trunk/Quackbot-Core/src/Quackbot/info/Admin.javaを変更します
/trunk/Quackbot-Core/src/Quackbot/info/BotEvent.javaを変更します
/trunk/Quackbot-Core/src/Quackbot/info/Channel.javaを変更します
/trunk/Quackbot-Core/src/Quackbot/info/Server.javaを変更します
/trunk/Quackbot-GUI/dist/Quackbot-GUI.jarを変更します
/trunk/Quackbot-GUI/dist/README.TXTを変更します
/trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jarを変更します
/trunk/Quackbot-GUI/nbproject/private/private.propertiesを変更します
/trunk/Quackbot-GUI/nbproject/private/private.xmlを変更します
/trunk/Quackbot-GUI/src/Quackbot/GUI.javaを変更します
/trunk/Quackbot-GUI/src/Quackbot/log/ControlAppender.javaを変更します
/trunk/Quackbot-GUI/src/Quackbot/log/WriteOutput.javaを削除します
/trunk/Quackbot-Impl/dist/Quackbot-Impl.jarを変更します
/trunk/Quackbot-Impl/dist/README.TXTを変更します
/trunk/Quackbot-Impl/dist/lib/Quackbot-Core.jarを変更します
/trunk/Quackbot-Impl/dist/lib/Quackbot-GUI.jarを変更します
/trunk/Quackbot-Impl/dist/lib/Quackbot-Plugins.jarを変更します
/trunk/Quackbot-Impl/lib/javarebel.statsを変更します
/trunk/Quackbot-Impl/lib/jrebel.infoを追加します
/trunk/Quackbot-Impl/nbproject/private/private.propertiesを変更します
/trunk/Quackbot-Impl/nbproject/private/private.xmlを変更します
/trunk/Quackbot-Impl/nbproject/project.propertiesを変更します
/trunk/Quackbot-Impl/plugins/CMDs/Admin/reload.jsを変更します
/ trunk / Quackbot-Impl / plugins / CMDs / Operator / hostBanを追加します
/trunk/Quackbot-Impl/plugins/CMDs/Operator/mute.jsを変更します
/trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/curPlaying.jsを変更します
/trunk/Quackbot-Impl/plugins/CMDs/lyokofreak/lfautomode.jsを変更します
/trunk/Quackbot-Impl/plugins/listeners/onJoin.jsを変更します
/trunk/Quackbot-Impl/plugins/listeners/onQuit.jsを変更します
/trunk/Quackbot-Impl/plugins/testCase.jsを変更します
/trunk/Quackbot-Impl/plugins/utils/whatsPlaying.jsを追加します
/trunk/Quackbot-Impl/src/Quackbot/impl/SandBox.javaを変更します
/ trunk / Quackbot-Impl / vlc_httpを追加します
/trunk/Quackbot-Impl/vlc_http/current.htmlを追加します
/trunk/Quackbot-Plugins/dist/Quackbot-Plugins.jarを変更します
/trunk/Quackbot-Plugins/dist/README.TXTを変更します
/trunk/Quackbot-Plugins/dist/lib/Quackbot-Core.jarを変更します
/trunk/Quackbot-Plugins/nbproject/private/private.propertiesを変更します
/trunk/Quackbot-Plugins/nbproject/private/private.xmlを変更します
/trunk/Quackbot-Plugins/src/Quackbot/plugins/JSPlugin.javaを変更します
/ trunk / Quackbot-Plugins / vlc_httpを追加します
/trunk/global-lib/jrebel.jarを追加します

うん...。

質問の場合：

• コミットが大きくなりすぎる場合（非自明なもの）の要因は何ですか？
• そのようなコミットをどのように防ぐことができますか？詳細を教えてください
• 物事が急速に動いているときに、開発の半初期段階にいるときはどうですか？巨大なコミットはまだ大丈夫ですか？

私にとって、他の何かを作成する何かを作成することを忘れたり作成したりするため、「小さなコミット」をしようとするのに苦労しています。

それは問題です。作業をより小さく、より管理しやすい塊に分解することを学ぶ必要があるようです。

大規模なコミットの問題は次のとおりです。

• 複数の人が参加するプロジェクトでは、コミットが他の開発者の競合を解決する可能性が高くなります。
• ログメッセージで行われたことを正確に記述することは困難です。
• 変更が行われた順序を追跡することは難しく、したがって問題の原因を理解することは困難です。
• コミットされていない多くの作業を失う可能性が高くなります。

大規模なコミットが避けられない場合があります。たとえば、主要なAPIを変更する必要がある場合。しかし、通常はそうではありません。そして、このような状況に陥った場合は、ブランチを作成してそこで作業を行うことをお勧めします。多くの小さなコミットを行い、終了したら再統合します。

（別のケースは、最初のインポートを行う場合ですが、上記の問題の観点からは問題ありません。）

単一責任の原則。

すべてのソース管理のコミットは、1つの目的のみに使用する必要があります。要約に「and」または「also」という単語を含める必要がある場合は、それを分割する必要があります。

作業コピーに関連しない、または半関連の個別の変更が多数発生することは非常に一般的です。これは「絡み合った作業コピーの問題」と呼ばれ、規律のある開発者であっても回避するのは実際には非常に困難です。ただし、GitとMercurialは両方とも、それを解決するツールを提供します-git add -pまたはチャンク選択とTortoiseHgのMercurialキュー。

クライアントが特定の変更を行うように要求したことを想像してください。たとえば、「何でも」の日付から2日以内に何かを行うことができないというルールを追加する場合です。そして、あなたが変更を加えた後、彼らは心を変えます。コミットをロールバックする必要があります。無関係なレポートの並べ替え順序を変更することに関して、すべてが押しつぶされている場合、あなたの人生は悲惨です。

1つの作業項目、1つの変更セット。クライアントからの1つのリクエスト、1つのチェンジセット。あなたが気が変わるかもしれない一つのこと、一つのチェンジセット。場合によっては、1行のコードであることを意味します。データベーススキーマを含む10個の異なるファイルである場合があります。それはいいです。

大規模なコミットとは、実際にはすべてが同じバケットに収まらない大量の変更がある場合です。コントローラのロジックを変更してから、データベース接続モデルを変更してから、その他を変更します。スクリプトの場合、1回のコミットですべてをバンドルするべきではありません。

防止とは、完了した内容に応じてコミットを行うことです。上記の例では、コントローラーロジックの後、データベースの作業の後、およびスクリプトの後にコミットします。変更点を知っているという理由だけで、コミットを先送りしないでください。他の人はあなたの「変更されたもの」コミットログメッセージを振り返り、あなたは何を吸っていたのだろうと思うでしょう。

最初のインポートは、おそらくあなたが持つべき最大のコミットです。システムをゼロからセットアップしますか？確かにいくつかの大きなコミットがあります。整理したら、物事を整理します。

事前に大量のコードを処理することがわかっている場合は、特定の機能のブランチを作成し、定期的にメインラインからコードをプルダウンして、コードの同期を維持することをお勧めします。ブランチでの作業が完了したら、すべての変更をメインラインにマージします。このようにして、他のチームメンバーが大きなコミットを目にしたとしても、他のチームメンバーが驚いたり、イライラしたりすることはありません。また、物事を壊す可能性はずっと低くなります。物事を小さなコミットに分解する練習を続けてください。時間が経つにつれて、それは第二の性質になります。

この例は、大きすぎるコミットを示しています。

経験則として、1文または1行のテキストで変更を説明します。（このルールに基づいて、コミットは10から15の小さなものに分割する必要があります。）1行でコミットを適切にコメントできない場合は、すでに大きすぎます。

小規模なコミットを練習するには、メモ帳（またはメモ帳）で既に変更または追加した内容をメモします。長いリストになる前、またはメモ帳に既にあるものとは関係のないコード変更を行う前にコミットします。

私の分野（物理モデリング）で、6か月前のリポジトリにはなかったバグを今日の出力で発見しました。これが発生したら、リビジョンのバイナリ検索を行います。

1. 3か月前からモデルを実行
2. バグがまだ出力されている場合は、4.5か月前からモデルを実行します
3. ...悪い出力をもたらすコミットを見つけるまで繰り返す

バグが巨大なコミットで導入されたとき、問題の原因を見つけるために、細かい歯の櫛で座らなければなりません。コミットが少数のファイルに触れた場合、問題を引き起こしたコードの行を追跡することはそれほど苦痛ではありません。

問題を一連の小さなタスクに分割することをお勧めします（理想的には、各タスクをバグトラッカーに入れます）。各タスクを完了したらコミットを行います（そして、バグトラッカーでそのバグ/機能を閉じます）。

本当に重要なのはコミットのサイズではなく、コミットの編成方法を決定するのは変更の範囲です。

たとえば、200個のファイルを変更する大規模なコードベースでのすべてのインスタンスを__macro1に__macro2変更できます。その場合、200件のコミットメントは正気ではありません。

最終的に望むのは、任意の単一リビジョンでリポジトリをプルできることと、ビルドが機能することです。からlibfooに変更しましたlibbarか？変更には、ビルドスクリプトとMakefile（または該当するもの）の更新も含まれることを望みます。

場合によっては、1つのことを達成する一連の実験的な変更が必要になることがあります。その場合、後で元に戻す必要がある場合は、どのスコープがより重要かを判断する必要があります。一方が他方に依存していますか？1つのリビジョンで一度にコミットします。それ以外の場合、その場合、変更ごとに1つのコミットをお勧めします。とにかく別のブランチまたは別のレポでそのようなことをする必要があります。

はい、1つのファイルを以前のリビジョンに戻す（つまり、1つのファイルをより大きなコミットメントから戻す）ことができます。そうすることで、後で二分法のようなツールを実際に台無しにして、履歴を汚染します。

停止して「OK、テストに合格しました。これはうまくいくと思いますが、うまくいかない場合は簡単に取り消せますか？」..賢明なコミットメントを行うことになります。

ここで理解すべきことは、このコンテキストでの「大」とは、コミットの物理的なサイズではなく、明確な変更の数に関することです（ただし、一般的には2つが連動します）。

小さなコミットを行うほど「大きなコミットをしない」という問題ではありません。小さな自己完結型の変更をコミットするのが理想です。

変更ログから、個別に（そして安全に）コミットできる一連の事柄があることは明らかであるため、大きすぎることは自明です。

これが問題になる可能性がある理由は、最後のコミットが現在行っている変更の基準点であり、たとえば、最初のビットを正しく取得してから次のビットを間違った場合は簡単な方法ではないためです間違いを起こし始めたところまで作業を戻す（BTDTGTTS）。

もちろん、変更は大きい場合もあります-大規模なリファクタリング-他の人が示唆しているように、これはあなたがブランチする必要がある場所です問題とあなたは、早期かつ頻繁にコミットし続けることができます。

もう1つ-作業中にすぐに注意を要する何かが発生した場合は、個別に（理想的には完全に別個のフォルダーセットで）変更し、個別にコミットする必要があります。

このすべての本当の課題は、その仕組みの仕組みではありません-コミットは、時々あなたが作成する単なるバックアップコピーではなく、各コミットは途中でインチペブルであり、ロットには何の問題もないことです小さなコミットと、mobコミットで異なるものを一緒に変更することは、コードの塊で漠然と関連した機能ビットを一緒に変更することと同じくらい悪いです。

少なくとも、「自分の進歩がこれまでのところ好きであり、これから行う変更が災害である場合、それを失いたくない」と思うときはいつでもコミットするように自分を訓練してください。次に、VCSを活用して、試行した行き止まりを吹き飛ばしたり、問題を追跡するために追加した特別なデバッグコードを選択したりできます。（例：git reset --hardまたはrm -rf *; svn update）

固くて速いルールも、コミットが大きすぎる境界線もありません。

そこで小さなコミットが優れていることをガイドラインは合理的な範囲（すなわち、すべての行をコミットすることはprobaby過剰である）、しかし。

これらの種類のガイドラインを念頭に置いています。

• 単一のコミットには、たった1つのバグ修正のための変更を含める必要があります
• 1回のコミットに半日以上の作業を含めないでください
• 1回のコミットでビルドが中断されることはありません

もちろん-これらは私が心に留めておくものです-YMMV。開発者が異なれば、粒度のレベルも異なります。

コミットが小さいほど、潜在的なリグレッションの原因を正確に見つけやすくなります。

理想的には、コミットはコードベースに対する最小の一貫した変更（バグ、機能などに関連する）の​​意味でアトミックである必要があります。

コミットのサイズを小さく保つための具体的なヒントについては、VCSとそのセットアップ方法に大きく依存します。ローカルでコミットするか、サーバー上の独自のブランチで作業できる必要があります。

重要なのは、アトミックな変更を行うたびに「プライベート」ブランチにコミットすることです。その後、毎週など、定期的にブランチをマージできます。

dvcsを使用すると、ワークフローは次のようになります。

code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
code code code
git commit       // create commit locally with meaningful message
...
git push         // push your previous commits to the team server

集中型vcsを使用する：

svn copy trunk my_feature_branch  // create your private branch
svn co my_private_branch          //
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
code code code
svn commit                        // commit on your private branch with meaningful comment
...
svn merge my_feature_branch trunk  // all your previous commit are merged to main/master branch

あなたはおそらく、完璧はあなたがこれ以上何も奪うことができないときであるという言葉を聞いたことがあるでしょう。また、コミットサイズの標準についても説明する必要があります。

それは、その「完璧な」サイズがどこにあるかによります。外部の顧客に配送する場合、次の配送を期限内に完了しなかった場合に快適な配送が可能な最小の増分となる可能性があります。頻繁にデプロイされる内部アプリケーションを構築している場合、最適なサイズは、何も中断しない最小の増分である可能性があります（そして、目的の場所に近づきます）。

最新のバージョン管理システムは、簡単な分岐、インタラクティブなリベース、ステージング領域などにより、適切なコミットを作成するのに役立ちます。

コミットメッセージは1行のみにする必要があります（gitの場合は最大60文字）。コミットされるコードの量は、説明メッセージをその制限内に収めるのに十分な量でなければなりません。

私は毎回コミットする傾向があります（さらに、今ではgitに切り替えています）。

時には、論理的に異なる複数の異なるシャンパンで終日作業しており、その間にコードをコミットするのを忘れていました。使用すると、git citoolあなたが作業している間、あなたが日中とても慎重でなかった場合でも、一日の終わりに素敵な一口サイズのチャンクにあなたの仕事を壊すために非常に役立ちます。

git citool 特定のコミットでコミットするファイルの特定のハンク（または特定の行）を選択できるため、同じファイルに加えられた（重複しない）変更を複数のコミットに分割できます。

（Subversionを使用しているようです。Subversionでこれを行うツールは知りませんが、git-svnGitのSubversionアダプターを使用して、あなたの人生を変えることができます。）

コミットが大きいほど、ビルドを中断し、チームの他のメンバーから支払いを受ける可能性が高くなります。1日に2回、変更をコミットしてみます。昼食の直前と家に帰る前。したがって、午後12時と午後4時30分に、すべてが正常に機能し、コミットの準備ができるようにします。私はこの練習が私にとってうまくいくと思います。

質問に答えるには：

1）私にとっては、複数のことをしている場合、標準コミットは大きいと考えられます。ことによって、私はバグを修正したり、機能を追加することを意味します。

2）何かを終了するたびにコミットする習慣とルールにすることで、このようなコミットを防止します。

3）開発の半初期段階で、後で使用するファイルの最初の作成をコミットに含めることを許可します。

終了することで、特定できるすべてのバグが修正され、コミットによってビルドが中断されないことを意味します。

はい、これは多数のコミットを生成しますが、1つの変更のみが問題を引き起こしている同時にコミットされた大量の変更をロールバックする代わりに、物事を壊したものを正確にロールバックできます。

また、MercurialやGitなどの分散バージョン管理システム（DVCS）のルールが少し変更されていることも指摘したいと思います。これらのいずれかを使用している場合、変更を加えるたびにコミットしますが、まだテストしていないので、動作中に中央リポジトリにプッシュします。これは、ビルドを壊すことを心配せずにコードの変更をより多く修正できるため、望ましい方法です。

私の場合、サーバーのファイルをリポジトリシステム（SVN）にコミットしようとしています。これは最初のコミットであり、本当に大きなプロジェクト（数GB）であり、クライアントサーバーから最初のコミットを行いたいので、ダウンロードしたくないです。

問題は、クライアントが共有サーバー上にあり、1分以上実行するとsvnクライアント（または他のソフトウェア）が強制終了されることです。

別の方法として、プロジェクトをコンピューターにダウンロードし、そこから最初のコミットを行うこともありますが、SVNにトランザクションの方法に似た大きなコミットをさらに分割するオプションがあるかどうかを知りたいと思っています。

私の前の開発者はバージョン管理システムを使用したことがありませんでした。

私が働いている会社は、コミットごとにピアコードレビューを強制しています。したがって、ピアが合理的な時間内に何が起こっているのかを把握してレビューすることを困難にするコミットは大きすぎます。