20

TFS で直接の親または子ではないブランチにマージすることは可能ですか? これは私が使用中に経験したことなので、答えはノーだと思います。ただし、承認サイクルが異なる可能性があるさまざまな機能に取り組んでいる場合 (つまり、機能 1 が機能 2 の前に承認される可能性がある場合) には、これが非常に役立つ場合があります。次のフルバージョンの前にリリースできるように、一部の機能を以前のブランチにマージする必要がある製品ブランチがある場合、これは非常に困難になります。

私たちの現在のブランチ戦略は、トランク (またはメインラインと呼ぶ場合) で開発し、ブランチを作成して安定させ、本番環境にリリースすることです。このブランチは、ホットフィックスやその他のものを作成するために使用できますが、メインラインは今後の機能に分岐できます。

上記のようなシナリオを軽減するために、どのような手法を使用できますか?

4

7 に答える 7

19

分岐構造をどのようにセットアップしたかを再検討したいというHarpreetに同意します。ただし、このタイプのマージを本当に実行したい場合は、ベースレス マージと呼ばれるものを使用できます。tfs コマンド プロンプトから実行します。

Tf merge /baseless <<source path>> <<target path>> /recursive

根拠のないマージに関する追加情報は、ここにあります

また、このドキュメントは、tfs 分岐構造を構築する際に非常に貴重であることがわかりました Microsoft Team Foundation Server Branching Guidance

于 2008-09-09T21:06:57.570 に答える
8
tf.exe merge /recursive /baseless $/TeamProject/SourceBranch $/TeamProject/TargetBranch
于 2008-09-09T21:00:26.167 に答える
2

分岐戦略を再検討することをお勧めします。どのように生産ブランチを取得しますか? 開発ブランチからのすべてのコードをマージし、回帰テストを行ってから、修正のために本番ブランチを作成していますか? それとも、トランク上で開発を行ってから、安定化してリリースするために本番ブランチを作成していますか? 2 番目の方法では、説明しているタイプの問題が発生します。最初のアプローチを使用している場合-トランクは、テストされたブランチ上に構築されてからマージされたもの専用であると想定されており、これに遭遇する頻度ははるかに少なくなります. このアプローチでまだこの問題が発生している場合は、開発作業が非常に大きく、分岐と昇格のレイヤーを使用した比較的複雑な分岐戦略が必要な可能性があります。

于 2008-09-09T20:38:11.897 に答える
1

知る限り、ブランチが同じ元のフォルダーから作成されている限り、これを行うことができます。

  • トランク/
  • branch/ -/feature1 (トランクから分岐) -/feature2 (トランクから分岐)

これを行うと、feature1 と feature2 の間でもマージできるはずです。

TFSでの分岐/マージの経験から、もっと欲しいと思っています。SVNさえあればいいのに。

于 2008-09-09T20:33:24.607 に答える
1

はい、ベースレス マージを実行できますが、コマンド ライン (tf.exe) からのみ実行できます。

于 2008-09-09T21:00:32.780 に答える
1

TFS では、親/子ではないブランチとマージすることができます。これはベースレス マージと呼ばれます。次のリンクを参照してください。

MSDN から

CodePlex 経由で TFS チームから

私たちは通常、開発ブランチで大きな変更や不安定化する変更を行います。いずれかの製品のメジャー リリースが近い場合、ほぼすべての変更がブランチで行われます。

于 2008-09-09T21:05:50.647 に答える
0

私は TFS の専門家ではありませんが、兄弟をマージできると思いますし、根拠のないマージではないと思います。

機能 (ブランチ名 "feature") のためにメイン ブランチ (ブランチ名 "main") から分岐した後、メイン ブランチ (ブランチ名 "dev") からも分岐したブランチでいくつかの作業が必要になりました。フィーチャー ブランチと dev ブランチは、どちらも同じ親に由来するため、兄弟と見なします。機能を dev にマージすると、すべてのファイル (14000) がマージとしてマークされ、一部はマージ、編集としてマークされました。キャンセルできませんでした (Visual Studio がハングアップするだけだった) ため、マージを受け入れました。次に、dev を main にマージし、main を feature にプルしました。再び 14000 個のファイルがマージ対象としてマークされました。私は本当に動揺し、これが続くのではないかと心配しました。

この時点で、テスト プロジェクトを実行しました。main をセットアップし、main から分岐した dev と feature をセットアップします。上記の手順を繰り返して同じ結果を得ました。メインからフィーチャーへのマージが完了すると、その後のすべてのマージで編集済みのファイルのみが表示されました。

ちょっとしたテストの後、メインからフィーチャーへのマージを完了しました。テストと同じように、マージは編集されたファイルのみを表示するようになりました。開発から機能、機能からメイン、メインから開発などに移動できます。

ブランチのすべてのファイルの日付が変更されたときに気付きました。多分これは問題ですか?

于 2019-05-31T15:07:14.187 に答える