現在、ソース管理としてTFSを使用するプロジェクトに取り組んでいます。私は機能の一部を実装している最中ですが、外部のリソースによって実行される必要がある作業によってブロックされています。機能が完全ではないため、ビルドを中断せずに変更をチェックインすることはできません。ですから、ブロッキング作業が終了するまで数日待つのではなく、いくつかの欠陥に取り組みたいと思います。
他の変更とは別にこの作業を行うために、作成した2番目のワークスペースで欠陥を処理しています。
2つ目のワークスペースを使用して変更を分離した後、同僚から、変更を棚上げしない理由を尋ねられました。棚について読んだ後、これは私のような状況に適した解決策のようです。 私の質問は、もしあれば、どのような状況で複数のワークスペースを作成し、どのような状況で棚を使用する必要があるかということです。棚 についての投稿がいくつかありますが、ワークスペースについてはあまりわかりません。
ちなみに、ここで2つ目のワークスペースを作成するというアイデアを思いつきました。
新しいブランチがおそらく最善の方法でしょう。しかし、あなたの質問に答えるために、シェルフと単にdiffernetワークスペースを使用することの主な違いの1つは、シェルフするときにコードをTFSにプッシュバックするため、バックアップされることです。ワークスペースにあるものはすべて、マシンにあるものと同じです。それを失うと、それはなくなります。
私の店では枝分かれを多用しているので、棚の用途はあまり見かけません。
しかし、私にとって非常に便利なケースが1つ見つかりました。それは、2台の異なる開発マシン（1台はオフィス、もう1台は自宅、VPN経由で接続）間を行き来することがよくあることです。私が何かに取り組んでいて、それを家から仕事に、またはその逆に移したい場合、私はしばしば棚を使用します。あるマシンからそれを棚上げし、他のマシンからそれを外すことができます。私は変更の最中にこれを行い、チェックインするとビルドが中断したり、他の開発者に割り込んだりします。
ここでは、2 つのまったく異なる概念について話しています。コードを保留すると、TFS に保存されますが、特定のブランチにはチェックインされません。別のワークスペースを作成すると、開発用コンピューターに新しいローカル フォルダーが設定され、そこのブランチにファイルが保存されます。チェックインを行うと、競合が発生する可能性があります。
コードの新しいブランチを作成してみませんか。コードの独自のブランチにチェックインしているため、他の人の変更を踏むことなく、そのブランチで作業してチェックインできます。次に、自分の変更が完了し、他の人がメイン ブランチでの変更を完了したら、自分の変更をメイン ブランチにマージできます。
棚は理想的なオプションです。Shelving を使用すると、通常のビルド以外で TFS に一括で変更を加え、後でそれらを名前で取得できます。複数のワークスペースは、あなたがしていることの解決策ではありません。複数のワークスペースは、製品の異なるバージョンを管理していて、それらで作業する必要がある場合に適しています。たとえば、4.0 と 5.0 の製品があり、両方のバージョンにセキュリティ フィックスを適用する必要があるとします。シェルビングは、変更を加えたいがすぐにコミットしたくない場合に最適です。