毎日コードをコミット/チェックすることは良い習慣ですか？

私は継続的インテグレーションに関するMartin Fowlerのメモを読んでおり、彼は必須項目として「毎日メインラインにコミットしている」としています。

私が取り組んでいるセクションが完全でない限り、コードをコミットするのは好きではありません。実際には、3日ごとにコードをコミットします：1日目はタスクを調査/再現し、いくつかの予備的な変更を行い、2日目は変更を完了します、そして3日目でテストを書き、提出のためにクリーンアップします^。コードをもっと早く提出するのは気が進まないでしょう。

現在、リポジトリから変更を取得し、通常は1日に2回ローカルに統合しますが、小さな作業を分割できない限り、頻繁にコミットしません。

質問：毎日コミットすることは、それを順応させるためにワークフローを変更する必要があるほど良い習慣ですか、それともお勧めできませんか？

編集： CVSの意味で「コミット」（別名「プッシュ」）を意味していることを明確にすべきだったと思います。

^順序はより任意であり、タスクに依存します。私のポイントは、正確なシーケンスではなく、時間とアクティビティを説明することでした。

私はこの規則に同意せず、Mason Wheelerの発言に同意します。いくつかのアイデアを追加したいと思います。

私はコミットする意味のある変更があるたびにコミットしようとします：これは、いくつかの小さなバグを修正する場合は1日に数回、残りの部分では使用できないより大きなソフトウェアに取り組んでいる場合は週に1回になることがあります一貫した状態に達するまで、意味のある方法でコードを作成します。

また、私は解釈コミットとして意味のあるリビジョン公開コードベースに新しい機能を貢献しています。コミットする前にコードをクリーンアップして、他の開発者が変更履歴を見て変更の意味と目的を理解できるようにする必要があると思います。他の開発者が履歴に表示する変更が少ないほど良い：改訂履歴を見るとき、意味のある機能を追加する増分を見たい。私は、各開発者が持っていたすべての小さなアイデアに興味がなく、彼らがソリューションに到達する前に試してみたいと思っていました。

さらに、コードの現在のスナップショットがコミットされるバックアップ機能としてSVNサーバー（またはバージョン管理システム）を使用することは良い考えではないと思います（コンパイルされている場合）：USBスティックを使用できますまたは、外部USBドライブまたはネットワークディスクを使用して現在のコードをミラーリングし、コンピューターが故障しても失われないようにします。リビジョン管理とデータバックアップは2つの異なるものです。リビジョンの公開 は、コードのスナップショットの保存と同じではありません。

最後に、時々コミットすることは問題ではないと思います（つまり、コードの現在の状態に本当に満足している場合のみ）。異なる人が同じファイルを同時に操作すると、多くのマージ競合が発生します。これは悪い習慣です（この記事のポイント7を参照）。マージの競合は、プロジェクトを明確なインターフェイスとできるだけ少ない依存関係を持つモジュールに分割し、開発者の作業を調整して、作業するコードができるだけ重複しないようにすることで軽減する必要があります。

ちょうど私の2セント。

編集

私が思いついた時期尚早のコミットに対するもう1つの理由は、（非常に）バグの多いバージョンをテストできないことです。トランクでコミットしていて、テストチームが毎日テストしている場合、数時間（または1日間）テスト可能なバージョンがない場合があります。バグを修正せずに変更を元に戻そうとしても、再構築には数時間かかる場合があります。たとえば、チームで5人のテスターが働いている場合、非アクティブなためにチームの時間の5 x 2 = 10時間を無駄にしています。それは一度私に起こったので、私は本当にできるだけ早くコミットの名前で時期尚早なコミットを避けようとします。

私は1日に数回コードをコミットします。コードがコンパイルするのに十分に完了し、他のことを壊さないポイントに到達するたびに、それは入ります。

1日に数回安全にチェックインできるように、作業を分割する必要があります。

これの理論的根拠は2つです。

1. チェックインされていない作業は失われる可能性があります-コンピューターに壊滅的な障害が発生する可能性があります。この場合、待つ時間が長いほど、より多くの作業が失われます。
2. チェックインせずに行う作業が多いほど、最終的にベイク処理を決定したときに他のコードを統合する必要があります。これにより、競合やマージの問題が発生する可能性が高まります。

背後にある理由を理解せずに方法論や実践を順守することは決して良い考えではありません。それが貨物カルトプログラミングの起源です。

したがって、「Martin Fowlerがそう言ったので、私は毎日コミットする必要があります」はただ愚かです。そして時にはそれも非現実的です。複雑な新機能に取り組んでいる場合、数日間作業するまでチェックインする価値のあるポイントに到達しないかもしれません。

これは、チェックインする前にすべてが完璧であることを確認する必要があるという意味ではありません。これは、何かがうまくいかない場合に仕事を失う良い方法です。正しいことは、問題について適切な判断を下して使用することです。経験則は、あなたをとても助けます。

Odedは、できるだけ頻繁にコードをコミットする2つの重要な理由を挙げました。さらにいくつか追加します。

1. コードの作業中に、他の人はそのコードでいくつかの機能を必要とする場合があります。彼らはそれを得るために6日間待つべきではありません。この場合、同僚は通常、コードの一部にプロトタイプを作成してコミットし、本文を追加して再度コミットします。そして、これは通常数時間で行われます。

2. 「共通」コードは、すべての変更をできるだけ早く確認するためのものです。作業中のコードが他の作業と完全に分離されていて、待機させない場合は、作業用のブランチを作成することをお勧めします。メインライン。

私は、維持する価値のあるすべての論理的な変更をコミットすることを強く信じています。頻繁にコミットし、コードを維持する価値がない場合は、クリーンな状態に戻します。コードをプッシュ/パブリッシュするのを長く待つほど、実装が難しくなり、実行される問題が多くなります。また、貢献に関するフィードバックをより迅速に受け取ることができます。

• 彼らはビルドを壊しますか？
• 他のチームメンバーの努力を複製していますか？
• 何か間違ったことをしていますか？
• または人々はあなたからのものを待っていますか？

小さな変更は管理がはるかに簡単です。

また、異なるバージョン管理システムの違いに注目する価値があります。Git（分散型）などの一部では、公開の準備ができたときにのみプッシュして、履歴全体をローカルでコミットおよび制御できます。SVN（集中型）のような他のものは、小さなコミットを非常に非効率的にする2つのステップを結合します。

コミットは本質的に変更ドキュメントであることを忘れないでください。物事がうまくいかないとき、あなたは十分ではないよりも多くの歴史を持つことができます。1週間の作業を1回行うだけでは役に立たないようです。最終的には、各論理チャンクの要約ではなく、変更されたコードのすべての行を読むことになります。

ここでの答えのほとんどは、Martin Fowlersの声明の主要なポイントの1つを逃していると思います。これは継続的インテグレーションに関連しています。メインラインにチェックイン（プッシュ/公開/マージ）されていないコードはテストされません。

これは、オフィスを離れるときはいつでも、ローカルマシンにあるコードをコミットすることを推奨するものではありません。ここでいくつかの他の人が指摘したように、それは悪いことであり、ビルドを壊し、不安定なメインラインを引き起こします。

ただし、問題を引き起こすことなくメインラインにチェックインできる小さな手順で変更を行うことをお勧めします。これにより、コードをすべて切り離して書き換えるのではなく、コードの進化が促進されます。

さて、この働き方の良いところは何ですか？

1. 大量のコードや革新的な変更をコミットしないと、ビルドが壊れる可能性が低くなります。
2. コミットがビルドを壊した場合、問題が何であるかを特定し、それを元に戻してから修正バージョンをすばやくコミットするのはかなり簡単です。
3. コードの小さな変更ごとにすべてのテストが実行されるようにすることで、継続的な統合スキームの外でコードが成長することによる微妙なバグやリグレッションが発生しないようにします。

もちろん、すべての変更がこのアプローチに適しているわけではありません。他の人が指摘したように、絶対的なルールはありません。ただし、長期間メインラインから外れることが予想される変更については、独自の継続的統合スキームを使用して代替メインラインを設定し、同じアプローチに従ってください。今日の分散型VCSでは、これは非常に簡単です。

毎日チェックインするための引数：

• コードは保存され、ハードドライブの障害に対してバックアップされます
• アクティビティはコミットノートに記録できます（木曜日に何をしましたか...？）
• 既存のコードベースとの統合はより早く、より小さなチャンクで行われ、競合またはマージの問題をより早く特定することが望まれます
• あなたのチームはあなたが取り組んでいるものの可視性を持っています
• あなたの同僚はあなたのインターフェースに対してより早く取り組むことができ、あなたの「大きな複雑なコード」と統合するためのより多くの時間を与えます
• あなたのコードは実世界でより早くテストされるか、少なくともあなたが与えるよりも多くの使用にさらされ、バグや省略のより早い特定につながります。

毎日のチェックインに対する議論：

• する必要がない、またはしたくない
• まだ私のコードを「クリーンアップ」していない、それは混乱です
• 時間がない

怠lazや混乱を除けば、毎日チェックインするよりも良い理由はないと思います。開発環境で実行されているコードが開発ブランチのコードと一致しないのは、誰かが「まだ終了していない」ためチェックインしていないためです。

私はこれについて間違っていると思いますので、毎日のチェックインに対する正当な議論を教えてください。

「メインラインへのマージ」として「コミット」を意味している場合、顧客にリリースされているソフトウェアプロジェクトでそのようなことを絶対にしないでください。メインラインが常に機能し、リリース可能になり、機能が途中で壊れた状態にならないように、実行およびテストされた変更をマージする必要があります。

ただし、今日の分散バージョン管理を使用することの贅沢さは、メインラインを安定させると同時にgit/hg/whatever commit、物事の状態を維持したいと思うたびにその両方を行えることです。私はこれを数時間に一度、間違いなく毎日の終わりに行います。

DVCSを使用すると、作業を公開し、チーム内の他のユーザーと共同作業し、メインラインブランチの変更に合わせて最新の状態に保つことができます。顧客や他のチームが依存するコードの安定性を汚染することなく、これらすべてを実行できます。

Subversionが最新のテクノロジーであり、極端な苦痛を伴わずに機能ブランチを分岐およびマージする方法がなかった時代には、いくつかの異なる機能が同時に構築されていたメインラインを持つことが最善のアプローチだったかもしれません。しかし、この優位性は2010年を超えて拡大することはありません。

Team Foundation Serverでは、チェックインとは異なる「シェルブ」を実行できますが、マシンが死んだ場合でも変更を失わないようにコードのバックアップを作成するだけです。

また、「開発者ライン」と「メインライン」があるソフトウェアハウスを見てきました。開発者は、適切と判断した場合はいつでも開発者ラインに自由にチェックインでき、メインラインにアクセスできるのはチームリーダーのみです。