73

私が働いている会社は、現在の分岐モデルに問題を抱え始めています。コミュニティはどのような種類の分岐戦略にさらされているのでしょうか?

さまざまな状況に適したものはありますか? あなたの会社は何を使っていますか？それらの長所と短所は何ですか??

4

12 に答える 12

54

これは、私が過去に使用して成功した方法です。

/trunk - ブリーディング エッジ。コードの次のメジャー リリース。いつでも機能する場合と機能しない場合があります。

/branches/1.0、1.1 など。コードの安定したメンテナンス ブランチ。バグを修正し、新しいリリースを安定させるために使用されます。メンテナンス ブランチの場合は、(該当する場合) コンパイルして、いつでも QA/出荷の準備ができている必要があります。安定化ブランチの場合は、コンパイルして機能を完成させる必要があります。新しい機能を追加したり、リファクタリングしたり、コードを整理したりする必要はありません。プレフィックスを追加して、安定化ブランチとメンテナンス ブランチを示すことができます。

/branches/cool_feature. トランク (またはメンテナンス ブランチ) になるかどうかわからない、非常に実験的または破壊的な作業に使用されます。コードのコンパイル、動作、またはその他の正常な動作についての保証はありません。メインライン ブランチにマージする前に、可能な限り最小限の時間継続する必要があります。

/tags/1.0.1、1.0.2、1.1.3a など。パッケージ化および出荷されたリリースのタグ付けに使用されます。決して変わることはありません。タグはいくつでも作成できますが、それらは不変です。

于 2008-08-29T19:17:18.520 に答える
7
  1. アクティブな開発のための1つのブランチ（専門用語に応じて/ mainまたはmaster）
  2. メンテナンスリリースごとに1つのブランチ->非常に小さな修正のみを受け取りますが、すべての主要な開発は/mainに送られます
  3. 新しいタスクごとに1つのブランチ：Bugzilla / Jira/Rallyのすべての新しいエントリで機能する新しいブランチを作成します。頻繁にコミットし、インチペブルチェックインを使用して変更を自己文書化し、終了して十分にテストされた場合にのみ、変更を「親」ブランチにマージします。

より良い説明については、このhttp://codicesoftware.blogspot.com/2010/03/branching-strategies.htmlをご覧ください。

于 2009-04-27T22:41:35.413 に答える
7

リポジトリは次のようになります。

/trunk
/branches
/sandbox
/vendor
/ccnet

/trunkは、標準的な最先端の開発です。CI を使用しているため、常にテストをビルドしてパスする必要があります。

/branches これは、「承認された」大きな変更を入れる場所です。つまり、トランクに入れることがわかっているものですが、いくつかの作業が必要であり、CI を壊す可能性があります。また、独自の CI プロジェクトを持つメンテナンス リリースにも取り組んでいます。

/sandbox 各開発者には独自のサンドボックスと共有サンドボックスがあります。これは、「製品に LINQ プロバイダーを追加してみましょう」など、実際の作業を行っていないときに行うタスクです。最終的にトランクに入るかもしれませんが、そうでないかもしれませんが、そこにあり、バージョン管理されています。ここには CI はありません。

/vendor コンパイルするが保守するコードではないプロジェクトの標準ベンダー ブランチ。

/ccnet これは CI タグです。CI サーバーのみがここに書き込むことができます。後から考えると、これを CI や BUILDS などのより一般的な名前に変更するように指示されていたはずです。

于 2008-09-12T16:56:08.460 に答える
6

まず最初に：KISS（単純に愚かにしてください！）

/ブランチ
  /RB-1.0（* 1）
  /RB-1.1（* 1）
  /RB-2.0（* 1）
/ tags
  /REL-1.0（またはお使いのバージョンが1.0.0.123 * 2など）
  /REL-1.1
  /REL-2.0
/トランク
  クールな新機能を備えた現在の開発;-)

* 1）バージョンを保守可能に保つ-たとえば、必要に応じて、および/または必要に応じてトランクにマージできるサービスパック、ホットフィックス、バグ修正）* 2）major.minor.build.revision

親指のルール：

  1. タグフォルダをチェックアウトする必要はありません
  2. リリースブランチでのコーディングはごくわずかです（マージが簡単になります）-コードのクリーンアップなどはありません。
  3. タグフォルダにコーディングしないでください
  4. 具体的なバージョン情報をソースファイルに入れないでください。プレースホルダーまたは0.0.0.0を使用します。これは、ビルドメカニズムがビルドしているバージョン番号に置き換えられます。
  5. サードパーティのライブラリをソース管理に入れないでください（STL、MFCなどのライブラリをSVNに追加することもありません;-)）
  6. コンパイルするコードのみをコミットする
  7. ハードコードされたパス（絶対パスと相対パス）の代わりに環境変数を使用することをお勧めします

--hfrmobile

于 2011-01-05T14:48:30.347 に答える
3

Gnat は、分岐戦略で見つけることができるさまざまなアドバイスについて、この優れた内訳を書いています。

分岐戦略は 1 つではありません。

  • あなたのチームの規模
  • 製品とライフサイクル期間
  • 使用しているテクノロジー (Web、組み込み、Windows アプリ)
  • Git、TFS、Hg などのソース管理

Jeff Atwood の投稿は、多くの可能性を分析しています。追加するもう 1 つの点は、プロモーションの概念です (Ryan Duffield のリンクから)。このセットアップでは、dev ブランチ、test bracnh、および release ブランチがあります。リリース ブランチに到達してデプロイされるまで、コードを昇格させます。

于 2011-10-19T11:10:26.497 に答える
3

私がここで目にしていない代替案は、「Branch on Change」哲学です。

トランクを「ワイルド ウェスト」ではなく、「現在のリリース」にした場合はどうなりますか? これは、Web サイトなど、一度にリリースされるアプリケーションのバージョンが 1 つしかない場合にうまく機能します。新しい機能またはバグ修正が必要な場合、その変更を保持するためにブランチが作成されます。多くの場合、これにより修正を個別にリリースに移行することができ、カウボーイ コーダーが意図しない機能を誤ってリリースに追加することを防ぎます。(多くの場合、それはバックドアです - 「開発/テスト用」)

Ben Collins からの指示は、どのスタイルが自分の状況に適しているかを判断するのに非常に役立ちます。

于 2008-09-15T17:37:47.647 に答える
3

リリースが最終 QA の準備ができたら分岐します。QA プロセス中に問題が発見された場合、バグはブランチで修正され、検証されてからトランクにマージされます。ブランチが QA に合格したら、リリースとしてタグ付けします。そのリリースのすべてのホットフィックスもブランチに対して実行され、検証され、トランクにマージされてから、別のリリースとしてタグ付けされます。

フォルダー構造は次のようになります (1 つの QA 行、2 つのホットフィックス リリース、およびトランク)。

/支店

/REL-1.0

/タグ

/REL-1.0

/REL-1.0.1

/REL-1.0.2

/トランク

于 2008-08-29T19:02:08.917 に答える
3

ワイルド、ワイルド、ウェスト スタイルの git-branch を使用します。慣習によって定義されたよく知られた名前を持つブランチがいくつかありますが、私たちの場合、企業プロセス ポリシーの要件を満たすためには、実際にはタグの方が重要です。

あなたが Subversion を使用していることを以下で見たので、おそらくSubversion Bookの分岐に関するセクションを確認する必要があると思います。具体的には、Branch MaintenanceおよびCommon Branch Patternsの「リポジトリ レイアウト」セクションを参照してください。

于 2008-08-29T19:23:20.160 に答える
2

現在、進行中のメンテナンス用のブランチが 1 つと、「新しいイニシアチブ」用のブランチが 1 つあります。これは、単に「将来いつリリースされるかわかりません。」という意味です。また、2 つのメンテナンス ブランチが進行している場合もあります。1 つは現在運用中のものに対する修正を提供するもので、もう 1 つはまだ QA 中のものです。

私たちが見た主な利点は、ユーザーのリクエストや緊急事態により迅速に対応できることです。すでにチェックインされている可能性のある余分なものをリリースすることなく、本番環境のブランチで修正を行い、リリースすることができます。

主な欠点は、ブランチ間で多くのマージを行うことになり、何かが見落とされたり、誤ってマージされる可能性が高くなることです。これまでのところ、それは問題ではありませんが、心に留めておくべきことです。

このポリシーを制定する前は、通常、すべての開発をトランクで行い、コードをリリースするときにのみ分岐していました。その後、必要に応じてそのブランチに対して修正を行いました。それはより単純でしたが、柔軟性がありませんでした。

于 2008-08-29T18:42:37.293 に答える
1

私たちが仕事で従う哲学は、サイトに大きな損害を与えることなく、トランクをいつでも押すことができる状態に保つことです. これは、トランクが常に完璧な状態であると言っているわけではありません。もちろん、そこにはバグがあります。しかし重要なのは、絶対に壊れたままにしないことです。

追加する機能がある場合は、分岐します。設計変更、分岐。「ああ、トランクでこれを行うだけで、それほど時間はかからないだろう」と思ったことが何度もありましたが、5時間後、物事を壊しているバグを理解できませんでした。分岐してほしかった。

トランクをきれいに保つと、バグ修正をすばやく適用してプッシュする機会が得られます。便利に分岐した壊れたコードについて心配する必要はありません。

于 2008-08-29T18:52:40.747 に答える
0

Subversion については、Ryan Duffield のコメントに同意します。彼が参照している章は、どのシステムを使用するかについての優れた分析を提供します。

私が尋ねた理由は、Perforce が SVN または CVS からブランチを作成するためのまったく異なる方法を提供しているからです。さらに、分岐に関する独自の哲学を提供するすべての DVCS があります。分岐戦略は、使用しているツールによって決まります。

参考までに、Svnmerge.pyは SVN でのブランチのマージを支援するツールです。頻繁に (10 ～ 30 回ごとに) コミットする限り、非常にうまく機能します。そうしないと、ツールが混乱する可能性があります。

于 2008-08-29T18:52:44.617 に答える
0

どの分岐パターンを選択しても、次のように分岐をバイナリ ツリー形式に保つようにしてください。

   trunk - tags
     |
    next
   /  \  \
bugfix  f1  f2
        /   \  \          
       f11    f21 f22
  • 子ノードは、直接の親とのみマージする必要があります。
  • ブランチ全体のみを親ブランチとマージするように最善を尽くしてください。ブランチ内のサブフォルダーをマージしないでください。
  • ブランチ全体からのみマージして選択する限り、必要に応じてコミットを選択できます。
  • 上の図の次の分岐は説明のためのもので、必要ない場合があります。
于 2010-03-17T09:27:35.827 に答える