フィーチャーブランチ

GitやMercurialなどの分散バージョン管理システム（DVCS）の急増に伴い、分岐（マージ）およびマージ（マージ）の適切な使用、およびこれが継続的統合（CI）の概念にどのように適合するかについての議論が増えています。 この問題については、特に機能の分岐とCIのアイデアとの関連性に関して、いくつかの混乱があります。

シンプル（分離）機能ブランチ

機能ブランチの主なアイデアは、何らかの機能の作業を開始するときに新しいブランチを作成することです。 DVCSでは、独自のリポジトリでこれを行いますが、同じ原則が集中型VCSで機能します。



次の一連の図で私の考えを説明します。 その中で、メインの開発ライン（トランク）は青でマークされ、2人の開発者は緑と紫でマークされています（Reverend GreenとProfessor Plum）。











ブランチのローカルコミットの指定として、指定された色付きの四角形を使用します。 ブランチ間の矢印は合併を示し、オレンジ色の長方形はマージ自体を強調しています。 この例では、メイン行に更新があります。たとえば、いくつかの修正されたバグがあります。 これが発生すると、開発者はそれらをローカルブランチにマージします。 時間の感覚を得るために、各開発者が自分の変更を1日に1回コミットする数日間の作業について話していると仮定しましょう。



コードが機能することを確認するために、ブランチでビルドとテストを実行できます。 この記事のフレームワークでは、各コミットとマージとともに、それが実行されたブランチの自動ビルドとテストを想定しています。



機能分岐の主な利点は、各開発者が自分のタスクに取り組むことができ、周囲で起きていることから隔離できることです。 メインラインからの変更を自分のペースでマージし、これが開発中の機能に干渉しないことを確認できます。 さらに、これにより、チームはリリースする新しい開発を選択し、後で残すものを選択できます。 グリーン牧師が遅れた場合、プラム教授の変更を含むバージョンのみを提供できます。 または、逆に、教授が希望どおりに機能するかどうかわからないために、教授の追加を延期することができます。 この場合、機能をリリースする準備が整うまで、教授に変更をメインラインにマージしないように依頼するだけです。 このアプローチにより、選択する機会が与えられ、チームは各リリースの前にどの機能をマージするかを決定します。



この画像の魅力にもかかわらず、このアプローチには特定の問題が潜んでいる場合があります。







開発者は機能を単独で作業できますが、ある時点で、作業の結果を統合する必要があります。 この例では、Plum教授はメインラインをその変更で簡単に更新します。ブランチではメインラインのすべての変更を既に受け取っている（そしてビルドに合格している）ため、マージはありません。 ただし、グリーン牧師にとってすべてがそれほど単純ではないため、彼はすべての変更（G1-6）をプラム教授の変更（P1-5）にマージする必要があります。



（この例では、多くのDVCSユーザーは、機能分岐のこのような単純な、さらに簡単な説明では多くの詳細が欠けていると感じるかもしれません。より複雑なスキームについては後で説明します。）



これは危険なマージなので、このマージ長方形を巨大にしました。 問題なく実行でき、開発者が相互作用なしにコードのさまざまな部分で作業したため、マージがスムーズに行われる可能性があります。 しかし、彼らは相互作用する部分に取り組むこともでき、それから地獄は彼らを待ちます。



悪夢は多くの形をとることができ、開発ツールはいくつかを救うことができます。 最も標準的なものは、2人の開発者が同じテーマの同じファイルで作業しているときに、ソースコードをマージするのが難しい場合があります。 現代のDVCSはそのような問題にうまく対処しますが、時には魔法の助けがなければそうではないようです。 Gitは、複雑な競合をうまく処理できるツールとして評判があります。 とても良いので、この質問はこの記事の範囲外です。



さらに気になる問題は、セマンティックの競合です。 最も単純な例は、Plum教授がGreen牧師がそのコードで呼び出すメソッドの名前を変更する場合です。 リファクタリングツールは、コード内でのみ問題なくメソッドの名前を変更するのに役立ちます。 したがって、G1-6にfooを呼び出す新しいコードが含まれている場合、Plum教授はそれを認識しません。この変更はブランチにないためです。 犬が埋葬されている場所の認識は、大規模なマージでのみ私たちに来ます。



関数の名前の変更は、セマンティックの競合の最も明らかな例です。 実際には、彼らははるかに秘密にすることができます。 テストはそれらを解決する鍵となりますが、より多くのコードをマージする必要があるほど、競合の可能性が高くなり、それらを修正するのがより難しくなります。 一般的に、特にセマンティックの競合のリスクは、大規模な合併を怖がらせます。



大規模な合併の恐れの結果は、リファクタリングへの抵抗です。 コードをきれいに保つには、絶え間ない努力が必要であり、成功するためには、誰もがそれを見たときにゴミをきれいにしなければなりません。 ただし、機能ブランチでのこのようなリファクタリングは、Big Scary Mergeをさらに大きく悪化させる限り、問題があります。 その結果、開発者は火のようなリファクタリングを恐れており、コードはフリークで大きくなりすぎています。



上記の問題では、機能の分岐が悪い考えである主な理由がわかります。 チームが健全なコードを維持するためのリファクタリングを恐れている瞬間-彼らは優雅な出口のチャンスがない長いピークにあります。

継続的インテグレーション

継続的な統合が解決するのはこれらの問題です。 CIを使用すると、グラフは次のようになります。





ここにはさらに多くのマージがありますが、マージは、めったになくトン単位で行うよりも少しずつ頻繁に行う方がよいものの1つです。 その結果、Plum教授がGreen牧師が依存するコードの一部を変更した場合、私たちの緑の同僚はP1-2マージでもっと早く発見するでしょう。 現時点では、（前の例のように）G1-6ではなく、これらの変更に対応するためにG1-2を変更する必要があります。



CIは、大規模なマージの問題を中和するのに効果的ですが、重要な通信メカニズムでもあります。 このシナリオでは、プラム教授がG1を統合し、グリーン牧師が教授のライブラリを使用していることを認識すると、潜在的な競合が発生します。 その後、プラム教授はグリーン牧師を見つけることができ、一緒に彼らの機能の相互作用について議論することができます。 おそらく、Professional Pum機能には、Reverend Green機能とうまくいかないいくつかの変更が必要です。 一緒に、彼らは彼らの仕事を妨げない、はるかに良い設計上の決定を下すことができます。 ブランチを分離すると、開発者は問題を最後の瞬間まで知ることができなくなります。最後の瞬間、問題を解決するのに手遅れになることがよくあります。 通信はソフトウェア開発の重要な要素の1つであり、CIの主な機能の1つはそれを促進することです。



ほとんどの場合、機能の分岐にはCIへの異なるアプローチがあることに言及することが重要です。 CIの原則の1つは、誰もが毎日メインラインにコミットすることです。したがって、機能ブランチが1日以上存在する場合、CIから非常に遠い何かに変わります。 ビルドがCIサーバー、各ブランチ、およびすべてのコミットで実行されるため、CIを使用していると人々が言うのを聞きました。 これは継続的なビルドであり、優れていますが、 統合されていないため、CIではありません。

無差別な統合

先ほど括弧で述べたように、分岐を機能させる方法は他にもあります。 イテレーションの最初にプラム教授とグリーン牧師が一緒に香り豊かな緑茶を醸造し、彼らの仕事について話し合ったとしましょう。 彼らは、タスクの中に相互作用する部分があることに気付き、次のように相互に統合することを決定します。







このアプローチでは、最初の例のように、最後にメインラインとマージしますが、大きな怖いマージを回避するために互いにマージすることもよくあります。 機能の分岐の主な利点は分離であるという考え方です。 ブランチを隔離すると、知識の範囲外で下劣な競合がエスカレートするリスクがあります。 そして、孤立は幻覚であり、遅かれ早かれ痛みを伴います。



しかし、このより労働集約的な統合はCIの一形態なのでしょうか、それともまったく異なる獣でしょうか？ 繰り返しますが、CIの重要な特徴は、誰もが毎日メインラインと統合していることです。 機能ブランチ間の統合（私はあなたの許可を「無差別統合」（PI）と呼びます）には、メインラインは含まれません。 この違いは非常に重要だと思います。

CIは、主にコミットのたびにリリース候補者を生む手段と考えています。 CIシステムと展開プロセスのタスクは、現在のリリース候補版の制作準備を反論することです。 このモデルには、全体像の現在の状態を表すある種の基本的な開発ラインが必要です。



- デイブ・ファーリー

ランダム統合と継続的統合

それでも、PIがCIと異なる場合、どの場合にPIはCIより優れていますか？



CIを使用すると、バージョン管理システムを使用して変更を選択的に行うことができなくなります。 各開発者はメインラインに影響を与えるため、すべての機能がメインラインで成長します。 CIでは、メインラインは常に正常である必要があり、理論上（そして実際には多くの場合）、各コミット後に解放できます。 半完成の機能、またはリリースしない機能を使用すると、システム全体の機能を損なうことはありませんが、メニューに新しいアイテムを含めないなど、ユーザーインターフェイスから非表示にするために何らかの変装が必要になります。



そのような場合、PIは中間の何かを提供できるため、グリーン牧師はプラム教授の変更をいつ受け入れるかを選択できます。 Plum教授がP2のカーネルAPIに変更を加えた場合、グリーン牧師はP1-2をインポートできますが、Plum教授が作業を終了してメインブランチにマージするまで残りを残すことができます。



ただし、一般的に、VCSを使用してリリース用の機能を取得することは良い考えだとは思いません。

機能の分岐は貧しい人々のためのモジュール式アーキテクチャであり、機能を時間/展開で簡単に置き換えることができるシステムを構築する代わりに、人々は手動でマージすることでこのメカニズムのソース管理にバインドします。



- ダンボダート

構成を変更して機能をオンまたはオフにできるように、ソフトウェアを設計することを好みます。 これには、 FeatureTogglesとBranchByAbstractionの 2つの便利なテクニックがあります。 モジュールに分割する方法と方法、およびこれらのオプションを制御する方法についてさらに考える必要がありますが、VCSに依存している場合よりも結果がはるかに正確であるという結論に達しました。



PIで最も気にかかるのは、チームのコミュニケーション能力にさらされていることです。 CIでは、メインラインが通信ポイントとして機能します。 プラム教授とグリーン牧師が一度も話さなかったとしても、彼らはその形成の日に対立を見つけるでしょう。 PIでは、相互作用するコードに取り組んでいることに注意する必要があります。 常に更新されるメインラインは、彼がすべての人と統合していることを全員に保証するのに役立ちます。誰が何をしているのかを知る必要はありません。



PIはオープンソースから生まれたもので、おそらく、オープンソースプロジェクトのペースがそれほど速くないことがその要因かもしれません。 フルタイムの仕事では、プロジェクトで1日何時間も働きます。 これにより、機能を優先して作業することができます。 オープンソースでは、多くの場合、人々はここで1時間、そこに数日寄付します。 機能の実行には1人の開発者の実行に多くの時間がかかりますが、多くの空き時間がある他の開発者は、変更を許容可能な品質に早めることができます。 このような状況では、選択的なアプローチがより重要になる場合があります。



使用するツールは、選択した戦略に依存しないことを認識することが重要です。 多くはDVCSを機能の分岐に関連付けていますが、CIでも使用できます。 必要なのは、ブランチの1つをメインラインとしてマークすることだけです。 誰もが毎日このブランチにプルアンドプッシュする場合、最も基本的なラインがあります。 実際、よく統制されたチームでは、集中型VCSよりもCIプロジェクトにDVCSを使用します。 統制のとれていないチームでは、DVCSを使用すると、一元化されたVCSとブランディングの複雑さがメインラインへの頻繁なコミットに追い込まれるときに、人々を長命ブランチに押しやるのではないかと心配します。



PS この記事 は翻訳者から、 VCSを使用するアプローチへの質問を研究 する ように促しました。おかげで、分岐の「正しい」使用の詳細な説明を探し始め、上記の翻訳されたテキストに出会いました。 私は質の高い翻訳者のふりをするつもりはありませんが、開発者へのフィードに入り、オープンソースのアプローチ（フォーク）の反対について考える理由を与えたいだけです。 棒で打たないで、建設的に批判してください、これは私がそれをするのは初めてです:-) 。