最近、同僚と、スクラムプロジェクトでバージョン管理を整理する方法について話し合っていました。より具体的には、ブランチ作成の基準（開発者ごと、タスクごと、ストーリーごと、スプリントごと？）と統合の方法。
私の意見では、それを整理するための便利な方法は、ユーザーストーリーごとにブランチを作成することです。これにより、各ストーリーが完成したらリリース可能なトランクに統合でき、アプリケーションの「配信可能なバージョン」を常に使用できるようになります。どんな瞬間にも。
したがって、ストーリーを完成させることができない場合は、それを省略して、スプリントのリリースを損なうことはありません。（集中型ツールを検討する場合、分散型ツールを使用する場合は考慮事項が異なる可能性があります）
あなた自身のアプローチ、あなたが好むツールの種類、そしてあなたが経験と学んだ教訓で見た賛否両論を知りたいです。
分岐プロトコルを軽量に保ちます。スクラムでは、誰かが特定の機能で動作するようにコードを分岐したい場合は、それらを許可します。誰も分岐することを恐れてはいけません。これは、DVCSの利点の1つです。つまり、チームのルールや標準に偏ることなく、必要なときにブランチを作成できます。
私のお金では、それはケースバイケースであり、開発プロセスでパターンが見られ始めたら、それらを形式化して、全員が同じページにいるようにします。
すべての開発者が、変更を統合およびマージするのは自分の責任であることを理解していることを確認してください。これにより、コードをいつ分岐するかについて人々が適切な電話をかけることができるように、バーをほぼ適切な場所に設定する必要があります。
ユーザーストーリーごとのブランチは、私にはかなり過剰に聞こえます。単一のコードベース（トランク）を保持し、これを処理します。私たちが通常分岐するのは、通常のリリースまで待てなかった現在の本番環境の問題を修正することだけです。
それは実際には非常に興味深いトピックです。
実際、各タスク (ストーリーではなく、スクラム計画ミーティング後に分解された実際のタスク) には、少なくとも 1 つの関連するブランチがあります。
次の図で、それがどのように見えるかを確認できます。
これにより、開発者が多くの中間コミットを行うことにした場合でも、チームはタスク (ブランチ) で何が変更されたかを確認できるため、ピア レビューを奨励することが非常に簡単になります (これは非常に良い方法です!)。
以下に役立つリンクがいくつかあります。
マスターブランチを数日間混乱させたり、「多くの」開発者が関与したりするような話や一連の話があるときはいつでも、そのためのブランチを作成します (あまり一般的ではありません。これを避けるためにタスクを実行しようとしますが、リスク軽減の一種として。スプリント後にマスター ブランチの値を増やしていない可能性があることを意味する場合でも、各スプリントの終わりにマスター ブランチが常にリリースの準備ができていることを確認したいと考えています。
ストーリー/機能/タスク ブランチは、マスター ブランチに対して非常に頻繁に同期されます。目標は、スプリントが終了するかなり前にブランチを常にマージすることです。
もちろん、私たちは皆 ' git ' を使用しているので、事実上、私たちは常にローカル ブランチで作業を行っており、ビッグバン統合を回避するのに十分な頻度で master と同期することがかなり得意になり、役に立たないまま放置することはめったにありません。 /master ブランチの未使用コード。
リリースごとに1つのブランチを使用し、継続的インテグレーションを使用して、1つのユーザーストーリーが他のユーザーストーリーに損害を与えないようにします。
ソース バージョニング システムに行う必要がある唯一の変更は、それを継続的インテグレーション システム ( TeamCityやCruiseControl.NETなど) と統合することです。
ええ、私はあなたの質問に本当に答えていないことを知っていますが、私は本当にそれを意味します. アジャイル ソフトウェア プロジェクトでは、できるだけ頻繁に製品を顧客にリリースできるようにする (またはできるようにする) 必要があります。そのため、ソース システムにあるものはすべて機能していること、または機能していない場合はなぜ機能していないのかを知る必要があります。
機能ごとに分岐することで、どのように機敏性や無駄を省くことができるかわかりません。支店管理のコストは高すぎます。機能ごとにブランチが必要だと感じる場合は、ストーリーが大きすぎると思います。ストーリーは次のスクラムまでに完了する必要があります。そのため、ブランチが 1 ～ 2 日しか存在しない場合、それがどのように役立つか、またはそのコストが返済されるかはわかりません。多くの人がストーリーに取り組むことは日常的なことなので、開発者がコードをマージできるように、開発者が作業する開発ブランチを使用することがあります。コードをテスト用にデプロイせずに、同じストーリーに取り組んでいる間、1 日に何度も (メイン ブランチ) . 理想的には、進行中のストーリーが非常に少なく、メイン ブランチのみが必要で他のブランチが必要ないほど速く完了することが理想的です。