ブランチが1つしかない場合、SVNブランチを気にする必要がありますか？

Subversionで1つのブランチのみを処理する場合、気にする必要がありますか？トランクで作業を高速化することはできませんか？

これは、Subversionで開発する方法です。

• トランクあり
• 新しい開発ブランチを作る
• そのブランチで新しい機能を開発します
• 機能が完了すると、トランクにマージされ、ブランチが削除され、トランクから新しい開発ブランチが作成されます

プロダクションにリリースしたいときは、トランクからタグを作ります。バグ修正は、そのタグからのブランチで行われます。このバグ修正はトランクにマージされます。

これが、機能の完了後に新しい開発ブランチを作成する理由です。このようにして、バグ修正はすぐに新しいコードに含まれます。

以下は明確にする必要がある図です：

これは、これが最も効率的な作業方法ではないという感じがあります。コミットする前にローカルでビルドします。これには5〜10分かかります。これはかなり長い待ち時間として経験されていることを理解できます。

開発ブランチの考え方は、トランクは常にリリースの準備ができているということです。しかし、これは私たちの状況ではもう当てはまりません。場合によっては、機能の準備がほぼ整っており、一部の開発者は既に次の機能のコーディングを開始します（そうでない場合、1人または2人の開発者が完了してマージするのを待っています）。

次に、機能1が完了すると、トランクにマージされますが、機能2の一部のコミットが含まれています。

では、ブランチは1つしかないので、開発ブランチを気にする必要がありますか？私はトランクベースの開発と抽象化による分岐について読んでいますが、ほとんどの記事は抽象化による分岐の部分に焦点を当てています。数回のリリースにまたがる大きな変更の印象を受けました。これは私たちが抱えている問題ではありません。

どう思いますか？トランクで作業できますか？最悪のシナリオは（私が思うに）トランクからタグを作成し、必要なコミットをチェリーピックする必要があるということです（一部のコミット/機能はまだ本番稼働の準備ができていないため）。

小さな増分でコミットでき、継続的な統合が可能であれば、トランク上で直接作業するIMHOは問題ありません。そのため、コミットによって既存の機能が損なわれないようにすることができます（妥当な範囲で）。現在のプロジェクトでもそれを行っています（実際、デフォルトでタスク固有のブランチを使用するプロジェクトで作業したことはありません）。

リリース前にブランチを作成するか、機能の実装に長い時間がかかる場合（つまり、複数の反復/リリースにまたがる場合）のみ作成します。タスクの大まかなサイズは、ほとんどの場合十分に見積もることができるため、個別のブランチが必要かどうかを事前に知ることができます。また、次のリリースまでの残り時間を把握しているため（約2か月ごとにリリースを公開）、タスクが次のリリースまでに利用できる時間に収まるかどうかを簡単に確認できます。疑わしい場合は、リリースブランチが作成されるまで延期し、トランクでの作業を開始してもかまいません。これまでのところ、タスク固有のブランチを1回だけ作成する必要がありました（約3年で）。もちろん、プロジェクトは異なる場合があります。

機能開発で説明しているのは並行開発（さまざまな製品リリースを対象とした同時開発）であり、適切に処理するためにブランチが必要です。特定のリリースを作成する機能を頻繁に再構成する必要がある場合は、リリースごとまたは機能ごとに1つのブランチを持つことができます。

これを行うもう1つの方法は、デフォルトでトランクを使用しないで作業することですが、タスクが次のリリースを超えて拡張されることが予想される場合は、ブランチを作成します。もちろん、リリースには常にタグを付けます。

どのアプローチを採用するかは、実際にどの程度の管理を事前に行うことができるかに依存します。通常のリリースで実際に並行開発が行われない場合は、2番目のアプローチを採用します。