私の会社はブランチをマージするのが間違っていますか？
私は最近、ブランチとマージおよびSCMに関するMSDNの記事に出くわしました： ブランチングとマージのプライマー-Chris Birmele 。
記事では、「ビッグバンマージ」はマージするアンチパターンであると述べています。
Big Bang Merge —ブランチのマージを開発作業の終わりまで延期し、すべてのブランチを同時にマージしようとします。
これは、会社が作成されたすべての開発ブランチで行っていることと非常に似ていることに気付きました。
私は非常に小さな会社で働いており、1人が最終レビュー+トランクマージ機関として機能しています。私には5人の開発者（私を含む）がいて、それぞれに個別のタスク/バグ/プロジェクトが割り当てられ、それぞれが現在のトランク（Subversion）から分岐して、分岐で開発作業を実行し、結果をテストし、ドキュメントを作成します必要に応じて、他の開発者とピアレビューとフィードバックループを実行し、プロジェクト管理ソフトウェアでレビュー+マージのためにブランチを送信します。
トランクリポジトリの唯一の権限である上司は、ブランチのすべてのレビューを、できる限りレビューを実行する単一の時点まで実際に延期します。一部のブランチは、機能拡張/修正のために戻されます。ブランチはすぐにトランクにマージされ、一部のブランチは競合などのためにスローされます。
最終レビューキューに10〜20のアクティブなブランチを配置してトランクにマージすることは珍しくありません。
また、2つのブランチが同じトランクから作成されたものの、同じコード部分を変更したため、最終レビューとマージの段階で頻繁に競合を解決する必要があります。通常、これを回避するには、トランクを再分岐して変更を再適用し、競合を解決してから、新しいブランチをレビューのために送信します（貧しい人々のリベース）。
私が持っているいくつかの直接的な質問は次のとおりです。
- 「ビッグバンマージ」と言われたアンチパターンを展示していますか？
- このマージプロセスの結果、問題が発生していますか？
- 上司のボトルネックを増やすことなく、このマージプロセスをどのように改善できますか？
編集：上司がトランクリポジトリのグリップを緩めたり、他の開発者がトランクにマージしたりできるようになるとは思いません。彼の理由が何であるかはわかりませんが、私はこのトピックを取り上げるつもりはありません。なぜなら、それは以前に取り上げられており、かなり迅速に打ち落とされているからです。彼らは私たちを信用していないだけだと思う。
この状況に関する他の洞察があれば幸いです。
いくつかの提案：
各ブランチで行われた変更が十分に小さく、結果として生じるマージの競合を効果的な方法で処理できる限り、多くの機能ブランチまたはバグ修正ブランチがあっても問題はありません。これは、MSDNの記事ではなく、作業方法に問題がない場合の基準です。
ブランチがトランクにマージされるときはいつでも、トランクはすべての開いている開発ブランチにできるだけ早くマージする必要があります。これにより、チーム内のすべての人がマージの競合を並行して解決できるようになります自分のブランチ内なので、トランクのゲートキーパーの負担がかかります。
これは、ゲートキーパーが10のブランチが「トランクにマージする準備ができている」まで待機しない場合、よりうまく機能します。最後のトランク統合からのマージ競合を解決するには、常にチームがある程度の時間を必要とするため、織り交ぜた時間間隔で作業することをお勧めします。 -ゲートキーパーによる1つの統合、チームによる1つの再統合、ゲートキーパーによる次の統合、チームによる次の再統合など。
ブランチを小さく保つには、大きな機能をいくつかの小さなタスクに分割し、それぞれのタスクを独自のブランチで開発することが役立つ場合があります。すべてのサブタスクが実装されるまで機能の生産準備が整っていない場合は、すべてのサブタスクが完了するまで 機能トグル の後ろに生産からそれを隠します。
遅かれ早かれ、コードベースの多くのファイルに影響を与えるリファクタリングタスクに遭遇します-これらは多くのブランチとの多くのマージ競合を引き起こす高いリスクがあります。それらはチームで明確に通信することで最もうまく処理でき、上で書いたとおりにそれらを正確に処理するようにしてください：再統合する前に最初にすべての開発ブランチに統合し、それらを小さなサブリファクタリングに分割することによって。
現在のチームサイズでは、単一のゲートキーパーがいる場合でも機能する場合があります。しかし、チームの規模が大きくなる場合、2人目（またはそれ以上）のゲートキーパーを配置する方法はありません。誰もがトランクにマージできるようにすることはお勧めしませんが、それは上司だけがこれを実行できることを意味するわけではありません。ゲートキーパーの仕事をするための候補者になる可能性のある1人か2人の上級開発者もいるでしょう。また、現在のチームのサイズであっても、2番目のゲートキーパーを使用すると、チームがトランクにより頻繁に、または上司が不在のときに簡単に統合できるようになります。
「ビッグバンマージ」と言われたアンチパターンを展示していますか？
そのように聞こえます。
このマージプロセスの結果、問題が発生していますか？
絶対に
上司のボトルネックを増やすことなく、このマージプロセスをどのように改善できますか？
私の会社では、すべての開発者がマージする能力を持っています。マージリクエストを別の開発者に割り当て、両方の関係者が満足するまでレビュー/フィードバック/更新サイクルを実行します。次に、レビュー担当者がコードをマージします。
マージされるのを待っている10〜20のブランチは、プロセスに欠陥があることを示しています。私たちがそれだけ多く持っていると、すべての開発作業は、それが片付けられるまで停止します。
これは本質的に、多くのオープンソースプロジェクトが機能する方法です。特にLinuxカーネルには、現在よりもはるかに多くのブランチが存在します。これらのプロジェクトでビッグバンマージを回避する一般的な方法は、継続的な統合のために別のブランチ（または複数のブランチ）を作成することです。これは、変更が同僚と連携して機能することを確認するために使用するブランチであり、ゲートキーパーがレビューに取り掛かると、定期的にトランクにリベースされます。
必要に応じて、このブランチを使用して、いくつかの独自のプルリクエストを1つの大きなまとまりのあるリクエストに結合して、上司がレビューすることができます。 Linus Torvaldsは、通常、2つ以上のレベルで統合されたプルリクエストを取得し、たとえば、完全に新しいファイルシステムドライバーのオーダーのサイズを持つことができます。
私はDoc Brownの両方に同意しますが、別のアンチパターンも確認します。
私の上司であるトランクリポジトリの唯一の権限は、実際にはブランチのすべてのレビューを単一の時点まで延期します彼ができる限りレビューを実行する場合、一部のブランチは拡張/修正のためにスローバックされ、一部のブランチはトランクにマージされます一部のブランチは競合のためにスローバックされますなど.
私の謙虚なところには、いくつかの管理アンチパターンがあります：
- 彼/彼女は、チームの速度を制限する単一のチョークポイントです。あなたの バス係数 は1です。 制約の理論 は、チェーンの最も遅い部分を改善するために努力する必要があると言います。
- 上司がフィードバックサイクルを遅くし、チームの俊敏性を低下させています。毎週リリースできますか？
- マージの複雑さは、コードの量とともに指数関数的に増加します。 1000行のうち1行ではなく、100行で10回マージすることをお勧めします。それはあなたができるだけ早くそれをしなければならない理由の一つにすぎません
- トランクで障害を検出した場合は、後ほど行います。いくつかのブランチのうちどれが問題のあるブランチでしたか
- 意思決定は、それらについてより知識のある人が行う必要があります。この場合、誰がもっと知っていますか？そのコードを作った開発者たちに違いない。
- マネージャーが休日にいる場合、本番環境のバグを修正することはできません。
- あなたは仕事をやり直し、枝を投げ返しています。これは waste の時間です。生産に至るまでの待ち時間も無駄です。
おススメ：
- あなたの上司はチームに責任を委任する必要があります。チームが成熟していてプロフェッショナルであることを示す必要があります。チームを信頼できることを明確にする
- いくつかのレビューメソッドを実装します。他の2人のチームメンバーの承認が必要な場合があります。
- SVNを使用していることが困難になっている可能性があります。 Gitを試して、それが役立つかどうかを確認してください。さらに。 GitHubを使用する場合は、プルリクエストメカニズムを使用して、マージで特定の投票が必要になるようにすることができます。
- アジャイルプラクティス、継続的な統合、DevOpsに関する情報を読んで共有します。
別のブランチで機能の作業を行う場合、ブランチの1つがトランクにマージされて他の機能ブランチにプルされるまで、統合テストを簡単に行うことはできません。私の経験では、これがビッグバンマージアンチパターンの主な問題です。理想的には、機能の作業を行い、機能ブランチでテストし、トランクにマージし、その時点で機能を使い終えます。マージされていない場合は、トランクの前に何かがマージされるたびに再検討する必要があります。このアンチパターンの問題点は、開発サイクルの最後に統合型のバグがたくさんあることです。
つまり、20のブランチがあります。ブランチ1がマージされました。次に、ブランチ2の開発者は、ブランチ1をブランチにマージして、競合なしでメインにマージできるようにしてからマージする必要があります。次に、ブランチ3の開発者は、ブランチ1とブランチ2をブランチにマージして、競合なしでメインにマージできるようにしてからマージする必要があります。
読者のための演習：私の完全な投稿を出力するプログラムを書く:-)
これは狂気です。あなたはマージに信じられないほどの時間を費やします。
あなたが働いている方法とあなたの上司が責任あるコントロールのフリークであることを考えると、ブランチ自体が問題のようです。すべての機能のブランチを作成するのではなく、各開発者に機能を部分的に、トランクに直接コミットしてもらいます。これにより、複数の小さなステップ（win-win）で開発者に統合の負担がかかります。ゲートキーパーは、開発サイクルの早い段階で、より小さな期間に小さな変更を追跡し続けることができ、それでもマスターレビュー担当者であることができます。
分岐自体は、それを実行する十分な理由がない限り、または他に選択肢がない場合を除き、実行したくないものです。あなたは物事をよりしっかりと同期させるのに十分なほど小さいので、より簡単で安全になります。