1

私の唯一の同僚は数週間前に去りました。今ではすべてをマージして、新しい開発者と私のためのベースライン作業環境を作成する必要があります。以前の同僚は、TeamFoundationServerに関連するほとんどの管理を行っていました。

私の現在の構造は、4つのブランチとバグブランチで構成されています。ブランチAとブランチBは、中央開発ブランチ（ブランチC）から分岐した個別の開発ブランチでした。中央開発ブランチ（ブランチC）は、メインブランチ（ブランチD）から派生しました。Bugsブランチは私の問題に影響を与えないはずなので、名前は付けられません。

少し前にすべてをマージしようとしたときにいくつかの間違いを犯したため、ブランチA、ブランチB、およびブランチCの動作バージョンに戻しました。

ブランチA、B、およびCIの作業バージョンを取得したので、ブランチA / BをCにマージし始めたいと思います。技術的に最新のコードを使用していないため、また古いバージョンに戻ったため、わかります。 「バージョンタイプ」を「最新バージョン」以外に変更する必要があるかもしれません。

バージョンタイプ

バージョンタイプを変更する必要がありますか、それとも最新バージョンのままにしてマージを続行する必要がありますか？

4

2 に答える 2

2

質問を読むと、ブランチ構造は次のようになります。

D (Main) 
--C (Dev)
----A (Developer1)
----B (Developer2)
--?Bugs

簡単な用語 (短い表記法を使用できるようにするため):

  • FI = 前方統合 (親ブランチから子ブランチへ)
  • RI = 逆統合 (子ブランチから親ブランチへ)
  • ブランチ C はブランチ A とブランチ B の親です。A と B はC の子です。

最初の質問から、次の状態が存在するように聞こえます。

  1. A と B の両方に、C に RI されていない変更があります。
  2. C、B、および A での以前のマージ試行を元に戻しました。
  3. (?) (tf.exe ロールバックを使用して) 各ブランチでロールバックをコミットしたため、各ブランチから「最新のものを取得」すると、失敗したマージ バージョンではなく、作業中のバージョンが得られます。

これが私の推奨事項です：

  1. A、B、および C の安定したバージョンにロールバックします (まだ行っていない場合)。
  2. C->A、テスト、A->C、検証 OK。
  3. C->B、テスト、B->C、検証 OK。

詳細：

  1. A、B、および C の作業バージョンへの tf ロールバック (まだ行っていない場合)

  2. C->A からの FI (C から A)

    • 可能なすべての競合を解決する

    • 保留中のマージ のシェルブセットを作成します

    • マージが成功し、すべての C がすべての A で動作することを確信できるまで、A でテストします。
    • マージの変更を A にコミットします。

  3. AからCへのRI、

  4. 手順 2 と 3 を C->B、B->C の順に繰り返します。

ヒント:「A」は、変更が最も簡単または最も重要な開発者ブランチです。

* 以前の「安定した」バージョンにロールバックするために変更をコミットしない場合は、おそらくバージョン タイプ オプションを使用する必要があります...しかし、3 つのブランチすべてにロールバックが必要な変更がある場合は、少なくともロールバック c が必要です。 Aの以前のバージョンをマージします。個人的には、3つのブランチすべてを最新のものにして、続行したい作業バージョンにすることをお勧めします。(マージは、特定の変更セットにマージする必要がなくても十分にトリッキーです)。

あなたが説明したシナリオは非常に一般的ですが、最適ではありません。A と B の両方が (毎回 FI とテストを行った後) C に頻繁にマージしている場合、マージ タスクははるかに小さくなります。

前進する

将来のマージの苦労を軽減するためのいくつかの推奨事項があります。

  1. 日常業務では、開発者は保留中の変更にTFS シェルフセットを使用してから、共通の開発ブランチに直接チェックインできます。フル ブランチは、分離が必要な場合にのみ必要です (競合する変更に同時に取り組んでいる場合や、複数の開発者が重大な変更に取り組んでいる場合など)。
  2. 他の開発者の変更から分離する必要がある場合にのみ、共通の開発者ブランチから子ブランチを作成します。たとえば、両方の開発者が作業する必要がある重大な変更を実装している場合、「機能」ブランチを作成できます。一方または両方の開発者は、開発者ブランチを不安定にすることなく機能に取り組むことができ、その後すぐに開発ブランチにマージします。特徴は安定しています。
  3. 親から子への FI マージが頻繁に行われます。そうしないと、マージの調整が非常に難しくなります。

チームの規模に対してブランチが多すぎる可能性があります (並行して存在してはならない並列機能がある場合を除きます)。正気度は、メインから離れたブランチの数に応じて減少します。すべての開発者が単一の Dev ブランチ (C) から作業し、必要な場合にのみ短期間の機能ブランチを作成します (機能が安定して Dev ブランチにマージできるようになったらすぐにブランチを閉じます)。

TFS 分岐ガイドは、適切な分岐パターンの図と、今後のニーズにより適したさまざまなパターンを含む多くのガイダンスの優れたリソースです。

楽しみ！-ゼファン

于 2011-06-28T15:42:34.090 に答える
1

A と B が C から作成された開発ブランチ (つまり、新しいコード/機能がメイン開発に個別に追加されるブランチを意味します) であり、それらが寿命に達した場合、C に再統合する必要があります。 A または B の最新バージョンを C にマージするのは正しいことです。

于 2011-06-27T22:28:39.687 に答える