[解決済み] 開発はブランチで続けるか、トランクで続けるか？[クローズド］

質問内容

定期的にリリースが行われるソフトウェア製品を開発しているとします。ブランチとマージに関して、どのようなベストプラクティスがあるでしょうか？定期的に公開されるリリースブランチをスライスして、トランクで開発を続けるか、トランクを安定版とみなして定期的にリリースタグをつけ、実験的な作業はブランチで行うかです。トランクをゴールドと見なすか、サンドボックスと見なすか、皆さんはどうお考えでしょうか？

解決方法は？

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

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

総合的にみてより良い方法（私の経験上）。トランクは常に安定していなければなりません。

この方法のガイドラインと利点は以下の通りです。

• 各タスク (または関連する一連のタスク) を独自のブランチでコーディングしておけば、いつこれらのタスクをマージしてリリースを実行するか、柔軟に決めることができます。
• QAは、トランクにマージする前に、各ブランチで行う必要があります。
• 個々のブランチでQAを行うことで、バグの原因を正確に把握することが容易になります。
• このソリューションは、開発者の人数に関係なく拡張できます。
• SVNでは分岐はほとんど瞬時に行われるため、この方法は有効です。
• 実行する各リリースにタグを付けます。
• しばらくリリースする予定のない機能を開発し、マージするタイミングを正確に判断することができます。
• すべての作業に対して、コードをコミットするメリットを得ることができます。 トランクからしか作業をしない場合、おそらくあなたのコードはコミットされないまま、つまり保護されず、自動的な履歴もないままになるでしょう。

もし、その逆で、すべての開発をトランクで行おうとすると、次のような問題が発生します。

• デイリービルドでビルドの問題が常に発生する
• ある開発者が問題をコミットすると、プロジェクトに参加している他のすべての人が問題を抱えることになり、生産性が低下する。
• 最終的に安定版を取得する必要があるため、リリースサイクルが長くなる
• 安定したリリースの少なさ

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

特に、すべての開発をトランクで行うべきと言えるケースは、新しいプロジェクトを始めるときです。 それ以外にも、状況に応じてさまざまなケースが考えられます。

ところで、分散型バージョン管理システムはより柔軟性があり、私はhgかgitのどちらかに切り替えることを強くお勧めします。