開発ブランチはいつ作成する必要がありますか?


11

プロジェクトのチームを単一のメイン/トランクブランチから、メインに定期的にマージする必要がある複数の開発/ワークブランチに移動しています。この記事TFS分岐ガイド(TFSとVisual Studio 2010を使用しています)に基づいて新しいプロセスを作成しています。

現在、1人から5人の人々がプロジェクトに取り組んでいます。Mainは必要に応じていつでもリリースできるようにするため、常に安定している必要があります。スプリントは修正されていません-少なくともまだ-現時点では1〜2週間ごとにリリースしています。

この時点で、各ユーザーはアプリケーション全体のバグを修正しています。数週間以内に、アプリの新しい大きなコンポーネントの開発を開始します。

私たちが見つけている一つのこだわりのポイントは、いつ開発ブランチを作成すべきかということです。開発者のスキルセットに応じて、複数のユーザーストーリーを並行して実装します。開発者ごとにブランチを作成することを考えましたが、それは意味がありません。作業の一部で常にコラボレーションが必要になるからです。他の作業が完了している間にMainにマージするため、単一の開発ブランチでは対応できません。

誰にもこれに関するガイダンスがありますか?


TFSを使用し、ブランチを作成してくださったことを神に祝福してください。私の会社の前の段階で、彼らはTFSを使用することを決定し、最終的にすべての開発者がマージプロセスを非常に恐れて、分岐がプログラマーフィアファクターに変わりました。
ヨルダン

@ジョーダン:完全に根拠のない恐怖ではありません。
ロバートハーヴェイ

回答:


9

私は任意のブランチ、つまりフレッドのバグ修正やハリーのバグ修正が好きではありません。複数の開発者が1つの機能を操作できる1つの(独立した)機能1ブランチの方がはるかに快適です。ただし、機能が完全な場合にのみマージされます。

したがって、今は「バグ修正」ブランチのみが必要ですが、開発を開始したら、重要な機能ごとにブランチを作成する必要があります。こうすることで、他のバグ機能に依存することなく、それらをマージおよびリリースできます。

TFSのマージがどれほど優れているかはわかりませんが、数か月以内にわかると思います:)


これは私が仕事をしている場所でのやり方にかなり近いです。トランクに変更が加えられるたびに、トランクから各作業ブランチに宗教的にマージすることだけを確実にすれば、うまく機能します。また、自動ビルドのセットアップも同時に検討してください。(ソース管理に保存されている)各ブランチが常に少なくともビルド可能な状態であることを知っていると、物事がずっと簡単になります。マージの両側に変更と非常に長い行を持つまでのVisual Studioのツールを使用してマージするためとして、それは...うまく機能
からCVn

5

他の作業が完了している間にMainにマージするため、単一の開発ブランチでは対応できません。

複数の開発ブランチを作成する必要があることを既に知っているようです。考えられる2つのシナリオ:

  1. 5人の開発者はそれぞれ、プロジェクトの独立した部分に取り組んでいます(バグ修正) - 開発者ごとに個別のブランチ作成されていることを確認してください。これにより、各開発者に責任と責任が課せられ、変更セットが他の人の作業と競合しないようになります。5人の開発者の1人が間違いを犯す可能性が高いです。もしそうである場合/それが事実である場合、他のすべての人が持ちこたえることは意味をなさない。
  2. 複数の機能の開発 -特定の機能/バグに取り組んでいる開発者の数に関係なく、これら分離する必要があります。これが有益な例は、すべてのコードコミットが開発中の機能の一部であるということです-第二の推測は含まれません。

1

DVCSの暗黙の作業分岐

私たちはMercurialを使用しているため、開発者の開発ボックスに暗黙の作業ブランチがあります。コミットは常にローカルワークスペースに対して行われます。リリース可能な作業が完了すると、それはプライマリリポジトリサーバーにプッシュされ、そこで自動的に構築およびテストされます。

明示的なブランチを作成することはほとんどありませんが、スプリントの長さは1週間を超えることはなく、カードの完了には1〜2日しかかかりません。

また、コードの他の部分や他のプロジェクトの作業をスレッド化することで、ユーザーが常に困難なマージを行う必要がないようにすることで、マージの痛みを軽減できます。


0

ストーリーごとに1つのブランチとリリースごとに1つのブランチの両方を使用しました(すべての開発者が開発者にストーリーをチェックインし、それらのいずれかがdevブランチを壊す場合はすべて壊れます)。競合が気に入らない場合は、ストーリーごとに1つのブランチを作成することを強くお勧めします。devブランチは、すべての開発者に対して常に安定したままであり、開発者が別の開発者が既に壊したコードに取り組んでいる待ち時間はありません。ストーリーが完了すると、すべてのコードがブランチに配置されます。これをdevにマージしますが、チェックインとテストは行いません。競合が発生した場合は解決し、競合する人にコードの削除を避けるように依頼します。次に、devにマージします。これにより、すべての開発者がスムーズに機能します。また、会社の規模にも依存します。当社には、1つのコードベースで同時に作業する200人の開発者がいます。しかし、彼らの物語のために別のブランチ。コードがdevブランチにマージされると、storyブランチはすぐに削除されます。これがお役に立てば幸いです。ありがとう


0

これがgitに基づいている場合は、バグ修正ごとにブランチを作成し、最短時間でバグを修正し、バグ修正ブランチを開発ブランチにマージして、変更を開発ブランチにプッシュします。プルリクエストとマージを確認することは、優先順位を最も高くする必要があります。それは、それが早く完了するほど、マージが問題を引き起こさない可能性が高くなるためです。マージしたら、これらのブランチを削除できます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.