ブランチとトランクのどちらで開発を続けますか？[閉まっている]

定期的にリリースされるソフトウェア製品を開発しているとします。ブランチとマージに関するベストプラクティスは何ですか？定期的なリリースブランチを公開して（または顧客が誰であっても）スライスし、トランクでの開発を継続するか、トランクを安定版と見なし、定期的にリリースとしてタグ付けし、ブランチで実験的な作業を行います。トランクは「ゴールド」または「サンドボックス」と見なされていると思いますか。

大規模な商用アプリケーションで両方の方法を試しました。

どの方法がより良いかという答えは、あなたの正確な状況に大きく依存しますが、私の全体的な経験がこれまでに示してきたことを書きます。

全体的に良い方法（私の経験では）：トランクは常に安定している必要があります。

この方法のガイドラインと利点は次のとおりです。

• 各タスク（または関連するタスクのセット）を独自のブランチにコーディングすると、これらのタスクをマージしてリリースを実行するときに柔軟性が得られます。
• トランクにマージする前に、各ブランチでQAを実行する必要があります。
• 個々のブランチでQAを実行することにより、バグの原因を簡単に正確に把握できます。
• このソリューションは、任意の数の開発者に対応できます。
• 分岐はSVNではほとんど瞬時の操作であるため、この方法は機能します。
• 実行する各リリースにタグを付けます。
• しばらくリリースする予定のない機能を開発し、それらをいつマージするかを正確に決定できます。
• 行うすべての作業について、コードをコミットするという利点があります。トランクだけで作業する場合は、コードをあまりコミットせず、したがって保護されておらず、自動履歴がない状態に保つでしょう。

反対のことをしようとしてトランクですべての開発を行うと、次の問題が発生します。

• 毎日のビルドで常に発生するビルドの問題
• 開発者がプロ​​ジェクトの他のすべての人々に問題を犯したときの生産性の損失
• 最終的に安定版を入手する必要があるため、リリースサイクルが長くなります。
• 安定性の低いリリース

ブランチを安定させ、トランクを開発サンドボックスとして維持しようとすると、必要な柔軟性がなくなります。その理由は、安定版リリースに含めるものをトランクから選択することはできないからです。それはすでにトランク内ですべて一緒に混合されます。

特にトランクですべての開発を行うと言えるのは、新しいプロジェクトを開始するときです。状況によっては他の場合もあるかもしれません。

ちなみに、分散バージョン管理システムの方がはるかに柔軟性が高いので、hgまたはgitに切り替えることを強くお勧めします。

私は両方の手法を使用してきましたが、トランクで開発し、リリース時に安定したポイントから分岐することが最善の方法だと思います。

あなたが持っていると言って反対する上記の人々：

• 毎日のビルドで常に発生するビルドの問題
• 開発者がプロ​​ジェクトの他のすべての人々に問題を犯したときの生産性の損失

おそらく継続的インテグレーション技術を使用していません。

1日ごとに、たとえば1時間に1回程度、いくつかのテストビルドを実行しないと、開発のペースをすぐに妨げるこれらの問題が発生する可能性があります。

日中にいくつかのテストビルドを実行すると、メインコードベースの更新がすぐに折りたたまれ、他のユーザーが使用できるようになります。また、誰かがビルドを壊した場合は、帰宅する前に修正できるように日中に警告します。

指摘したように、リグレッションテストを実行するためのナイトリービルドが失敗したときに壊れたビルドを見つけることは、まったく愚かであり、すぐに物事を遅くします。

Martin Fowlerの継続的インテグレーションに関する論文を読んでください。私たちは、Posix shの約2,000ラインで主要なプロジェクト（3,000kSLOC）のために独自のシステムを導入しました。

私は「リリースブランチ」アプローチを採用する傾向があります。トランクは揮発性です。リリース時期が近づいたら、リリースブランチを作成します。これはより慎重に扱います。それが最後に完了したら、リポジトリの状態にラベル/タグを付けるので、「公式」リリースバージョンがわかります。

私にはそれを行う他の方法があることを理解しています-これは私が過去にやった方法です。

両方とも。

トランクは開発の大部分で使用されます。ただし、トランクへのチェックインによって障害が発生しないように最善の努力が払われることが予想されます。（自動ビルドおよびテストシステムによって部分的に検証されています）

リリースは独自のディレクトリで維持され、バグ修正のみが行われます（その後トランクにマージされます）。

トランクを不安定な状態または動作しない状態のままにする新しい機能は、それ自体の個別のブランチで実行され、完了時にトランクにマージされます。

私は、複数のアジャイルチームのバージョン管理で Henrik Knibergが説明したアプローチを気に入って使用しています。Henrikは、複数のチームがあるアジャイル環境でバージョン管理を処理する方法（従来の環境でも単一のチームでも機能します）を説明するのに優れた仕事をしました。自己説明です）以下：

私はそれが好きです：

• それは簡単です：あなたは写真からそれを得ることができます。
• マージやコンフリクトの問題が多すぎることなく、うまく機能します（そしてスケーリングします）。
• 「アジャイルの精神で」いつでも「作業ソフトウェア」をリリースできます。

そして、十分に明確ではなかった場合に備えて、開発は「作業ブランチ」で行われ、トランクはDONE（解放可能）コードに使用されます。詳細については、複数のアジャイルチームのバージョン管理を確認してください。

トランクを安定させ、ブランチですべての作業を行う開発プロセスに関する優れたリファレンスは、DivmodのUltimate Quality Development Systemです。簡単な要約：

• すべての作業にはチケットが関連付けられている必要があります
• チケットの作業が行われたチケットごとに新しいブランチが作成されます
• そのブランチからの変更は、別のプロジェクトメンバーによるレビューなしにメインライントランクにマージされません。

彼らはこれにSVNを使用しますが、これはどの分散バージョン管理システムでも簡単に実行できます。

あなたの2番目のアプローチ（たとえば、リリースにタグを付けて、トランクが安定していることを考慮して、ブランチで実験的なことを行う）が最良のアプローチだと思います。

ブランチがブランチの時点でシステムのすべてのバグを継承することは明らかです。トランクに修正が適用されている場合、ブランチを一種として維持している場合、すべてのブランチに1つずつ移動する必要があります。リリースサイクルターミネータ。すでに20のリリースがあり、最初のリリースにまで遡るバグを発見した場合、修正を20回再適用する必要があります。

ブランチも本物のサンドボックスであるはずですが、トランクもこの役割を果たす必要があります。タグは、その時点でコードが「ゴールド」であり、リリースに適しているかどうかを示します。

変更が大きすぎたり、不安定になったり、製品のメジャーリリースに近づいたり、一時的なブランチを作成したりしない限り、トランクで開発します。また、個々の製品リリースごとに永続的なブランチを作成します。Microsoftの分岐ガイダンスに関するドキュメントは非常に参考になりました。分岐に関する Eric Sinkのチュートリアルも興味深いものであり、Microsoftで機能するものが他の一部の人にとって重すぎる可能性があることを指摘しています。それは私たちの場合でした、私たちは実際に彼のチームがするエリックが言うアプローチを使います。

それはあなたの状況に依存します。私たちはPERFORCEを使用しており、通常、いくつかの開発ラインがあります。トランクは「ゴールド」と見なされ、すべての開発は、統合するのに十分安定しているときにメインラインにマージされるブランチで行われます。これは、カットを行わない機能の拒否を可能にし、独立したプロジェクト/機能が取得できる長期にわたる確実な増分機能を提供できます。

トランクに組み込まれた新機能のマージと追いつきには統合コストがかかりますが、とにかくこの苦痛に苦しむことになります。みんなでトランクで一緒に開発することは、西部の荒野につながる可能性があります。一方、分岐により、苦い統合薬を服用したいポイントをスケーリングして選択することができます。現在、12のプロジェクトで100人を超える開発者にスケーリングしており、それぞれに同じコアコンポーネントを使用する複数のリリースがあり、非常にうまく機能しています。

これの美しさは、これを再帰的に実行できることです。大きな機能のブランチは、他のブランチが分岐する場合、それ自体のトランクになる場合があります。また、最終リリースには、安定したメンテナンスを行う場所を提供する新しいブランチがあります。

現在の製品コードのメンテナンスを新しい開発に合わせて管理しようとすることは、せいぜい問題です。これらの問題を軽減するために、テスト作業が完了し、コードを配信する準備ができたら、コードをメンテナンスラインに分岐させる必要があります。さらに、メインラインは、リリースの安定化を支援するため、実験的な開発作業を含めるため、またはライフサイクルが複数のリリースにまたがる開発作業を収容するために分岐する必要があります。

非メンテナンスブランチは、他の方法では管理が難しいコード間に衝突の可能性（または確実性）がある場合にのみ作成する必要があります。ブランチがロジスティックの問題を解決しない場合は、それが作成されます。

通常のリリース開発はメインラインで行われます。開発者は、通常のリリース作業のためにメインラインにチェックインおよびチェックアウトします。現在の製品コードへのパッチの開発作業は、そのリリースのブランチにあり、パッチがテストに合格してデプロイされたらメインラインにマージする必要があります。非保守ブランチでの作業は、ケースバイケースで調整する必要があります。

開発作業の規模によって異なります。並行して作業する複数のチームが、同じコード（トランク）ですべてを効率的に作業することはできません。作業している少数のグループだけがいて、主な懸念がブランチの切断である場合は、ブランチに戻って作業を続け、機能する現在の本番コードにバグ修正を行うことができます。これは分岐の簡単な使用法であり、それほど面倒ではありません。

並行開発が多数ある場合は、それぞれの作業にブランチを用意する必要がありますが、そのためにはさらに多くの規律が必要になります。ブランチがテストされ、マージする準備ができていることを確認してください。マージをスケジュールして、2つのグループが同時にマージしようとしないようにします。

一部のブランチは開発期間が長いため、最終的にトランクにマージするときのサプライズの数を減らすために、トランクからブランチへのマージを許可する必要があります。

大規模な開発者グループが存在する場合は、実験を行い、自分の状況で何が機能するかを感じる必要があります。これは、多少役立つと思われるMicrosoftのページです。http：//msdn.microsoft.com/en-us/library/aa730834（VS.80）.aspx

主な開発にはトランクを使用し、リリースのメンテナンス作業にはブランチを使用しています。それはうまくいきます。ただし、ブランチはバグ修正にのみ使用し、特にデータベース側では大きな変更は行わないでください。スキーマの変更のみがメイントランクで発生し、ブランチでは発生しないというルールがあります。

リリースサイクルの大きな機能を実行するつもりなら、ブランチに分離されます。それ以外の場合は、トランクで作業し、ビルドした瞬間にすべての製品リリースに分岐します。

以前のプロダクションビルドはその時点でold_production_に移動され、現在の製品リリースは常に単なるプロダクションです。ビルドサーバーが本番環境について知っているすべてのことは、本番ブランチをデプロイする方法であり、強制トリガーでそのビルドを開始します。

trunk =現在の開発ストリーム、branch = release（s）アプローチに従います。顧客へのリリース時にトランクを分岐し、トランクを前進させ続けます。サポートする準備ができているリリースの数を決定する必要があります。サポートが多ければ多いほど、バグ修正で行うマージが多くなります。私たちは、トランクの背後で2リリースを超えないように顧客を維持しようとしています。（例：Dev = 1.3、サポートされているリリース1.2および1.1）。

トランクは一般的に主要な開発ラインです。

リリースは分岐され、多くの場合、実験的または主要な作業は分岐で行われ、メインの開発ラインと統合する準備ができたときにトランクにマージされます。

トランクは通常、メインの開発ソースです。そうしないと、新機能のマージに多くの時間を費やすことになります。私はそれが他の方法で行われるのを見ました、そしてそれは通常、土壇場の統合の頭痛の多くにつながります。

私たちはリリースにラベルを付けているので、積極的な開発を妨げることなく、生産の緊急事態に迅速に対応できます。

私にとっては、使用しているソフトウェアによって異なります。

CVSでは、「トランク」で作業するだけでタグ付けや分岐は行わないでください。そうしないと本当に苦痛だったからです。

SVNでは、トランクで「最先端」のことを行いますが、サーバープッシュを行うときがきたら、適切にタグ付けします。

私は最近gitに切り替えました。今、私はトランクで働くことはありません。代わりに、名前付きの「new-featurename」サンドボックスブランチを使用してから、固定された「current-production」ブランチにマージします。今考えてみると、「current-production」にマージする前に「release-VERSIONNUMBER」ブランチを作成して、古い安定バージョンに戻れるようにする必要があります...

それは本当にあなたの組織/チームがどのようにバージョンを管理するか、そしてあなたがどのSCMを使うかに依存します。

• 次のリリース（次のリリースで）を簡単に計画できる場合は、トランクで開発することをお勧めします。ブランチの管理には、より多くの時間とリソースがかかります。しかし、nextを簡単に計画できない場合（大規模な組織では常に発生します）、ブランチ（数個または数十個）ではなくコミット（数百/数千）を選択することになります。
• GitまたはMercurialを使用すると、ブランチの管理はCVSやSubversionよりもはるかに簡単です。私は安定した幹/トピックブランチの方法論に行きます。これはgit.gitチームが使用しているものです。読む：http : //www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
• Subversionを使用して、最初にトランクで開発する方法論を適用しました。リリース日になるとかなりの作業がありました。コミットをチェリーピックする必要があったからです（私の会社は計画が得意ではありません）。現在、私はSubversionの専門家であり、Subversionでのブランチの管理について非常によく知っているので、安定したトランク/トピックブランチの方法論に向かっています。以前よりもはるかにうまく機能します。今はgit.gitチームがどのように機能するかを試していますが、おそらくSubversionを使用します。

ここに私が好むSVNデザインがあります：

• ルート
  • 開発
    • 枝
      • 特徴1
      • 特徴2
      • ...
    • トランク
  • ベータ
    • タグ
    • トランク
  • 解放する
    • タグ
    • トランク

独自のブランチを必要とする主要な機能を除いて、すべての作業は開発/トランクから行われます。作業が開発/トランクに対してテストされた後、テストされた問題をベータ/トランクにマージします。必要に応じて、ベータサーバーに対してコードをテストします。いくつかの変更をロールアウトする準備ができたら、適切なリビジョンをリリース/トランクにマージしてデプロイします。

タグはベータブランチまたはリリースブランチで作成できるため、ベータ版とリリースの両方の特定のリリースを追跡できます。

この設計により、柔軟性が大幅に向上します。また、一部のリビジョンがベータ版のテストに合格しなかった場合、他のバージョンをリリース/トランクにマージしながら、リビジョンをベータ版/トランクに残しておくのも簡単になります。

私たちが使用する方法は、Perforceアプローチです。これは、Laura Wingerdの素晴らしい本で詳しく説明されています。

http://oreilly.com/catalog/9780596101855/index.html

本はPERFORCEを中心にしていますが（WingerdはPERFORCE製品マネージャーです）、概念は任意またはすべてのVCSに適用できます。

PERFORCEアプローチ（およびプラットフォーム）は私たちに非常に役立ちました。多くの企業（google、Intuit、そして聞いたことがあるが、Microsoft Windows自体）で使用されています。

その本は読む価値がある。

これを読んでください：http : //oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

Subversionの慣習の質問である私見には、万能の答えはありません。

それは実際にはプロジェクトのダイナミクスとそれを使用する企業に依存します。非常にペースの速い環境では、リリースが数日おきに発生する可能性があり、信念を持ってタグ付けしてブランチしようとすると、管理できないリポジトリができてしまいます。このような環境では、必要なときに分岐するアプローチにより、はるかに保守しやすい環境が作成されます。

また、私の経験では、純粋な管理の観点から見ると、svnの方法論を切り替えることは非常に簡単です。

私が最も効果的に機能することがわかっている2つのアプローチは、必要なときにブランチすることと、タスクごとにブランチすることです。もちろん、これらは互いにまったく正反対です。私が言ったように-それはすべてプロジェクトのダイナミクスに関するものです。

@Brian R. Bondy：チームがプロジェクトで並行して処理される特定の量のPPL /タスクに到達すると、これは解決策ではないことに注意してください。

QA部門がqaに関与すると、進行中のブランチごとに1つのインストールを提供するために必要な労力が高すぎます。SOA /クライアント/サーバー/ Webサービス/データベースを考えてください。これらはすべてブランチごとに提供する必要があります。

このソリューションには、統合段階もありません。