ソース管理への変更をコミットする頻度はどれくらいですか？[閉まっている]

どのくらいの頻度で変更をソース管理にコミットする必要がありますか？すべての小さな機能の後、または大きな機能のみですか？

私はプロジェクトに取り組んでおり、実装する長期的な機能があります。現在、私はすべての作業、つまり実装されたすべてのサブ機能とバグ修正の後でコミットしています。バグを発見した後、いくつかの機能のテストの新しいチャンクを追加した後でもコミットします。

しかし、私はこのパターンを心配しています。仕事の生産的な日に、私は10回コミットするかもしれません。私がSubversionを使用していることを考えると、これらのコミットはリポジトリ全体に影響を与えるので、実際にそれを非常に多く作成するのは良い習慣なのでしょうか。

コンパイルして実行するコードの「完全な思考」を完了するたびに、チェックインします。これは通常、15〜60分のいずれかになります。場合によってはさらに長くなることもありますが、失敗した場合に書き換えたくないコードの変更が多数ある場合は、常にチェックインを試みます。私は通常、コードがコンパイルされていることを確認し、帰宅する前の1日の終わりにチェックインします。

「多すぎる」コミット/チェックインをすることについて心配する必要はありません。何かを書き直さなければならないときは本当に面倒ですし、万が一に備えて少しずつロールバックできるのは素晴らしいことです。

「コミットがリポジトリ全体に影響する」と心配していると言うとき、リポジトリ全体のリビジョン番号が増加しているという事実を参照していますか？Subversionがそれを格納するために使用するビット数はわかりませんが、リビジョン番号が不足することはないと確信しています！ 多くのコミットは問題ではありません。 隣の男の10倍の頻度でコミットでき、二酸化炭素排出量はまったく増加しません。

単一の関数またはメソッドには、その機能に応じた名前を付ける必要があります。名前が長すぎると、処理が多すぎます。私は同じルールをチェックインに適用しようとします。チェックインコメントは、変更によって達成されることを正確に説明する必要があります。コメントが長すぎる場合は、おそらく一度に変更しすぎています。

私はジェフ・アトウッドからのこの小さな記事が好きです：早めにチェックイン、頻繁にチェックイン

私は個人的に、終了/安定/コンパイルされたコードのすべての論理グループをコミットし、その日に行ったことをコミットせずにその日を離れないようにします。

大きな変更を行っていて、コードで作業している他の人への影響を懸念している場合は、新しいブランチを作成し、変更が完了した後でトランクにマージすることができます。

タスクが完了するたびにコミットします。これには通常30分から1時間かかります。

バージョン管理コメントが1文または2文より長い場合は、おそらく十分な頻度でコミットしていません。

私はオープンソースのマントラ（言い換え）に従います-早い段階でコミットし、頻繁にコミットします。

基本的に、他のチームメンバーに問題を引き起こさずに、便利な機能を追加したと思ったときはいつでも（小さなものでも）。

このコミット頻度の戦略は、他の開発作業に対する統合テストを可能にし、問題を早期に検出できるため、継続的統合環境で特に役立ちます。

実際に機能しないコードをコミットしないでください。リポジトリをバックアップソリューションとして使用しないでください。

代わりに、不完全なコードをローカルで自動化された方法でバックアップします。Time Machineが私の面倒を見てくれて、他のプラットフォーム用の無料のプログラムがたくさんある。

私が使用する経験則では、チェックインされるのは、チェックインされるファイルのグループが1つのチェックインコメントでカバーできる場合です。

これは通常、チェックインがアトミックであること、およびコメントが他の開発者によって簡単にダイジェストされることを保証するためです。

これは、変更が、アプリケーション全体に及ぶ構成ファイル（SpringコンテキストファイルやStruts構成ファイルなど）に影響を与える場合に特に当てはまります。チェックインする前にいくつかの「グループ」の変更を行うと、それらの影響が構成ファイルで重複し、2つのグループが互いにマージされます。

あまり心配する必要はないと思います。ここで重要なのは、何を、いつ、なぜ行うかです。3時間ごとまたは24時間ごとにコミットする必要があると言っても、意味がありません。コミットするものがあればコミットし、ない場合はコミットしないでください。

これは、バージョン管理の推奨ベストプラクティスからの抜粋です。

[...]プロジェクトに同時に多くの変更を加える場合は、それらを論理的な部分に分割し、複数のセッションでコミットします。これにより、個々の変更の履歴を追跡するのがはるかに簡単になり、後でバグを見つけて修正するときに多くの時間を節約できます。たとえば、機能A、B、Cを実装し、バグ1、2、3を修正する場合、合計で少なくとも6つのコミットが行われます（機能ごとに1つ、バグごとに1つ）。大きな機能に取り組んでいる場合や、大規模なリファクタリングを行っている場合は、作業をさらに小さな部分に分割し、各部分が完了した後にコミットすることを検討してください。また、複数の論理モジュールに独立した変更を実装する場合は、より大きな変更の一部であっても、変更を各モジュールに個別にコミットします。

理想的には、ハードドライブにコミットされていない変更を加えてオフィスを離れないでください。変更が他の人に影響を与えるプロジェクトで作業している場合は、ブランチを使用して変更を実装し、完了したらそれらをトランクにマージすることを検討してください。ライブラリまたはプロジェクトへの変更をコミットするとき、他のプロジェクト、つまり他の人々が依存している場合は、コンパイルされないコードをコミットすることによってビルドを壊さないようにしてください。ただし、コンパイルしないコードがあることは、コミットを回避するための言い訳にはなりません。代わりにブランチを使用してください。[...]

現在のパターンは理にかなっています。このソース管理の使用方法を覚えておいてください。ロールバックする必要がある場合、または差分を作成する場合はどうでしょうか。あなたが説明するチャンクは、それらの場合、まさに正しい差異のように見えます：diffは、バグ＃（チェックインログで指定）の実装で何が変更されたか、または機能を実装するための新しいコードが正確に何であるかを示します。同様に、ロールバックは一度に1つだけに影響します。

また、1日に数回の作業を終えた後でコミットすることも好きです。大きなコミットよりも小さなコミットで何が起こっているかを確認する方が簡単だと思います。コミットが多すぎることが心配な場合は、ブランチ全体を作成し、機能全体が終了したらブランチにマージすることを検討してください。

関連するブログ投稿は次のとおりです。コーディングホラー：早期チェックイン、頻繁チェックイン

他の人が述べたように、他の開発者の邪魔にならないように「完全」である1つの論理チャンクをコミットしてみてください（たとえば、自動テストを構築して合格します）。

各開発チーム/会社は、各ブランチに対して「十分」なものを定義する必要があります。たとえば、ビルドのみのコードが必要な機能ブランチ、自動テストに合格するためにコードも必要なトランク、QAテストに合格したことを示すラベルなどがあります。

これが良いパターンだと言っているのではありません。どのように「実行」されるかは、チームまたは会社のポリシーによって異なることを指摘しているだけです。

考えた瞬間。

（チェックインしたものが安全である限り）

ソースコードシステムと他に何を配置しているかによって異なります。Gitを使用している場合は、ステップを完了するたびにコミットします。私はSVNを使用していて、機能全体を完了したときにコミットするので、1〜5時間ごとにコミットします。CVSを使用していた場合も同じです。

私はいくつかの応答に同意します。コンパイルされないコードをチェックインしないでください。コードまたはその変更の「バックアップ」が懸念される場合は、個人のブランチまたはリポジトリを使用してください。論理ユニットが完成したらチェックインします。

もう1つ付け加えておきたいのは、環境によっては、チェックイン率が時間とともに異なる場合があるということです。たとえば、プロジェクトの早い段階でコンポーネントの各機能部分が完了した後でチェックインすることは、安全性と改訂履歴の両方にとって意味があります（私は、以前のビットがリファクタリングされ、新しいものが開発されている場合を考えています）。一方、プロジェクトの後半では、特に統合の開発/テスト中に、完全に完全な機能がより重要になります。半統合または半修正は​​誰にも役立ちません。

各バグ修正後のチェックインについて：修正が簡単でない限り、絶対に！1つのチェックインに3つの修正が含まれており、そのうちの1つをロールバックする必要があることを発見することほど痛みはありません。多くの場合、そのような状況では、開発者は1つの領域で3つのバグを修正し、どの変更がどのバグ修正に適用されるかを明らかにするのは悪夢のようです。

定期的にチェックインするのも好きです。それは私が自分の目標に向けてのステップを完了するたびです。

これは通常、数時間ごとです。

私の問題は、非常に多くのコードレビューを実行してくれる人を見つけることです。

私たちの会社のポリシーでは、チェックインする前にコードレビューを行う必要があります。可能な解決策：

1. チェックインごとの作業が増えます。チェックインを減らす==レビューを減らす。
2. 会社のチェックインポリシーを変更します。リファクタリングを実行したばかりで、ユニットテストがすべて正常に実行された場合、ルールを緩和できますか？
3. 誰かがレビューを実行して作業を続行できるようになるまで、変更を保留します。これは、レビュー担当者があなたのコードを嫌い、再設計する必要がある場合に問題になる可能性があります。変更を「棚上げ」することで、タスクのさまざまな段階をジャグリングすると、混乱する可能性があります。

正常にコンパイルされ、単体テストでリグレッションが発生しない限り、変更を30〜60分ごとにコミットするのが好きです。

まあ、あなたは好きなだけ何度でもコミットできるあなた自身のブランチを持つことができ、あなたの機能が終わったら、それをメイントランクにマージすることができます。

コミットの頻度について、私はこのように考えています。ハードディスクがクラッシュし、何かをコミットしなかった場合、私にとってどれほどの痛みを感じるでしょうか。私にとって、この何かの量は約2時間です。

もちろん、コンパイルできないものをコミットすることはありません。

少なくとも一日一回。

コミットごとに特定の時間制限はありません。テストに合格したらコミットする傾向があり、コードに満足しています。コンパイルできない、または失敗した場合に戻すことに不満がある状態のコードをコミットしない

一方では安全性と回復可能性の妥協点、他方ではプロジェクト全体の変更管理の容易さのバランスをとる必要があります。

私が使用した最良のスキームには、その質問に対する2つの答えがありました。

私たちは2つの完全に別個のリポジトリーを使用しました。1つはプロジェクト全体のリポジトリーで、もう1つは独自の個人リポジトリーでした（当時はrcsを使用していました）。

開いているファイルを保存するたびに、非常に定期的に個人リポジトリにチェックインします。そのため、個人用リポジトリは、基本的には大きく、長期にわたる、取り消しバッファーでした。

コンパイルして大丈夫なテストを行い、一般的な使用の準備ができているとして受け入れられたコードのチャンクができたら、プロジェクトリポジトリにチェックインしました。

残念ながら、このシステムは、さまざまなVCSテクノロジーを使用して機能します。同じタイプのVCSを2つ使用しているときに（たとえば、2つのSubversionリポジトリなど）、同じ結果を得る満足のいく方法は見つかりませんでした。

ただし、Subversionリポジトリに「個人的な」開発ブランチを作成することで許容できる結果が得られました。ブランチを定期的にチェックインし、完了したらトランクにマージします。

リリースされないブランチで作業している場合、コミットは常に安全です。

ただし、他の開発者と共有している場合、機能していないコードをコミットするのは少し面倒です（特に重要な場所にある場合）。通常、私は効果的に機能しているコードのみをコミットします。完全にテストされているわけではなく、実際にコンパイルされてすぐに失敗しないことを確認しました。

統合されたバグトラッカーを使用している場合、2つのバグを修正した場合は別々のコミットを実行すると、コミットログが適切なバグに対応できるようになるため便利です。しかし、繰り返しになりますが、1つのコード変更で2つのバグが修正されることがあるので、どのバグに対応するかを選択する必要があります（システムで1つのコミットを複数のバグに関連付けることができない場合）

私はまだ「頻繁にコミットし、早くコミットする」というフレーズを信じています。私はMercurialのような分散型のVCSを好み、いくつかのことをコミットして後でアップストリームにプッシュしても問題はありません。

これは本当に一般的な質問ですが、本当の質問は次のとおりです。未完成のコードをコミットできますか？

機能するコードを完成させ、更新で他の人がそれを取得しても、だれも台無しにしないときはいつでも。

そして、適切にコメントしてください。