プロジェクトのチームを、単一のMain/Trunkブランチの使用から、定期的にMainにマージする必要のある複数のDevelopment/Workブランチに移動しています。新しいプロセスは この記事 および TFS分岐ガイド に基づいています(TFSおよびVisual Studio 2010を使用しています)。
現在、プロジェクトには1人から5人の人が同時に取り組んでいます。必要なときにいつでもオプションをリリースできるようにするため、Mainは常に安定している必要があります。私たちはスプリントを修正していません-少なくともまだ-そして今のところ1週間から2週間ごとにリリースしています。
この時点で、各人がアプリケーション全体のバグを修正しています。数週間以内に、アプリの新しい大きなコンポーネントの開発を開始します。
私たちが見つけている1つの固定点は、開発ブランチを作成する必要があるときです。開発者のスキルセットに応じて、複数のユーザーストーリーを並行して実装します。開発者ごとにブランチを作成することを検討してきましたが、1つの作業で常にコラボレーションが必要になるため、それは意味がありません。他の作業が完了している間にMainにマージしたいので、単一の開発ブランチでは満足できません。
誰かがこれについていくつかのガイダンスを持っていますか?
私は任意のブランチ、すなわちフレッドのバグ修正やハリーのバグ修正が好きではありません。複数の開発者が1つの機能を操作できるようにする1つの(独立した)機能1つのブランチの方がはるかに快適です。ただし、機能が完全な場合にのみ機能をマージします。
したがって、現時点では「バグ修正」ブランチのみが必要ですが、開発を開始したら、重要な機能ごとにブランチを作成する必要があります。そうすれば、他のバグの多い機能に依存することなく、それらをマージしてリリースできます。
TFSのマージがどれほど優れているかはわかりませんが、数か月でわかるでしょう:)
他の作業が完了している間にMainにマージしたいので、単一の開発ブランチでは満足できません。
複数の開発ブランチを作成する必要があることを既に知っているようです。次の2つのシナリオが考えられます。
DVCSでの暗黙の作業分岐
私たちはMercurialを使用しているため、開発者の開発ボックスには暗黙の作業ブランチがあります。コミットは常にローカルワークスペースに対して行われます。解放可能な作業が完了すると、プライマリリポジトリサーバーにプッシュされ、そこで自動的に構築およびテストされます。
明示的なブランチを作成することはほとんどありませんが、スプリントは1週間以内であり、カードは1〜2日で完了します。
また、コードの他の部分や他のプロジェクトからの作業をスレッド化することで、マージの痛みを軽減することができるので、人々はいつも難しいマージを行う必要がありません。
私はストーリーごとに1つのブランチとリリースごとに1つのブランチの両方を使用しました(すべての開発者が開発するストーリーをチェックインし、それらのいずれかがdevブランチを壊すと、すべてが壊れます)。競合が気に入らない場合は、ストーリーごとに1つのブランチをお勧めします。開発ブランチはすべての開発者にとって常に安定したままであり、別の開発者がすでに破ったコードに取り組んでいる開発者の待ち時間はありません。ストーリーが完了すると、すべてのコードがブランチに配置されます。 devにマージしますが、チェックインとテストは行いません。競合が発生した場合は、解決して、競合している人にコードの削除を回避するよう依頼します。次に、devにマージします。これは、すべての開発者がスムーズに作業するのに役立ちます。また、会社の規模にも依存します。私たちの会社には、1つのコードベースで同時に作業している200人の開発者がいますが、彼らのストーリーには別々のブランチがあります。コードがdevブランチにマージされると、storyブランチはすぐに削除されます。これがお役に立てば幸いです。ありがとう
これがgitに基づいている場合は、バグ修正ごとにブランチを作成し、できるだけ短時間でバグを修正し、バグ修正ブランチを開発ブランチにマージしてから、変更を開発ブランチにプッシュします。プルリクエストを確認してマージすることは最高の優先順位である必要があります。これは、処理が速くなるほど、マージによって問題が発生しない可能性が高くなるためです。マージしたら、これらのブランチを削除できます。