集中型バージョン管理では、頻繁に更新することは常に良いことですか？

仮定して：

• チームは一元化されたバージョン管理を使用しています。
• 完了までに数日かかる大きな機能に取り組んでいますが、ビルドが中断するため、それより前にコミットすることはできません。
• チームメンバーは、作業中のファイルの一部を変更する可能性がある何かを毎日コミットします。

これは一元化されたバージョン管理であるため、ある時点でローカルチェックアウトを更新する必要があります：新しい機能をコミットする直前に少なくとも1回。

コミットの直前に1回だけ更新すると、チームメイトによる他の多くの変更が原因で多くの競合が発生する可能性があり、一度にすべてを解決するのは苦痛の世界になる可能性があります。

または、頻繁に更新することもできますが、毎日解決する競合がいくつかあるとしても、少しずつ簡単に解決できるはずです。

頻繁に更新することを常にお勧めしますか？

個人的には、ローカルバージョンを毎日更新しています。

あなたが説明するシナリオでは、私はさらに一歩進んでいきます

• 新しい長いフィーチャーのブランチを作成します。
• メインラインからこの新しいブランチに頻繁にマージします。

こちらです、

• サーバーにコードを保存するために毎日チェックインできます
• チェックインによってビルドが壊れることを心配する必要はありません。
• 以前のチェックインで必要に応じて、リポジトリを使用して一部の作業を取り消したり、diffしたりできます。
• 最新のコードベースで作業していて、競合する可能性のあるコード変更を早期に検出することが確実です。

私がそれらを見るときの欠点は

• メインからのマージは手動で（またはスクリプトで）行う必要があります
• もっと「管理」が必要

はい、頻繁に更新することをお勧めします。困難なマージの競合を回避するために頻繁に更新します。これが、ソフトウェア構成管理（SCM）の知識の基本であり、相違点が変化するという問題があります。

これは、集中型か分散型かに関係なく、アップストリームソースから分岐する時間が長いほど（つまり、DVCSの場合、トランク、ブランチ、またはその他のリポジトリである場合）、マージの競合が発生する可能性が高くなります。はい、更新時にチームからの厄介な驚きが発生する可能性がありますが、厄介な驚きを先延ばしにすることはさらに悪化します（待つ時間が長くなるほど、一連の変更が行われた理由を覚える人が少なくなります）。

更新して動作するようにするには、これは、コードを扱う他のプログラマーが、ビルドを破壊する上流のコードを故意にコミットまたはプッシュしてはならないことも意味します。通常、これがプログラマーが分岐する（またはSCM用語で上流から分岐する）理由で、このような状況が必然的に発生した場合にチームメンバーや他の利害関係者がコードを壊すのを防ぎます。

覚えておくべきマントラは、「更新、更新、更新、コミット」です。コミットする前に、変更が他のユーザーと連携できることを常に確認してください。これは、コードを初めてチェックアウトすることも確実に機能するようにするためでもあります。

質問の3番目の箇条書きは間違っています。

• あなたは新しい機能に取り組んでいますが、完了するまでに数日かかることは確かです。ビルドが壊れてしまうため、それより前にコミットすることはできません。

あなたがしばらくの間コミットできない何かに取り組んでいることがわかっているなら、それはブランチを使用するための教科書の例です。

保留中の変更が多い状況に置かないでください。あなたがいる場合知っているあなたには、いくつかの時間のためにあなたのプロジェクトのメインブランチにコミットすることはできません、その後、別のブランチに取り組んでいます。そしてそこで、頻繁にコミットします。

すでに質問で説明されている状況になっている場合は、今すぐブランチに切り替えて、変更をコミットし、そのブランチで作業を続けます。

通常CVCSでは、頻繁に更新することをお勧めします。しかし、ブランチで作業している場合、「頻繁に更新するかどうか」の質問は「頻繁にマージするかどうか」になります。とにかく答えはイエスです。別のブランチからマージする前に、（ブランチ内の）保留中のすべての変更をコミットし、必要に応じてマージを安全にロールバックするオプションにコミットしてください。

もっと頻繁にコミットすべきだと思います。数日など長時間作業する場合は、トランクで直接作業するのではなく、コードをブランチしてブランチで作業する必要があります。私はブランチなしで作業を始めるのが便利だと知っていますが、更新/コミットがコードを破壊するかどうか確信が持てず、最終的に更新/コミットを保持する状況になるので、実際には柔軟性がありませんあなたの仕事をしました。「機能の分岐」は、常にコードをコミットし、終了時に後でマージできるという点で優れています。

分岐戦略では、更新はトランクからのマージに置き換えられます。私の経験では、トランクからマージする必要はあまりありません。5日間の期間などのコードはそれほど変化せず、終了時に一度だけ競合を解決する方が簡単だからです。

ローカルで分散バージョン管理を使用する方が実際には便利です。つまり、私はgitをsubversionクライアントとして使用しています。これには次の利点があります。

• ローカルの変更は更新前に保存されるので、マージを間違えた場合はいつでも戻ってやり直すことができます。
• より大きな変更を行う場合、完成したパーツを保存できます。これにより、進行中の残りの変更を簡単に確認できます。
• より大きな作業中にバグを修正する場合、その修正のみをコミットし、残りを一時的にコミットして、他の作業をローカルに維持しながら、修正をsubversionに「dcommit」できます。

新しい機能を追加する場合、新しい単一のソースファイル（および対応する外部インターフェイスヘッダーファイル）を作成できますか？

「新機能」が広範な影響を持っていることを心配していますか？オブジェクト指向はもはやかつての流行語ではないかもしれませんが、そのパラダイムにはメリットがあります。

そうすれば、フレームワーク（外部インターフェイスとスタブ関数）を作成し、それをコミットすることができます。そうすれば、残りの開発が完了するまで、サードパーティの影響が最小限になるはずです。

あなたが説明している状況では、少数の大きなファイルよりも小さなソースファイルを使用する方が良いと感じています。

集中型バージョン管理と分散型バージョン管理の違いは何ですか？

どちらの場合も、開始したコンテンツと比較してコンテンツが移動する場所でチェックインする必要があります。中央リポジトリから作業場所へのマージの頻度に違いはありません（プロジェクトブランチが作業場所です）。

私は頻繁にマージする傾向があります（少なくとも1日に1回、他の都合の良いときに、または誰かが自分の作業に影響を与える何かをチェックインしたことがわかったときにマージすることもあります）。小さな変更を吸収する方がはるかに簡単です。問題が発生した場合、1週間前にチェックインした内容よりも、チェックインしたばかりの内容について質問する方が助けになります。

ところで、私はあなたが「ビルドを壊す」と呼ぶものを知りません。私は比較的小さな増分で作業する傾向があるため、一部の機能が無効になってもコンパイル可能な状態を維持します。そして、テストを実行して、マージが機能するはずの何かを壊していないことを確認します。繰り返しになりますが、問題が早期に検出された場合は、問題を修正する方が簡単です。

それは、誰かがビルドを壊したときに、あなたが「更新解除」にどれだけ優れているかに依存します。一方では、できるだけ小さなチャンクで更新したいとします。個人的には、更新が利用可能であることに気づくたびに更新します。一方、ビルドが失敗し、誰かが修正するのに1日かかる場合でも、その間に新しい機能に取り掛かることができます。

更新が完了するとバックアップが非常に難しいバージョン管理システムを使用してきました。それらについては、チェックインが必要になる直前にのみ更新する傾向があります。より良いバージョン管理システムを使用すると、1日に数回更新しない理由はほとんどありません。