version-control - ブランチまたはトランクで開発を続けますか?

Question

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

score 152 · Accepted Answer

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

どちらの方法が優れているかについての答えは、正確な状況に大きく依存しますが、これまでの全体的な経験が示していることを書きます.

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

この方法のガイドラインと利点を次に示します。

各タスク (または関連する一連のタスク) を独自のブランチでコーディングすると、これらのタスクをマージしてリリースを実行するタイミングを柔軟に設定できます。
トランクにマージされる前に、各ブランチで QA を実行する必要があります。
個々のブランチで QA を行うことで、バグの原因を正確に知ることができます。
このソリューションは、任意の数の開発者に対応します。
分岐は SVN ではほぼ即時の操作であるため、この方法は機能します。
実行する各リリースにタグを付けます。
しばらくリリースする予定のない機能を開発し、それらをいつマージするかを正確に決定できます。
実行するすべての作業について、コードをコミットする利点があります。トランクのみで作業する場合、おそらくコードをコミットしないままにしておくことが多く、そのため保護されておらず、自動履歴もありません。

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

デイリービルドのコンスタントなビルドの問題
開発者がプロジェクトの他のすべての人のために問題をコミットすると、生産性が低下します
最終的に安定したバージョンを取得する必要があるため、リリースサイクルが長くなる
安定性の低いリリース

ブランチを安定させ、トランクを開発サンドボックスとして維持しようとすると、必要な柔軟性が得られません。その理由は、その安定版リリースに入れたいものをトランクから選んで選ぶことができないからです。トランクの中ですでにすべてが混ざり合っているでしょう。

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

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

score 66 · Accepted Answer

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

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

デイリービルドのコンスタントなビルドの問題

開発者がプロジェクトの他のすべての人のために問題をコミットすると、生産性が低下します

おそらく継続的インテグレーション技術を使用したことがありません。

1 日に数回、たとえば 1 時間に 1 回程度のテストビルドを実行しないと、これらの問題が発生しやすくなり、開発のペースがすぐに妨げられることは事実です。

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

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

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

score 36 · Accepted Answer

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

他にも方法があることは理解しています。これは、私が過去に行った方法です。

score 19 · Accepted Answer

両方。

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

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

トランクを不安定または非稼働状態のままにする新機能は、独自の別のブランチで実行され、完了時にトランクにマージされます。

score 14 · Accepted Answer

私は Henrik Kniberg がVersion Control for Multiple Agile Teamsで説明したアプローチを気に入って使用しています。Henrik は、複数のチームを持つアジャイル環境でバージョン管理を処理する方法を説明する素晴らしい仕事をしてくれました(従来の環境の単一チームでも機能します)。自明です）以下：

私はそれが好きです：

それは簡単です：あなたは絵からそれを得ることができます.
マージや競合の問題があまり発生せずにうまく機能します（およびスケーリングします）。
「動作するソフトウェア」はいつでもリリースできます (アジャイルの精神で)。

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

score 11 · Accepted Answer

トランクの安定性を維持し、すべての作業をブランチで行う開発プロセスの良い参考資料は、Divmod のUltimate Quality Development Systemです。簡単な要約:

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

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

score 10 · Accepted Answer

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

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

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

score 8 · Accepted Answer

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

score 5 · Accepted Answer

それはあなたの状況に依存します。Perforce を使用しており、通常は複数の開発ラインがあります。トランクは「ゴールド」と見なされ、すべての開発は、統合するのに十分安定したときにメインラインにマージされるブランチで行われます。これにより、カットを行わない機能を拒否することができ、独立したプロジェクト/機能が取り上げることができる、時間の経過とともに確実な増分機能を提供できます。

トランクに組み込まれた新機能のマージとキャッチアップには統合コストがかかりますが、とにかくこの痛みに苦しむことになります. 全員が幹線上で一緒に開発すると、ワイルドウェストの状況につながる可能性がありますが、分岐を使用すると、苦い統合の丸薬を服用するポイントをスケーリングして選択できます。現在、12 のプロジェクトで 100 人を超える開発者にスケールアップしており、それぞれが同じコアコンポーネントを使用して複数のリリースを行っており、非常にうまく機能しています。

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

score 4 · Accepted Answer

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

score 4 · Accepted Answer

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

非メンテナンスブランチは、他の方法では管理が困難なコード間の衝突の可能性 (または確実性) がある場合にのみ作成する必要があります。支店が物流上の問題を解決しない場合、問題が発生します。

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

score 4 · Accepted Answer

これは、開発作業の規模によって異なります。並行して作業している複数のチームは、すべて同じコード (トランク) で効果的に作業することはできません。少人数のグループで作業していて、主な関心事がブランチをカットすることである場合は、ブランチに戻って作業を続行し、現在の本番コードにバグ修正を加えて動作させることができます。これは分岐の些細な使用法であり、それほど面倒ではありません。

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

一部のブランチは非常に長い間開発されているため、最終的にトランクにマージする際の驚きの数を減らすために、トランクからブランチへのマージを許可する必要があります。

大規模な開発者グループがいる場合は、実験して、自分の状況で何が機能するかを感じてください。これは、多少役立つかもしれない Microsoft のページです: http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspx

score 2 · Accepted Answer

トランク=現在の開発ストリーム、ブランチ=リリースのアプローチに従います。顧客へのリリース時に、トランクを分岐し、トランクを前進させ続けます。サポートする準備ができているリリースの数を決定する必要があります。サポートが多ければ多いほど、バグ修正のためのマージが多くなります。私たちは、お客様がトランクの後ろにあるリリースを 2 つ以内に抑えるように努めています。(例: Dev = 1.3、サポートされるリリースは 1.2 および 1.1)。

score 2 · Accepted Answer

大きな機能であるリリースサイクルに取り組む場合、ブランチに置き去りにされます。それ以外の場合は、トランクで作業し、ビルド時にすべての製品リリースに分岐します。

その時点で、以前の本番ビルドは old_production_ に移動され、現在の本番リリースは常に本番のみです。ビルドサーバーがプロダクションについて知っているのは、プロダクションブランチをデプロイする方法だけであり、フォーストリガーでビルドを開始します。

score 1 · Accepted Answer

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

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

score 1 · Accepted Answer

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

アクティブな開発を配布せずに生産上の緊急事態に迅速に対応できるように、リリースにラベルを付けています。

score 1 · Accepted Answer

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

CVS の下では、「トランク」で作業するだけで、タグ/ブランチを使用することはありませんでした。

SVN では、トランクで「最前線」の作業を行いますが、サーバープッシュを行うときは適切にタグ付けされます。

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

score 1 · Accepted Answer

それは、組織/チームがバージョンをどの程度管理しているか、およびどの SCM を使用しているかに大きく依存します。

次の (次のリリースでの) 計画が簡単にできる場合は、トランクで開発する方がよいでしょう。ブランチの管理には、より多くの時間とリソースが必要です。しかし、次の計画が簡単にできない場合 (大規模な組織では常に発生します)、ブランチ (数または数十) ではなく、コミット (数百/数千) をチェリーピッキングすることになるでしょう。
Git や Mercurial を使用すると、cvs や subversion よりもブランチの管理がはるかに簡単になります。私は安定したトランク/トピックブランチの方法論に行きます。これは git.git チームが使用しているものです。読む: http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
Subversion では、最初にトランク内開発方式を適用しました。リリース日になると、かなりの作業がありました。なぜなら、私は毎回コミットを選択しなければならなかったからです (私の会社は計画が苦手です)。現在、私は Subversion の専門家のような存在であり、Subversion でのブランチの管理についてよく知っているため、安定したトランク/トピックブランチの方法論に移行しています。以前よりもはるかにうまく機能します。今、私は git.git チームがどのように機能するかを試していますが、おそらく Subversion を使い続けるでしょう。

score 1 · Accepted Answer

私が好むSVNデザインは次のとおりです。

根
- 発達
  - 枝
    - 特徴1
    - 特徴2
    - ...
  - トランク
- ベータ
  - タグ
  - トランク
- リリース
  - タグ
  - トランク

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

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

この設計により、多くの柔軟性が可能になります。また、一部のリビジョンがベータでのテストに合格しなかった場合に、他のリビジョンをリリース/トランクにマージしながら、リビジョンをベータ/トランクに残しておくことも容易になります。

score 0 · Accepted Answer

Subversion規約の質問IMHOに対する万能の答えはありません。

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

また、私の経験では、純粋な管理上の観点から、必要に応じて svn 方法論を切り替えるのは非常に簡単です。

私が知っている最も効果的な 2 つのアプローチは、必要に応じて分岐する方法と、タスクごとに分岐する方法です。もちろん、これらは互いに正反対です。私が言ったように - それはすべてプロジェクトのダイナミクスに関するものです.

version-control - ブランチまたはトランクで開発を続けますか?

20 に答える 20

Related

Reference