集中型バージョン管理では、頻繁に更新することは常に良いことですか？
仮定して：
- チームは一元化されたバージョン管理を使用しています。
- 完了までに数日かかる大きな機能に取り組んでいますが、ビルドが中断するため、それより前にコミットすることはできません。
- チームメンバーは、作業中のファイルの一部を変更する可能性のある何かを毎日コミットします。
これは一元化されたバージョン管理であるため、ある時点でローカルチェックアウトを更新する必要があります：新しい機能をコミットする直前に少なくとも1回。
コミットの直前に一度だけ更新すると、チームメイトによる他の多くの変更が原因で多くの競合が発生する可能性があり、一度にすべてを解決するのは苦痛の世界になる可能性があります。
または、頻繁に更新することもできます。毎日解決する競合がいくつかある場合でも、少しずつ簡単に解決できます。
頻繁に更新することを常にお勧めしますか？
個人的にはローカルバージョンを毎日更新しています。
あなたが説明するシナリオでは、私はさらに一歩進んでいきます
- 新しい長いフィーチャーのブランチを作成します。
- メインラインからこの新しいブランチに頻繁にマージします。
このように
- サーバーにコードを保存するために毎日チェックインできます
- チェックインによってビルドが壊れることを心配する必要はありません。
- 以前のチェックインで必要に応じて、リポジトリを使用して一部の作業を取り消したり、diffしたりできます。
- 最新のコードベースに取り組んでおり、競合する可能性のあるコード変更を早期に検出することは間違いありません。
私がそれらを見るときの欠点は
- メインからのマージは手動で（またはスクリプトで）行う必要があります
- もっと「管理」が必要
はい、頻繁に更新することをお勧めします。 難しいマージの競合を回避するために頻繁に更新しますこれは、ソフトウェア構成管理（SCM）の知識の基本であり、相違点が変化するという問題があります。
これは、集中型か分散型かに関係なく、アップストリームソースから分岐する時間が長いほど（つまり、DVCSの場合、トランク、ブランチ、または他のリポジトリである場合）、マージの競合の可能性が高くなります。はい、更新時にチームからの厄介な驚きが発生する可能性がありますが、厄介な驚きを先延ばしにすることはさらに悪くなります（待つ時間が長くなるほど、一連の変更が行われた理由を覚える人が少なくなります）。
更新して動作するようにするには、これはコードを扱っているプログラマーや他のプログラマーが意図的にコミットしたり、ビルドを壊す上流のコードをプッシュしたりしないでくださいであることも意味します。通常、これがプログラマーが分岐する（またはSCM用語で上流から分岐する）理由で、このような状況が必然的に発生した場合にチームメンバーや他の利害関係者がコードを壊すのを防ぎます。
覚えておくべきマントラは、「更新、更新、更新、コミット」です。コミットする前に、変更が他のユーザーと連携できることを常に確認してください。これは、コードを初めてチェックアウトすることも確実に機能するようにするためでもあります。
質問の3番目の箇条書きは、単にwrongです。
- あなたは新しい機能に取り組んでいますが、完了するまでに数日かかることは確かです。ビルドが壊れてしまうため、それより前にコミットすることはできません。
もしあなたが知っているあなたがしばらくの間コミットできない何かに取り組んでいるなら、それはブランチを使うための教科書の例です。
保留中の変更が多い状況に置かないでください。あなたが知っている場合、しばらくの間プロジェクトのメインブランチでコミットすることができなくなり、別のブランチで作業することができます。そして、頻繁にコミットします。
すでに質問で説明されている状況になっている場合は、ブランチに切り替えて今すぐにし、変更をコミットして、そのブランチでの作業を続けます。
通常CVCSでは、頻繁に更新することをお勧めします。しかし、ブランチで作業している場合、「頻繁に更新するかどうか」の質問は「頻繁にマージするかどうか」になります。とにかく答えはイエスです。別のブランチからマージする前に、（ブランチ内の）保留中のすべての変更をコミットし、必要に応じてマージを安全にロールバックするオプションにコミットしてください。
もっと頻繁にcommitすべきだと思います。数日など長時間作業する場合は、トランクで直接作業するのではなく、コードをブランチしてブランチで作業する必要があります。私はブランチなしで作業を始めるのが便利だと知っていますが、更新/コミットがコードを破壊するかどうか確信が持てず、最終的に更新/コミットを保持する状況になるので、それほど柔軟ではありませんあなたの仕事をしました。 「機能の分岐」は、常にコードをコミットし、終了時に後でマージできるという点で優れています。
分岐戦略では、更新はトランクからのマージに置き換えられます。私の経験では、トランクから頻繁にマージする必要はありません。5日間などのコードはそれほど変化せず、終了時に一度だけ競合を解決する方が簡単だからです。
ローカルで分散バージョン管理を使用するほうが実際に便利だと思います。つまり、Subversionクライアントとしてgitを使用しています。これには次のような利点があります。
- ローカルの変更は更新前に保存されるので、マージを間違えた場合はいつでも戻ってそれをやり直すことができます。
- より大きな変更を行う場合、完成したパーツを保存できます。これにより、進行中の残りの変更を簡単に確認できます。
- より大きな作業中にバグを修正するときは、その修正だけをコミットし、残りを一時的にコミットして、他の作業をローカルで実行しながら、修正をSubversionに「dcommit」できます。
新しい機能を追加する場合、新しい単一のソースファイル（および対応する外部インターフェイスヘッダーファイル）を作成できますか？
「新機能」が広範な影響を持っていることを心配していますか？オブジェクト指向は以前の流行語ではなくなった可能性がありますが、そのパラダイムにはメリットがあります。
このようにして、フレームワーク（外部インターフェイスとスタブ関数）を作成し、それをコミットすると、残りの開発を完了する間、サードパーティの影響が最小限になるはずです。
あなたが説明する状況では、少数の大きなファイルよりも小さなソースファイルを使用するほうが良いと感じています。
集中型バージョン管理と分散型バージョン管理の違いは何ですか？
どちらの場合も、開始したコンテンツと比較してコンテンツが移動する場所でチェックインする必要があります。中央リポジトリから作業場所へのマージの頻度に違いはありません（プロジェクトブランチが作業場所です）。
私は頻繁にマージする傾向があります（少なくとも1日に1回、他の都合の良いときに、または誰かが自分の作業に影響を与える何かをチェックインしたことがわかったときにマージすることもあります）。小さな変更を吸収する方がはるかに簡単です。問題が発生した場合、1週間前にチェックインした内容よりも、チェックインしたばかりの内容を尋ねると、人々の助けになります。
ところで、私はあなたが「ビルドを壊す」と呼ぶものを知りません。私は比較的小さな増分で作業する傾向があるため、一部の機能が無効になってもコンパイル可能な状態を維持します。そして、テストを実行して、マージが機能するはずの何かを壊していないことを確認します。繰り返しになりますが、問題が早期に検出された場合は、問題を修正する方が簡単です。
それは、誰かがビルドを壊したときに、あなたが「更新解除」にどれだけ優れているかに依存します。一方では、できるだけ小さなチャンクで更新したいとします。個人的に、私はアップデートが利用可能であることに気づくたびにアップデートします。一方、ビルドが壊れて、誰かが修正するのに1日かかる場合でも、その間に新しい機能に取り掛かることができます。
更新が完了するとバックアップが非常に難しいバージョン管理システムを使用してきました。それらについては、チェックインする必要がある直前にのみ更新する傾向があります。より良いバージョン管理システムを使用すると、1日に数回更新しない理由はほとんどありません。