リリース サイクルでは、複数の TFS ブランチを維持しています。現在のプロセスは、ユーザー ストーリーが完了したときに、変更セットを WIP ブランチからテスト ブランチにチェリー ピックすることです。
私は、git-tf がこのように複数のリモート ブランチを操作できるかどうか、またマージをチェックインできるのか、新しいコードのように見えるコードをチェックインできるのかを知りたいと思っています。
ここでこれについての議論がありました：
また、git-tfs は、VS を直接使用する他のユーザーとはうまく機能しないことが言及されていました。それが git-tf に当てはまるかどうかは誰にもわかりませんか?
現時点では、git-tfは TFS ブランチを git ブランチで表しておらず、マージをどちらの方向にも変換しません。つまり、マージをチェックインせず、TFS マージの結果を git マージとして表示しません。2 つのアーキテクチャのマージにはかなり根本的な違いがあるため、これは一種の重要な問題です。
TFS は git マージとしてマージします。
git では、2 つのコミットをマージして、最終的に結果のコミットを作成します。TFS は、マージ ソースとターゲット変更セットを選択するという点で似ていますが、マージ ソースは変更セットである必要はありません。ラベル、ワークスペースのバージョン、日付などに基づいてマージできます。つまり、最終的に複数の異なる変更から異なるファイルをマージすることになる可能性があります。これは簡単に解決できる問題です (最終的には、クレイジーなタコのマージとして表されると思います)。
解決が難しい問題は、TFS ブランチに基づいて git ブランチを作成することです。これはセットアップの問題です。つまり、どのブランチが必要ですか? それらのすべて？それらのいくつか？答えが「すべて」の場合、最初のクローン作成時に簡単にセットアップできます。しかし、私にとっては、何百ものブランチがあり、初めてセットアップするのはかなり費用がかかります。答えが「それらのいくつか」である場合は、クローンを作成するときにそれらすべてを指定する必要があります。そうしないと、後で厄介な方法で git 履歴を書き換えることになります。
git は TFS のマージに合わせてマージします。
git では、ブランチは一種の一時的なものです。1b4cafこれは実際にはツリー内のノードへのポインタにすぎません...「 commitはかつて branch にあった」という長命の状態はありませんbranch。masterTFS ブランチを指すgitブランチと、 を指す$/Proj/main別の git ブランチがあるとします。git では、 にマージします。問題ありません。この時点で、のコミットには の親があります。しかし、ブランチで何かを変更し始めると、すぐに判断が難しくなる可能性があります。test$/Proj/testtestmainmainHEADtestHEADtest
さらに、現在git-tf、単一の git ブランチを TFS サーバー パスにマップします。マージ チェックインの場合、一度に複数のブランチにチェックインする必要があります。にいくつかのコミットをmaster行い、いくつかのコミットを行ってからtest、それぞれの をマージしたとしHEADます。ここで、各 TFS ブランチにいくつかのコミットをチェックインしてから、マージを行う必要があります。これは必ずしも難しいことではありませんが、現在のやり方から非常に根本的に逸脱してgit-tfいます。
これは決して不可能な問題ではありませんが、巧妙なエンジニアリングと多くの巧妙なテストが必要になります。しかし、それはまだありません。