機能ごとの分岐-長所/短所？
私は現在、分岐とマージが最初からまったくうまく機能していないプロジェクトで働いています。これを変えるために、私たちはそれを行うためのさまざまな方法について話してきました。こういうことはみんな自分の哲学があると思うので、ここにもあるようです。
私たちが話していることの1つは、機能ごとに分岐することです。この特定の方法の良い点と悪い点について、私たちはたまたま非常に異なる見解を持っています。
以前にこれを行った経験はありますか？それはうまくいきましたか？問題はありましたか？どのような問題がありましたか？
この質問が本当に正しい答えを持っていないことは知っていますが、世界中の他の開発者の意見を聞くことは非常に興味深いことであり、stackowerflowはそのための素晴らしい場所のようです。
機能ごとにブランチを使用しており、非常にうまく機能します。最大の利点は、新しい機能が（この場合はMainに）統合されるまで、機能チームが作業内容が他の機能チームに影響を与えないことを知っていることです。
新しい機能が終了したら（そしてブランチがメインにマージされたら）、ブランチをブランチ履歴フォルダーに移動します。これにより、開発者が確認する必要のあるブランチ（フォルダー）の数を最小限に抑えることができます。
私たちの場合、メインブランチでは誰も働いていません。すべての開発は機能ブランチで行われます。初期開発（本番環境への最初のリリース前）は、開発ブランチで行われます。本番環境への最初のリリース後、すべての開発は新しい機能ブランチで行われます。
中小規模のチームの場合、完全なブランチ分離が本当に必要ない場合は、余分なブランチを避けてください。特に、開発チームの文化が適切なブランチとマージを嫌う場合はそうです。おそらく、維持するブランチの数を減らすことと引き換えに、マージを許可されているすべての開発者がマージの方法に厳密に従うことを確認してください。シェルフセット（TFS内）と短命の機能ブランチは、マージのオーバーヘッドと関連するリスクを最小限に抑えるための優れた手法です。
詳細
生産性とバージョン管理の安全性のバランスをとるために私が見つけたパターンは次のとおりです（〜25人の開発者と〜3人のテスターのチームの場合）：
同じブランチで作業する：疎結合または無関係のコードで作業する開発者は、同じDev（または「統合」）ブランチで比較的安全に直接作業できます。バグ修正と非破壊的な変更はここにうまく適合します（他の開発者に影響を与える主要なリグレッションのリスクが低くなります）。継続的インテグレーションビルドとゲートビルドは、同じブランチで作業する多くの開発者のリスクを軽減する2つのベストプラクティスです。 トグル注：フィーチャートグルを使用すると、分岐の必要性をさらに回避できますが、トグル動作をテスト/維持するためのオーバーヘッドが、分岐を使用するよりもリスクが高くないことを確認してください。
Shelvesets：バージョン管理システムの機能を使用して、開発者固有のプロトブランチで保留中の変更を保存します。 TFS（Team Foundation Server）にチェックインする開発者は、統合/開発ブランチにチェックインする前に機能を開発およびテストする必要があるのが個人ブランチ（または多くのマイクロ機能/タスクブランチ）の代わりにシェルフセットを使用できます。他のバージョン管理システムにも同様の構造があると思いますANTIPATTERN：ローカルワークスペースは各開発者に一時的な分離を自動的に提供します...しかし開発者はソース管理のどこかで頻繁に/毎日変更をチェックインして防止する必要がありますローカルのみの作業の日数以上を失うリスク。）
短命のブランチ：分離のためにブランチが必要な場合（複数の開発者が取り組む必要のある機能を壊すためなど）、短命の機能ブランチを作成することは良い方法の1つです。ブランチの使用を明確に定義し、長期にわたって一意にするブランチ命名規則をお勧めします。
上記のワークフローの主な利点は、顧客の満足度を直接向上させる機能を開発する代わりに、マージ税（フォワード/リバースの統合（ダウン/アップのマージ）に費やされる時間）を最小限に抑えることです。
シナリオ例：新しい「クール」機能は既存の機能を壊し、完了するまでビルドします。また、同じコードベースでコラボレーションするには2人以上の開発者が必要です（Shelvesetを使用するオプションを削除します）。 「Cool」の開発所有者Cool1という名前のブランチを作成し、機能の最初のバージョンを開発して統合テストします。開発者の所有者は、親の変更を毎日（せいぜい毎週）マージする責任があります。マージの準備ができていることを確認します（親が子をマージしました（FI）、すべてUTおよびコア受け入れテストが実行され、引き続き合格）。親（RI）にマージし、親ブランチで機能することを確認します（すべて= UTおよびコア受け入れテストに合格）、次にCool1機能ブランチ（クリーンアップ）を削除します。
開発/統合ブランチにマージした後、クール機能をより徹底的にテストします。 （テストリソースは限られているため、各ブランチの完全なテスト環境は避けてください。）Coolのバグ修正と戦術的拡張/リファクタリングは、Devブランチで直接行われます（開発が割り当てられたときにシェルフセットを使用すると、チェックイン前にローカルのdev/testに何日もかかる）。 Coolの大規模な（マルチ開発者）手直しが後で必要な場合は、新しいCool2ブランチを作成します。
TFS2010の移動/名前の変更注： TFS 2010の移動と名前の変更の動作が（TFS 2008から）変更され、移動と名前の変更= "新しい名前/場所に分岐してから元のアイテムを削除済みとしてマークします"。つまり、ブランチを別のフォルダーに移動するのではなく、ソース管理\ Dev \に表示したくない場合は、非アクティブな機能ブランチを削除する必要があります。これはまた、削除されたフォルダの表示を有効にする開発者は、これらの削除された（または移動または名前が変更された）短命のブランチを、雑然とする可能性のある「ゴースト」として常に見ることを意味します。 （これにより、履歴を表示したり、削除したアイテムの削除を取り消すことができます。）
機能のブランチの代わりに、機能の切り替え（つまり、機能を使用可能にするかどうかを指定できるコード内の切り替え）があります。それらはこの点で本当に役に立ちます。それらは、新しい機能の開発と展開を可能にしますが、トグルが...うまくトグルされた場合にのみ利用可能です（それはWordですら）。私はそれがグーグルラボ全体のアイデアのようなものだと思います。
ここで注意すべき点は、これらのトグルは、開発中に慎重に検討およびテストされない場合、それ自体でドラマを引き起こす可能性があるということです。事実上、機能を有効または無効にした場合の動作を確認するために実行する必要のあるテストの量が増えています。開発中の機能が複数ある場合は、それらすべてが有効/無効状態のさまざまな組み合わせとどのように相互作用するかを確認する必要があります。
そうは言っても、うまくやれば、彼らにも大きなメリットがあります。すべてのユーザーに影響を与えることなく、特定のユーザー（パワーユーザー、または機能のチャンピオンなど）に機能をリリースできます。問題が発生していると思われる場合は、構成要素が存在するDBレコードを変更することでオフにすることができます。
特定の機能がマスターを通過したと見なされたら、トグルを削除して、アプリケーション全体の一部にすることをお勧めします。
そうは言っても、機能の分岐は悪いことではないと思いますが、ソース管理とマージの概念を理解し、分岐がメインの分岐と一致しすぎて1つの大規模なOMGタイプが発生しないようにすることに依存しています。マージ。
私は最近、Thoughtworksが主催する会議に出席し、MartinFowlerがこのトピックについて話し合いました。講演では、継続的デリバリーと、これが低速でリスクの高い展開を克服するのにどのように役立つかについて焦点が当てられました。 http://www.thoughtworks.com/events/thoughtworks-continuous-delivery-devops を参照するか、継続的デリバリーを検索して詳細を確認してください。
GitはTFSよりもはるかに優れています。私はgitを7年以上使用しており、それ以前はTFSを使用していました。最近、TFSを使用する必要がある場所で転職しました。開発ブランチがあり、すべての開発者が同じ開発に取り組んでいるだけでは、適切なレビューの機会はありません。 gitコードレビューが正式なプロセスであるという事実が大好きです。
Gitを使用して、機能/作業項目に関連するブランチを作成することにより、ローカルブランチに取り組んできました。作業が終わったら、リモートブランチにプッシュできます。次に、リモートブランチから、開発/統合ブランチへのプルリクエストを実行します。プルリクエストがレビューされると、レビュー担当者はPRをdevブランチにマージします。これは私にとって非常にうまく機能しました。
独自のブランチでマージターゲットに取り組むチームが多いほど、競合に対処するために必要なコミュニケーションが向上します。
コード内の高いチャーン、結合、および共通の領域に注意してください。それらは論争の領域になります。
機能ごとの分岐はTFSで効果的に実行できますが、開発のすべての場合と同様に、複雑になるほど、発生するオーバーヘッドが大きくなります。