コミットを適切に管理し、機能の競合を防ぎ、VCSとの依存関係を管理するにはどうすればよいですか？

これは、大規模なチームとの共同作業の厄介な要素になっています。チェックインを管理し、機能の競合を防ぎ、ソース管理で依存関係を適切に管理するにはどうすればよいですか？

現在、私の職場ではTFS 2008を使用しており、12月初旬にTFS 2010に移行しています。まず、どのソース管理も他より優れていますが、複数のチェックインを防ぎ、ソース管理履歴全体をロールバックするのに役立つアプローチは誰ですか？揮発性トランクは、新しい機能を実装してトランクにマージし直すときに分岐または分岐する最善の方法ですか？

他の人の経験や、おそらくソース管理を管理するためのいくつかのベストプラクティスをぜひ聞きたいです。

TFS？丘を駆け抜けろ！できるだけ早く離れてください。それは多くの異なることをしますが、それらのどれも利用可能な最高の品種ツールほど優れていません。

しかし真剣に：

適切なバージョン管理システム（SVN、GITなど）を入手したら、ブランチ管理のルールを設定することをお勧めします。たとえば、ブランチをいつ作成するか、何をいつ、誰とマージするか、などなどです。

最近まで、新しい開発（「トランク」）に単一のブランチを使用していました。リリースの場合、トランクからブランチを作成します。最終的なQAはそのブランチで行われ、完了したらリリースします（月次リリースです）。

スケジュールのリスクを減らすために、「トランクにジャンクがない」という概念に切り替えました。このコンセプトには基本的に、トランクとは別に開発作業用のブランチを作成するためのルールが含まれています。たとえば、小規模な開発チームなどのために、機能ごとに個別のブランチを用意できます。「エピック」を使用して、小さな機能または機能の解放可能な部分を説明し、各エピックのブランチを作成します。少なくとも1日に1回、トランクからのすべての変更がエピックブランチにマージされます。キーは、バージョン管理または別のツール（例：3方向マージ）による適切なマージサポートです。エピックのQAはエピックのブランチで行われます。合格すると、エピックブランチがトランクにマージされ、統合テストが実行されます。リリース用のブランチはまだあります。

エピックブランチを使用すると、トランクから解放し、トランクに正常にマージされたすべてのエピックを含めることができるようになるため、スケジュールリスクを大幅に削減できました。完全ではないエピックはバスを逃し、次のリリース（翌月）を行います。

もちろん、これは私たちの環境でのみ機能します。おそらく、ブランチ管理に最適な選択に影響を与える、当社とは異なる要素があるでしょう。

たとえば、多くの人がリモートで作業していて、常にバージョン管理サーバーに接続されていないチームがある場合は、分散モデルをサポートするバージョン管理システムを使用することをお勧めします。GITと他のいくつかはこのカテゴリに分類されます。私の知る限りTFSでは、ファイルを書き込み可能にするためにサーバーに接続する必要があります（バージョン2010で修正されましたか？）。

「1つのサイズですべてに収まる」というものがないことを示すことができたと思います。特定のブランチ管理のプロセスから始めて、要件を決定し、最後にニーズに最適なツールを選択します。多分それはTFSです、そうでないかもしれません。

フィーチャーごとに1つのブランチを推奨します。これは、出荷するフィーチャーと延期するフィーチャーを決定する際に大きな柔軟性を可能にするためです。

これがあなたの状況でうまく機能するかどうかは、VCSがブランチをどの程度適切に処理するか、さらに重要なことにマージに依存します。Git＆MercurialのようなDVCSでは、これは比較的簡単な作業です。SVNはそれほどではありません。TFSについては何度か読みましたが、TFSはなんとか回避できました。TFSに悩まされている場合は、ブランチごとに1つの機能に基づいて小さなパイロットリリースを実行し、マージがどの程度うまくいくかを確認してください。

まず、免責事項。私たちはあなたのチームが日々どのように機能しているかを認識していないので、あなたのソースを管理する最良の方法が何であるかを言うのは難しいです。

一般に、トランクで作業することをお勧めします。メジャーリリースごとにブランチします。これにより、リリースバージョンのバグ修正がブランチにマージされ、トランクにマージできるようになります。すべての開発者はトランクで作業し、コードを定期的にコミットします（最低1日に1回）。

新しいコードを定期的にマージすると、大規模な統合フェーズでコードの大きなチャンクをマージする手間が最小限に抑えられます。痛みを広げることで、あなたはそれを少なく感じるでしょう。チームメンバーがコードをコミットする頻度が高いほど、マージする必要が少なくなります-常に最新のソースを使用するためです。

私はTFS 2008/2010を使用したことがありませんが、さまざまなフォーラムで読んだことから、バージョン管理にTFSを使用することには多くの否定的な点があります。これにより、これまでのところTFSを明確に理解することができました。

私は現在SVNとGitを使用していますが、どちらも小規模なチームや独身のチームに適していますが、個人的には大規模なチームにSVNを推奨しません。

私はPlasticSCMに目を向けてきましたが、近いうちにそれを試すつもりです。

特定の質問に答えられなかったことをお詫び申し上げます。私の権限で許可されていれば、コメントを投稿していたでしょう。

gitは他のすべてのソース管理ソフトウェアを時代遅れにしていると思います。分岐とマージは簡単で、問題が発生した場合は阻止されますが、非常に頻繁なコミット、分岐、マージを促進することで、多くの問題を回避できます。各ユーザーはレポの完全なコピーを取得します（これはプルーニングできますが、私はかなり巨大なコードベースで作業しており、問題はありません）。したがって、自動バックアップのようなものがあります。コミット/プッシュ/プルは高速であり、最も重要なことの1つは、ファイル名と追跡の結合を解除することです。名前とパスを含むファイルデータは、ツリーノードによって参照されるデータBLOBであり、パスとは無関係です。これは安全であるだけでなく、SVNなどの特定の種類の「絶対に実行しない」問題は問題ではありません。これは、従来のハブ構成またはピアツーピアとして使用でき、同じセットアップでこれらの用途を自由に組み合わせることができます。文書化されていない挿入に対して暗号的に安全です。そして、それは非常に高速です。

ファイルをサーバーにバックアップしたり、サーバーに保存したりするよりも、ファイルサーバーにコミットしてプッシュする方が簡単なため、ドキュメントを追跡してコンピューター間で同期するために、いつも自宅で使用していることがわかりました。

欠点は、ソースコントロールで慣れ親しんでいるすべてのルールを微妙に破るので、学習曲線が少し急になることですが、学習曲線は短くて急です。

私たちが実際に実践し、私たちに大いに役立ついくつかのグッドプラクティス：

1）ローカルにファイルの書き込み可能なコピーがないことを確認し、編集のために常にチェックアウトします。（ローカルで作業する必要がある場合は、EODの前にソース管理にマージしてください。）

2）小さな重要なマイルストーンがあれば、定期的にファイルにラベルを付けます。

3）適切なチェックアウトまたはチェックインのコメントを付けます。これは、レビューするときに役立ちます。時には、バージョンを開いて比較する必要がない場合もあります。

チェックインを管理し、機能の競合を防ぎ、ソース管理で依存関係を適切に管理するにはどうすればよいですか？

それは、私のPOVから、2つの要素のタスクです。技術（good＆easy＆bullet-proofブランチ|マージなど）と管理（十分に確立されたポリシー「何」「いつ」「どのように」）の側から行う必要があります。ALMの2層または3層の分離コード：「安定」（単体テストに合格）、「不安定」（すべての機能が含まれているが、製品としてのアプリには統合後の質問がある/はい、発生する可能性がある）や「進行中の作業」。このようにして、適切なプロジェクトマネージャは、個別の開発者の作業の共通の干渉を減らすことができます。

TFS（私は使用せず、使用しており、使用しません）には、ソース管理の面でAFAIKの根本的な問題があります。私はここにジェームズ・マッケイのテキストのいくつかにリンクしています：

• Team Foundation Serverは、バージョン管理ツールのLotus Notesです。
• Team Foundationサーバーでのベースレスマージ–なぜですか？

ソースコントロールを操作するいくつかの異なる方法をわかりやすく簡潔に比較対照する、本当に素晴らしい最新の記事がここにあります：Source Control Done Right。

ソース管理を使用するための1つの戦略/ベストプラクティスはないと思います。長い間一緒に作業してきた成熟したチームは、人気のある「ベストプラクティス」に厳密に従っていなくても、この領域での「苦痛」ははるかに少なくなります。

どのツールについて...それはほとんど問題ではありません。本当に重要なのは、チームの全員が使用状況に関して同じページにいることです。これは、誰もがコード行がどのように管理され、彼らが何をすることが期待されているかを理解する必要があることを意味します。とにかく、実際には、通常、どのツールを使用するかについての選択肢はありません。使用しているものを最大限に活用してください。