私は、非常に大きなオーバーラッピングコードベースを持ついくつかのプロジェクトを持っています。我々はちょうど最近SVNを使い始めたので、私はそれをどのように使うべきかを考えようとしています。複数のプロジェクトでのバージョン管理のベストプラクティス
問題は、あるプロジェクトでタスクを終了しているときに、別のタスクを開始していて、重複しています。多くの場合、割り込み駆動型開発も多くあります。だから、私のコードは決して本当に完全に安定した状態ではありません。私は快適にチェックインしています。
結果は私たちが本当にVCシステムを使用していないということです。だから、提案？
コードの個人的なブランチを調べ、変更をマージします。少なくともロールバックする必要がある場合に備えて、独自の変更のためのいくつかのバージョン管理機能があります。ブランチが入っている状態に慣れたら、そのブランチをトランクに戻してマージしてください。
個々のタスクではなく、各タスクの分岐をチェックアウトすることもできます。誰かがトランクを変更し、ブランチに変更を反映させたい場合は、トランクからブランチへの変更をマージすることもできます。
これはSVNを使用する一般的な方法ですが、他のワークフローもあります。私はブランチングを効果的に使用していなかったため、私がコミットするのを恐れていたプロジェクト（おそらくビルドを中断する）に取り組んできました。
ブランチングは、あなたのワークフローを助けるのに本当に強力です。マージの考え方に慣れるまでは、ブランチングを使用してください。
編集： 'ブランチをチェックアウトする'とは、ブランチフォルダにブランチを作成し、そのブランチをチェックアウトすることです。標準のsvnリポジトリ構造は、ルートのトランク、タグ、ブランチのフォルダで構成されています。
TFSでは、「シェルフセット」を作成することができます（他のソース管理プロバイダでは何が呼び出されるのか分かりません）。
これが重要な理由は、バグXXXXを扱っていて、コードの半分を修正しても、それが修正されていない場合です「チェックイン可能」ではないが、NewFeature YYYYに割り当てられた場合、同じコードベースで作業を続けるべきではない（SHOULD NOT）。 Bug XXXXコードを 'Shelf'し、ローカルのコードベースを最新のチェックインコードに戻し、NewFeature YYYYを実装してください。
この方法で、チェックインをアトミックに保ちます。リポジトリに保存されているので、作業を失うことについて心配する必要はありません（したがって、コンピュータが炎で破裂しても、涙を浮かべる必要はありません）。そして、XXXXの修正を混ぜていませんあなたの新しいコードをYYYYに入れてください。 その後、XXXXに戻るように頼まれたら（YYYYをチェックインしたと仮定して）、あなたはあなたの「シェルフセット」をアンヘルブし、中断した場所にすぐ戻ることができます。
SVNのコードが完全に安定した状態ではなく、とにかくチェックしてください（コードがあまりにも劣化しないように、X日/週ごとに安定化とリファクタリングのための時間を予約してください）。
または、チームの中断を最小限に抑えながらより構造化された方法で作業し、良いコードをチェックインできるようにします。
最初のオプションは理想的ではありませんが、ソースコントロールはありません。第2のオプションは不可能です。第3のオプションはありません。
コードを安定した状態にする時間がない場合は、常に分岐してマージする時間がありません。
だから、私のコードは、私がチェックインし、快適に感じることを完全に安定した状態で、本当に決してありません。
それはなぜですか？
ブランチが作業に適している場合（たとえば、命名規則が良い）、すべての人がそのヘッドが常に安定しているとは限りません。
この種の「作業中の」ブランチでは、いくつかのタグを途中に配置して、「安定したコードポイント」を指定します（デプロイするすべてのテスターによって照会できる）。
現在の状態が安定していない場合でも、その作業ブランチ上の他のバージョンは、変更を記録するためだけに行われます。
その後、安定した状態を表すと思われるブランチにすべてをマージします。
GITのような分散ソース管理システムでは、ローカルリポジトリにコミットします。コードをプッシュした場合にのみ、リモートリポジトリに「コミット」されます。
このようにして、その間の作業を「安全に」するのがはるかに簡単です。
問題は私たちが7人（エンジニア2人）の会社なので、実際にはそのような構造になることはできません。また、「チーム」は私だけです。 –