3

単純にするために、月に 1 回というリリース モデルがあります。したがって、通常は次のようになります。

Jan -> trunk
       trunk -> Feb
       trunk <- Feb
Mar <- trunk 
Mar -> trunk
       etc

トランクを放棄して、次のようなモデルを提供することを検討しています。

trunk -> Jan
  Jan -> Feb
  Feb -> Mar
  Mar -> Apr
  etc

マージしてトランクに戻すことはありません。作業は 2 月ブランチで行われますが、緊急の修正は 1 月ブランチで行われ、2 月のコードベースにマージされます。

これは、はるかに少ないマージを含め、多くの利点を提供しているようです. 理想的には経験から、明らかな欠陥/欠点を見つけた人はいますか?

4

3 に答える 3

5

これは多くの利点を提供するようです

何も見えませんが、少なくとも1つの頭痛を検出できます

はるかに少ないマージを含む

間違い。両方のワークフローでのパッチのフォワードポーティングには、同じ量のマージがあります

履歴書：

SubversionのすべてのURLには同等の権限があり、メインラインとしてパス/ trunkを使用するのは単なる便宜であり、無視してかまいません。ただし、サイドバックを忘れないでくださいsvn up。現在の月のリビジョンよりも古いものを1つ作成するのではなく、 svn switch & svn up（切り替え前にこのリビジョンのURLを特定してください。ログをリストに追加してください）

于 2013-02-13T12:46:32.363 に答える
1

分岐が早すぎて、その分岐を放棄しようとしているようですが、それに気づいていません。

通常のトランクベースのワークフローでは、"Jan" が解放されるとすぐに "Jan" の分岐を行います。その後、トランクの作業を続け、「Feb」として「Feb」のブランチがリリースされます。つまり、トランク モデルでは、リリース ポイントへの分岐を延期します。機能ブランチまたはホットフィックス以外のものをトランクにマージしていることに気付いた場合、ワークフローは壊れています。リリースブランチでかなりの作業を計画するのは間違っています。トランク ブランチとフィーチャー ブランチは基本的な作業用です。リリース ブランチは緊急用です。

新しいモデルは優れていますが、確立された命名規則を次のように維持できます。

 trunk
 trunk -> Jan   /* Release */
 trunk <- Jan   /* Hotfix */
 trunk -> Feb
 trunk -> Mar
 trunk -> Apr

これはトポロジー的にトランクなしモデルと同等であることに注意してください。

trunk                     Jan
 +----------- Jan          +------------   
 +------- Feb  |       Feb +--------   |
 +--- Mar  |   |       Mar +----   |   |
 |     |   |   |       Apr |   |   |   |
 |     |   |   |           |   |   |   |
trunk Mar Feb Jan         Apr Mar Feb Jan

ただし、トランクのないモデルでは、トランク モデルで「trunk」という名前の垂直パスの名前を常に変更しています。ほとんどの場合、誰もがトランクに取り組んでいるため、LazyBadger が既に述べたように、ネーミングは多くのスイッチを介して邪魔になります。

のコストsvn switchは確かに高くありませんが、忘れられたもののコストは高くなりますsvn switch。ある時点で、誰かがMar休暇から戻った後Apr、現在のブランチであるときに誤って作業することがあります。次に、その問題を検出し (QA)、コードを にマージしてApr元に戻す必要がありMarます。通常の作業を で行った場合、は常に新しい作業の良い点であるtrunkため、問題は発生しません。trunk

于 2013-02-13T13:28:18.493 に答える