5

支店間の親子関係の方向性は重要ですか？親子は、どちらが送信元でどちらが宛先であるかを識別する単なる抽象的な概念ですか、それとも一方向でしか実行できない特定の操作があるため、関係の方向が重要になりますか？

この質問の理由を説明するための背景情報を次に示します。

最近、新しい分岐戦略を実装し、この単純な設定を採用することにしました。

Dev -------------------------------
          \
      Main >-----------------------
                  \
        Production >---------------

これは私たちにとってはうまくいくようですが、私が読んだすべての推奨ガイダンスは、メインがルートであるべきだと示唆しています。したがって、代わりに次のようになります。

      Dev  >-----------------------
          /
Main ------------------------------
                  \
        Production >---------------

これは非常に似ていますが、明らかにMainとDevの間の親子関係が逆になっています。

Devをルートとして、Mainをその子として保持すると、どのような問題が発生するでしょうか。私が見ることができる唯一の問題は、メインから2番目のDevブランチを削除するかどうかです。これは、他のDevブランチとは反対の親子関係になりますが、これにはどのような意味があるのでしょうか。

ご覧いただきありがとうございます。さらに情報が必要な場合はお知らせください。

4

2 に答える 2

7

短期：短期的には、DEFはTFSの親のように見えますが、DEVはMAINの子であると全員に伝えます。

注：TFSでDEVブランチの親を変更できます...特定のチームの概念的な用語とプロセスのリスクが、TFSブランチの構造を修正するリスクよりも大きいと思われる場合はおそらくそうすべきです。

追加の考え

分岐方向はTFSにとって技術的に重要ではないことを繰り返します。しかし、混乱しやすい人間には十分注意してください。重要なのは、ブランチ間でマージを行う（または新しいブランチを作成する）すべての人がブランチ階層を明確に理解し、グループの公式用語とブランチ/マージプロセスに従うことです。

MAIN（別名ルートまたはトランクまたは祖先ブランチ）： 任意のブランチを「メイン」、「ルート」、「トランク」などのブランチとして任意に指定できます。これらの用語は、特に別の会社から採用された新しい開発者にとっては、一般的に同じ意味で使用されることを忘れないでください。マージとブランチを行うすべての人が、MAINブランチをチームのルート/トランクブランチとして扱うことを知っている限り、問題はありません。誰かにルートブランチから新しいリリースを作成するように何気なく依頼し、その人がroot = DEVブランチを決定した場合、問題が発生します（ブランチ図が「ルート」ブランチがDEVであるという考えを明確にサポートしている場合でも）。

マージの方向： FI（親から子への順方向統合）およびRI（子から親への逆統合）は、マージの方向を説明するために使用される最も一般的な用語です。FIRI（ "Fiery"）マージパターンをサブスクライブして、RIが親にマージされる前に、親のすべての変更が子にFIマージされることを確認します（すべての競合を解決し、必要に応じてテストします）。これは、親ブランチを子よりも安定させるのに役立ちます。現在、FIはDEV（親）からMAIN（子）までを意味するため、このアイデアはあなたの質問にとって重要です。あなたとすべてのブランチ/マージの人々が常にDEVが子ブランチであると偽ることができる場合は、「MAINブランチにマージする前にFIを実行しましたか？」と言うことができます。同様に、チームのブランチ/マージギルドは明示的に「重要：このガイド（および一般的な説明）では、技術的にTFSの親である場合でも、常にDEVブランチをMAINの子として扱います（2012年4月25日現在）。 DEVブランチについて話し合っています。

（チームで「マージアップ」や「マージダウン」などの他の用語をすでに使用している場合は、新入社員を含むすべての人がこれらの用語の意味を明確に理解している限り、問題ありません。（「アップ」と「 「ダウン」ブランチは、会社ごとに異なる方法で描画されるため、この用語は混乱を招く可能性があります。）

新しいブランチ： チームがMAINから新しいDEV_FeatureXブランチを作成することを決定した場合、それは子ブランチになります。（TFSは、親が1つだけの各ブランチを強制します...現在、2人の母親から生まれた子になることはできません:-)）同様に、リリースごとにブランチする場合（現在またはそれ以降）、これらのブランチはMAINブランチの新しい子になります。 。時間が経つにつれて、これは

コンピューターは人間よりもはるかに少ない頻度で間違いを犯すことを忘れないでください。楽しみ！-ゼファン

于 2012-04-26T20:18:01.567 に答える
1

ブランチの方向は関係ありません。特定のブランチを別のブランチに「基づいて」作成し、関係を作成することもできますが、どちらの方向からもまったく同じメリットを得ることができます。

唯一の違いはどこかにあり、それは大きな違いです。

生産が開発に基づいているメインに基づいている最初のグラフを見てみましょう：

  • DevからMain、MainからDev、MainからProd、ProdからMainに効率的にマージできます。
  • しかし、DevからProdまたはProdからDevへのマージは本当に苦痛になります。

なんで ？ソースブランチとデスティネーションブランチが直接関連している場合、スリーウェイマージのメリットがあります。ソースブランチとデスティネーションブランチが間接的に関連している場合（たとえば、DevとProd）、TFSは双方向のマージしか行えないため、さらに多くの競合が発生します。

スリーウェイマージの詳細については、ウィキペディアのリンクをご覧ください。

要約すると、両方のグラフはTFSに関して同じであり、選択するブランチモデルの問題です。

于 2012-04-25T13:09:59.603 に答える