💊 🍮 👩🏾‍🚒 ThreeFlowの分岐戦略 ♟️ 🤰 🥂

ソフトウェア開発のさまざまな側面に関する同僚との私の会話の中で、1つのトピックが他のトピックよりも頻繁にポップアップします。よくあるのは、ハッキングされたレコードのように何度も繰り返されるものです。これらは、GitFlowがなぜ悪いのか、なぜ避けるべきなのかというトピックに関する会話です。

後に「GitFlow」と呼ばれるメソッドを説明する記事「A Successful Branching Model for Git 」は、プロジェクトでGitを使用する方法の事実上の標準になりました。 Googleで「 git branching strategy 」のようなものを検索する場合、この方法は最初のリンクで説明されます（ほとんどの場合、次のリンクで説明されます）。

個人的には、GitFlowが嫌いです。過去数年にわたって、多くの開発チームにGitFlowの使用をやめるよう説得してきました。 GitFlowを使用すると、チームはコード変更管理を組織化できますが、実装することはできません。しかし、これは（少なくとも検索エンジンの結果では）このような一般的な方法であるため、十分な経験のないチームが「何か、少なくとも何らかの形で機能する」を探しているチームは、クイック検索でそれを見つけ、さらに「成功」という単語を見つけます記事のタイトルにその説明が記載されています-まあ、彼らはそれを考えずに使い始めます。この記事では、多くのチームで実装したGitブランチを使用するための、よりシンプルで劣らず成功した戦略を説明することで、この動作パターンを少なくともわずかに変更したいと思います。多くの場合、これらのチームはGitFlowを使用しようとしましたが、ThreeFlowへの移行とともに消える問題を経験しました。

厳密に3つのブランチがあるため、この戦略をThreeFlowと呼びます。 4つではありません。 2つではありません。三。

まあ、ただの警告：特効薬はなく、ThreeFlowも万能薬ではありません。常に適切とは限りません。組み込み開発やオープンソースプロジェクトではうまく機能しないと思います。しかし、プロジェクトチーム全体が1つの会社で働いており、外部開発者からのプール要求がない状況では非常に成功します。すなわちチームの全員がコードに完全にアクセスでき、リポジトリに書き込むために必要なすべての権限を持っています。

それでは、GitFlowの何が問題になっていますか？

要するに、GitFlowの何が問題なのかは、開発中の機能ごとにブランチを作成するという彼のアイデアです。機能のブランチは悪の根源です。これらのブランチが提供するものはすべて、問題、問題、そして再び問題です。この記事から有用なものがまったく得られない場合、またはここで読むのをやめる場合は、機能ブランチがひどいという考えを覚えておいてください。

公平を期すために、元の記事では機能のブランチについて説明していることに注意してください。これらは「通常、個々の開発者のマシンにのみ存在し、メインリポジトリ（オリジン）には存在しません」。しかし、同じ記事で、GitFlowを説明する図はそれを異なって示しています。機能ブランチには「起源」があります。さらに、多くの開発チームがGitFlowを使用していることを確認しましたが、別々の開発マシンでのみブランチを使用するという著者の推奨に注意を払っていませんでした。私が見たすべての人は、起源に存在する長期的なツールとして機能ブランチを使用しました。

一般的に、マシンの機能のブランチを作成しても問題はありません。これは、プロジェクトで複数のタスクを同時に処理する必要がある場合にタスクを切り替えるのに適した方法です。これは、すべての作業をリモートリポジトリと同期させることなく小さな修正を行う必要がある場合に、マスターブランチをクリーンに保つための良い方法です。しかし、元のGitFlowの推奨を超えて、元の機能ブランチの作成を厳しく禁止します。

個々の機能に長く存在するブランチを使用する場合、それらの統合の地獄はあなたの絶え間ない現実になります。 2人のエンジニアがそれぞれ独自の機能で、それぞれ独自のブランチで正常に作業を行っていますが、トラブルを引き起こすものは何もありません。しかし、どちらか一方が他方の作業を見ることはありません。ブランチをメインの開発ブランチと定期的に同期している場合でも、既に完了して染色された機能のコミットのみが表示され、互いの現在の作業は表示されません。そして、開発者Aは自分の機能の開発を終了し、メインブランチにコードを注入します。開発者Bはこれらの変更をピックアップし、「最後に競合する人は誰でもかまわない」という古典的な問題を取得します。彼はほんの1分間遅れていたかもしれませんが、ここで彼はここで開発者Aが書いたものと、それをすべて遅くする方法を理解しようとして何時間も費やします。そして、この「分離された」開発が別々の機能ブランチで実行される時間が長くなればなるほど、マージに伴う痛みと苦しみは大きくなります。

機能の既存のブランチは、作業を単純化するものではありません。後で問題を先送りするだけです。開発者間のコミュニケーションの主な形式は、ソースコードです。定期的な立ち上げ、会議の計画、回顧などで好きなだけ自分を慰めることができますが、これは重要ではありません。オーケストラのリハーサルを想像してみてください。ミュージシャンは長い間、どのように曲を演奏するかを話し合いますが、その後、指揮者は部屋に分散してそれぞれのパートをリハーサルするよう依頼します。そのようなリハーサルには意味がありますか？したがって、ソフトウェア開発に伴います。機能ブランチでの作業は、本質的に開発者間のコミュニケーションにおける致命的な沈黙に類似しています。機能のブランチはひどいです。

さらに、機能ブランチは非常にスケーラブルです。自分の快適さのために機能ブランチを作成する開発者は問題ではありません。しかし、あなたのチームは成長しており、各開発者は活発に開発している機能ごとにブランチを持っています。おめでとうございます、あなたは今、ブランチの各ペアに問題を抱えています。プログラマーを8人だけにして、それぞれがブランチの1つの機能だけで動作するようにします。そして今、あなたは28（ペアの数）の壊れた通信回線を持っています。開発者をもう1人、ブランチを1つ追加しました。現在、36の「崖」があります。

フラグを使用して機能を有効にする

ブランチを使用して機能を開発する代わりに、フラグを使用して機能をオンまたはオフにしてみてください。簡単です。ブールフラグを宣言することにより、新しい機能の開発を開始します。それに応じて、それが含まれます。デフォルトでfalseに設定します。この場合、新しい機能のコードなしで古いコードを呼び出します。

if(newCodeEnabled) { //   } else { //   }

フラグ自体は、コードにハードコーディングするか、外部構成に転送することができます（おそらくConsulやZookeeperのようなものを使用します）。これにより、テストや実稼働でも新しい機能を有効または無効にできます。プロジェクトマネージャーと顧客は、開発者を引き付けたり、プロジェクトを組み立て直したりする必要なく、自分自身でオンまたはオフにできる機能のリストを備えた製品コントロールパネルを見ることを非常に好みます。

2人の開発者が異なる（異なる）機能で同じ（メイン）ブランチで作業する場合、それぞれのフラグを作成します。そして、彼らは定期的にコードをコミットするだけです。この場合の競合の可能性は最小限です。誰でも適切と判断したコードをコミットできます。誰もが自分のローカルリポジトリをメインリポジトリと同期できます-非同期は最小限に抑えられます（確かに1営業日以内）。競合はまったくないか、最小限に抑えられます。 GitFlowが提供するように、数日または数週間でグローバルな変更を行うよりも、過去1時間でこの10行で同僚が何を変更したかを理解する方がはるかに簡単です。

そして、はい、もしあなたがコードのテストを書いたら（そして、あなたが書いたのですか？）、フラグを無効にしたコードブランチとフラグがオンになっているブランチの両方をテストする必要があります。相互に依存する2つの機能が開発されている場合、開発時には、すべての組み合わせに対して4つのテストが必要になります。これは、開発を複雑にして速度を落とす脅威のように聞こえますが、新機能の開発後に「古い」コードブロック（およびそれらのテスト）が削除されることを忘れないでください。そうすれば、幾何学的な複雑さが増しません。

新機能のフラグをより動的に使用できます。ベータテストまたはA / Bテストのために、それらを特定のユーザーグループにリンクできます。

機能の開発が完了し、本番環境でデフォルトで有効になったら、古いコードとフラグ自体を削除するために、優先度の低い小さなタスクをスケジュールできます。または、何らかの理由で機能を無効にしたい場合（新しいコードの安定性の問題、バックエンドの負荷調整）、これを行うことはできません。いずれにせよ、フラグと古いコードを削除または残すことを意識的に決定することが重要です-それを忘れると、コードはやがて開発者の気を散らすだけで実際の利益をもたらさない古い未使用の機能のコケに成長します

新しい機能を組み込むためのフラグアプローチの価値は、過小評価されています。機能のブランチではなく機能のフラグを使用し始めるとすぐに、戻りたくないことを保証します。私の記憶では、ほとんどの場合、遅かれ早かれ独立した長寿命ブランチでの大きな新機能の開発は、何人かのプログラマーの注意とGitの深い知識を必要とする問題につながりました。同時に、同じブランチで作業し、新しい機能のフラグを立てるというアプローチでは、1人で数分で解決できなかった競合は発生しませんでした。

だからThreeFlow

そこで、機能のブランチが悪い理由と、それらを置き換えることができるものを見つけました。これからThreeFlow分岐モデル自体について説明できます。

このアプローチでは、すべての開発者が1つのマスターブランチで作業します。機能が簡単な場合、1回のコミットで実装および追加されるだけです。機能の開発に時間がかかる場合は、最初にフラグ（デフォルトでは無効）が追加されてアクティブになります。開発者はこのフラグをローカルで有効にして新しい機能を開発およびテストしますが、メインリポジトリのコードは依然として「古い」コードブランチを使用します。コミットをマスターに追加するには、リベースが使用されます。ローカルブランチを使用して機能を操作する場合、マスターに移動する必要があります。そのため、元々このブランチの痕跡はありません。

以上です。そして、開発プロセス全体が行われます。 1つのブランチ、マスター。その中のすべてのコード。必要なものはすべてフラグでオンまたはオフになります。すべての開発者は同じコードを持ち、多くの場合互いに同期しています。 ThreeFlowの他のすべては、開発ではなくリリース戦略に関するものです。

リリース

リリース時刻が来ると（スケジュールどおり、またはマニュアルに記載されている場合）、マスターブランチの「スライス」がリリース候補ブランチになります。同じブランチがすべてのリリース候補に使用されます。

このブランチの目的は、リグレッション（およびその他の）テストを実行するためにQAチームが受け取るビルドを提供することです。理論的には、このリリース候補の新機能は、開発と組み込みの過程ですでにQAによってテストされていますが、おそらくQAはリリース候補でそれらを再確認したいと思うでしょう。

リリース候補を作成するには、次のようにします。

 $ git checkout candidate # ,  candidate   origin/candidate $ git pull # ,       $ git merge --no-ff origin/master $ git tag candidate-3.2.645 $ git push --follow-tags

ここで--no-ffフラグを使用する理由は、マージコミット（2つの親を持つ新しいコミット）を作成するためです。彼の両親の1人はリリース候補ブランチの前のHEADであり、2番目はマスターブランチのHEADです。これにより、誰がいつリリース候補を作成したか、何が正確に何になったのか（masterブランチのコミット）の履歴を簡単に追跡できます。

また、リリース候補のタグを作成したことにお気づきかもしれません。これについてもう少し。

リリース候補のテスト中にバグが検出された場合、それらはリリース候補ブランチで修正され、そこで新しいリリース候補がマークされ、修正された変更がマスターにストールされます。また、ブランチ間でどのコードが移動されたかを正確に表示するため、これらの変更は「--no-ff」パラメーターで適用する必要があります。

リリース候補がテストおよび承認されると、そのHEADがHEADリリース候補ブランチを指すようにリリースブランチを更新します。リリース候補ごとにタグがあるため、リリースブランチにプッシュするだけです。

 $ git push --force origin candidate-3.2.647:release

ここでの「--force」パラメーターは、リリースブランチのすべての変更を無視し、HEADを同じコミットに強制することを意味します。これは、リリース候補の最後に作成されたタグを示します（上記の例ではcandidate-3.2.647）。これはマージではありませんが、それはここでは必要ないためです。 Gitの話を複雑にしたくはありません。一般に、リリースブランチを作成する唯一の理由は、実稼働環境で見つかった重大な問題に対する緊急修正の理論的な必要性です。はい、この「--force」はリリースブランチのすべてのホットフィックスを消去します。ただし、新しい機能を備えた製品の次のバージョンを同時にリリースし、チームの別のメンバーが本番環境のバグを修正すると、プロジェクト管理とコミュニケーションに重大な問題が生じます。これらは、ブランチやリリースを中心としたこれらすべてのダンスの開始前であっても解決する必要があります。リリースブランチでの修正は非常にまれであり、当然、リリース候補とマスターブランチで停止する必要があります。

マージの代わりに--forceを使用する理由は、HEADリリース候補ブランチのマージコミットとHEADリリースブランチのコミットが異なるsha-1を持つ可能性があるためです。これは必要なものではありません。リリースで新しいコミットを作成するのではなく、リリース候補者によって選択された正確なコミットをリリースと呼びます。これは、QAチームによってテストされ、この責任者によってリリースが承認されました。これがまさに「--force」の機能です。

これらの推奨事項に従えば、gitリポジトリのストーリーは上の図と非常によく似たものになり、ブランチ間で移動したコミットを正確に示します。

リリースノート

新しいリリースの「リリースノート」を簡単に生成できます。必要なのは、最後のリリースタグと現在のリリース候補タグの違いを取得することだけです。リリースブランチには、かつてリリース候補だったものがありますので、どれを見つけることができます：

 $ git describe --tags release candidate-3.1.248

リリース候補に候補-3.2.259があることがわかったので、次の2つのタグの違いを取得できます。

 $ git log --oneline candidate-3.1.248..candidate-3.2.259

さて、またはタグがなくても、リリースのHEADと候補ブランチを比較するだけです：

 $ git log --oneline release..candidate

該当する操作

ThreeFlowで作業するときに一般的に使用される操作を次に示します。すべての例は、ローカルブランチがリモートブランチに正しく関連付けられており、現在の変更が含まれていることを前提としています。これについてよくわからない場合は、もう一度git fetchを実行し、masterだけでなくorigin / masterなどの名前を使用することをお勧めします

masterブランチからリリース候補を作成するにはどうすればよいですか？

 $ git checkout candidate $ git pull $ git merge --no-ff master $ git tag candidate-3.2.645 #optionally tag the candidate $ git push --follow-tags

リリース候補からリリースするにはどうすればよいですか？

 $ git push --force origin <tag for the candidate>:release

何らかの理由でリリース候補にタグを付けないことにした場合、次のことを行う必要があります。

 $ git push --force origin candidate:release

特定のコミットを持つブランチを見つけるにはどうすればよいですか？

特定の変更がリリース候補またはリリースに含まれることを確認したい場合があります。確認方法は次のとおりです。

 $ git branch -r -contains <sha of commit>

ブランチでHEADが指すタグを見つけるにはどうすればよいですか？

 $ git describe --tags <branch>

新しいリリースに含まれるコミットを知るにはどうすればよいですか？

 $ git log --oneline release..<tag of release candidate>

または：

 $ git log --oneline release..origin/candidate

リリース候補とリリースブランチを設定するにはどうすればよいですか？

すべてのプロジェクトは、最初のコミットから始まります。これは通常、readmeファイルを追加するような単純なものです。このコミットからリリース候補とリリースブランチを作成することをお勧めします。取得する必要があるのは、2つの親との最初のマージコミットです。これにより、正しいストーリーが得られます。そのため、一般に、masterブランチのコミットが適切です。最初のものを取りませんか？

 $ git branch candidate `git log --format=%H --reverse | head -1` $ git checkout candidate $ git push

リリース用のブランチを作成するには：

 $ git branch release $ git branch release --set-upstream-to=origin/release

ご質問

しかし、これは「サボテンモデル」ではありませんか？

この記事で説明されている分岐戦略は、Jussi Judinによって説明された「GactFlowの代替として、またすべての作業にmasterブランチを使用する」「サボテンモデル」に非常に似ていると思われるかもしれません。はい、大部分はそうです。主な違いは、Judinがコミットをmasterブランチからreleaseブランチに選択的に移動することを提案していることです（「チェリーピック」）。私はこれに断固として反対しています。コミットの選択的な移動は、マスターのいくつかの絶対に壊滅的な状態と緊急リリースの大きな必要性で最後に使用されるべき極端な手段です。マージよりもリベースを使用することを好みます。そして、選択性を避けます。

もう1つの違いは、ThreeFlowにリリース候補のブランチが存在することです。これは、必要最小限の悪として受け入れています。個人的に、私の目標は、各コミットで指を突いてすぐに運用に移せるような状態にmasterブランチを維持することです。しかし、多くのチームにとって、このモードで作業するのは難しく、不快であることに気付きました。人々はQAチームの形でバッファを用意し、開発者に承認されたビルド（「悪いものではなく、これを取得する」）を与え、その品質についてフィードバックをもらう必要があります。また、ThreeFlowモデルはその機会を提供します。製品の品質に慎重に適したチームでは、リリース候補とリリースブランチの違いは最小限になります。

しかし、GitFlowは機能の分岐なしで説明されているだけではありませんか？

実際、以前に同様の方法でGitFlowを使用していた人々にこの戦略を説明しました。「機能にブランチを使用せず、すべての開発は開発ブランチで行われ、これをマスターと呼び、マスターと呼ばれるものをブランチと呼びます。リリース。」 ThreeFlowの主なアイデアは、複雑さを最小限に抑えることでした。 GitFlowは、何らかの理由（機能、リリース、ホットフィックス）で新しいエンティティ（ブランチ）の作成を推奨します。プロジェクトが大きく、時間が長くなればなるほど、その歴史はひどく見えます。 ThreeFlowは、ブランチの数を最小限に抑えるよう努めています。機能またはホットフィックスのブランチはありません。機能はウィザードで記述され、修正プログラムはリリース候補、またはリリースにも適用されます。また、多数のリリースブランチの代わりに、現在のリリース候補および現在のリリースと呼ばれるものが常にあります。 3つのブランチのみ。常に。

また、ブランチネーミングシステムを作成する必要はありません（そのうち3つしかなく、名前は一定です）：マスター、候補、リリース。

「私のコードをどこに置くか？」という質問には常に答えがあります。これが生産上の問題のホットフィックスである場合-リリース。これがリリース候補のバグ修正である場合、候補にあります。これが通常の日常業務の場合-マスター。

コードレビューはどうですか？

メインの開発ブランチに到達する前にすべてのコードをレビューするルールがある場合は、別のブランチを追加するのが論理的です（開発と呼びましょう-はい、この名前をGitFlowから盗んでください）。そのため、すべての開発がその中に入り、レビュアーは承認されたコミットをそこからマスターに転送します（まあ、またはファイナライズを依頼します）。もちろん、転送されたものと転送されなかったものを何らかの方法で追跡する必要があり、これは困難を引き起こす可能性があります。 ThreeFlowを使用する場合、メインブランチにコミットする前にコードレビューの概念を厳守することはチームにとってうまくいかないか、このアプローチのさらなる適応が必要になることを認めなければなりません。 Gerritのようなツールを同様の目的で使用している人がいると聞きましたが、私自身は使用したことがありません。

複数のアーティファクトを保存するコードベースはどうですか？

多くの場合、コードは実際には1つのコードベースに格納され、そこから複数のプロジェクトを組み立てることができます。これらの個々のアセンブリ成果物には、QA部門による別個の検証サイクルが必要であり、リリース候補の別個のバージョンがあります。この場合、ThreeFlowはどのように機能しますか？

うまくいきます。ごく最近、私はかつて同様のプロジェクトで働いていました。いくつかの異なるアーティファクトが収集およびデプロイされたGitリポジトリが1つありました。解決策は明らかです。各アーティファクトはリポジトリに2つのブランチを追加します。マスターですべてのコードを記述し、無効化されたフラグを使用して機能を操作します。これを行うために、リポジトリから収集されるアーティファクトの数と数を知る必要はありません。しかし、ここではリリースになり、各アーティファクトには、リリース候補とリリースのための独自のブランチが必要です：foo_candidate、foo_release、bar_candidate、bar_release。以上です。

それはあなたが思っているよりも優れています。私の最近のプロジェクトの1つでは、1つの大きなコードベースから4つの異なるアーティファクトが収集されました。いくつかの一般的なコード、サブプロジェクトごとに個別のもの-わかりました。一方で-リリース候補とリリース用の8つのブランチと、1つのマスター。しかし、一方で、各アーティファクトには独自の個別のチームがあり、各アーティファクトには3つのブランチのみが関連していたため、それらの総数はほとんど関係ありませんでした。

Gitコマンドへの追加の引数セットをどうにかして回避できますか？

提案されたアプローチの特徴の1つは、使用されるほぼすべてのチームが追加の引数を持っていることです。マージを行うたびに、「-no-ff」を忘れずに追加してください。リリースを作成してタグを付けるときは、タグを元の場所に保存するためにプッシュするときに「--follow-tags」を使用することをお勧めします。デフォルトでこれらのタグを適用できます：

 $ git config --global merge.ff no

これで、「-no-ff」パラメーターなしでmergeコマンドを使用できます（暗黙的に追加されます）

同様に、プッシュ時のタグの場合：

 $ git config --global push.followTags true

プル時に自動リベースを構成することもできます。

 $ git config --global branch.master.rebase true

ローカルブランチを使用して個々の機能を操作する場合、プルするときにすべての新しいブランチを自動的にリベースすることもできます：

 $ git config --global branch.autosetuprebase always

これらのルールを現在のリポジトリのみに適用し、全員には適用しない場合は、上記のコマンドから「--global」キーを削除することもできます。

リリースブランチにマージを使用できますか？

まあ、まず第一に、あなたは自由な人であり、あなたは何でもしたいことができます。私と他の一部の人にとってうまく機能する戦略を説明しています。私には、GitFlowよりも優れているようです（単純なため）。

第二に、はい、-forceキーを押して履歴情報の一部を失うという考えが気に入らない場合は、-no-ffキーとマージできます。ここでのプラスは、ブランチ間でコミットを転送するさまざまな方法を覚えておく必要がないことです。自分自身をマージするだけです--no-ffは常に、それだけです。

実際、ThreeFlowの最初のバージョンでは、リリースの--no-ffパラメーターとマージして、まさにそのような動作を説明しました。それはうまくいきました、物語はよく読まれました。私が気に入らなかった唯一のことは、リリースブランチからのビルドアーティファクトが、以前はリリース候補と見なされ、QAとリリース承認を経た正式なコミットではなかったことです。あることをテストしてから、別のことをして、この別のことをリリースしたことがわかりました。残念だ。もちろん、合併を高速転送に置き換えることもできますが、これは情報の損失につながり、成功することが保証されているという事実でさえありません。

私の意見では、push + forceは、リリースの内容が実際には継承されたコミットのチェーンの用語の分岐ではなく、そのように解釈されるべきではないことをより明確にします。これは、現在実稼働で動作している実際のコードへの単なるポインターです。また、リリースブランチ自体は、かつて本番環境でレイアウトされていた一連のタグを指しているだけです。さて、これは現在のコードのブランチであるため、いつでもすぐに本番用のホットフィックスを作成できます。

まとめると

一貫した分岐戦略なしでGitを使用することは危険なビジネスです。だから、これを取る：

マスター、候補、リリースの3つのブランチがあります
マスターで働いています。すべての新しいコミットは、リベースを使用して追加されます。
開発プロセスの機能はフラグによって無効にされます。準備ができたら点灯します。
- — master (merge "--no-ff") candidate
, QA -, ( merge "--no-ff") master
- , "--forced" release
release candidate master

以上です。 ThreeFlow Git, .

? ? , "--force" , ? !

ThreeFlowの分岐戦略