Git Flowの推奨はもう止めましょう!

George Stocker    
チームがテスト駆動開発を通じて、より良いソフトウェアを、より速く提供できるようにすることを使命とするソフトウェア技術者。
この記事は、著者の許可を得て配信しています。
https://georgestocker.com/2020/03/04/please-stop-recommending-git-flow/

Git-flowはこのブログで投稿された人気のあるブランチおよびマージ法であり、「A Successful Git branching model」というタイトルがつけられています。

過去10年間で無数のチームは見出しにだまされ、あえて言わせてもらうとごまかして来たと言えるでしょう。

投稿されたブログを読めば、著者はみなさんが成功裏にプロジェクトを導入したと主張していることが分かります。しかし意図的にか成功したプロジェクトの詳細については語っていません。

そして残された我々にとっては、これこそブログ投稿を信頼することは間違いだという最も顕著な事例となります。 私は、すべての戦略がすべての状況、すべての人々、すべてのコンテキストで機能するわけではないということは、自明の理だと断言します。そして同じ論理をこのブランチモデルに適用します。

これで終わりでしょぅか? いえ、まだ十分ではありません。この論法に納得していない人もいるでしょう。そこでgitflowのブランチモデルなんか焼け落ちてしまえ、とさえ思うその理由について掘り下げて行きましょう。

GitFlowは表面的には複雑です

マイクロサービスや継続的デリバリーについて頭を悩ます以前にgitflowは複雑です。 このイメージ図を見て、直観的に思うことを言ってみてください。


(参照: https://nvie.com/posts/a-successful-git-branching-model/ )

ここではfeatureブランチ、releaseブランチ、masterブランチ、developブランチ、hotfixブランチをご覧頂きましたが、これらはすべてビルドおよびリリースプロセスにおいて追跡、理解、および説明されなければなりません。

それ以上に、常にどのブランチが何であるかを追跡し続ける必要があります。 これを使えるものにしようと保持する必要を求められるメンタルモデルには、高い認知負荷が伴います。私はgitを10年間使用していますが、ここで何が起きているのかをメンタルで把握出来るかどうかさえわかりません。

Gitflowは「短命な」ブランチルールに背いています

gitでは、ブランチにコミットしている人とのマージの競合数はそのブランチで作業している人の数とともに増加して行きます。git-flowでは、その数は更に増加します。何故ならば、developブランチにマージされる(ライフタイムが異なる)3つのブランチがあるからです。Featureブランチ、releaseブランチ、そしてhotfixブランチです。ここに至っては、マージ競合の可能性は線形ではなく、マージ競合機会は3倍にもなる可能性があります。

もうお腹一杯です。

「マージの競合についての懸念」と口にするのを躊躇する理由は、gitflowのようなブランチ戦略を追求しない、というのが本音です。一方で、これらのブランチが全て集結したときに導入される潜在的な複雑さは、看過できない程大量になります。コミット速度が低い組織の場合であればこれは然程問題とはならないでしょう。しかし、かなり急速な動きをしている組織やスタートアップの場合にはそうとは言えません。

リベースすることはGitflowを放棄することになります

リベースとは複雑なトピックであることは解っているものの、ここで話合うことは重要です。Gitflowを追い求めれば、リベースは諦めざるを得ません。2つのブランチが一緒になるポイントでは、リベースすることがマージコミットを排除することになることをお忘れなく。また、gitflowの視覚的な複雑さ故にブランチを目で見ながら追っていく必要があります。つまり、問題を解消したいと思うなら、リベースする必要はありません。

Gitflowは継続的デリバリーを不可能にします

チームが自動化された形でそれぞれ「チェックイン」(実際には、マスターへのマージ)すると共に直接生成に向けてリリースするところでは、継続的なデリバリーは普通に行われる行為です。乱雑なgitflowを見て、どうやって*それ*を継続的に配信するのか説明してみてください。

ブランチモデル全体は数分または数時間ごとにリリースされる新しいコードでは不可能ですが、長期のリリースサイクルでは予測可能と言い切ることが出来ます。しかしそのためのオーバーヘッドはあまりに高くつきます。CDの中心にあるプラクティスについて言っているので無く、修正によるロールフォワードについてです。 Gitflowではhotfixブランチを個別の存在として扱い、慎重に保存および制御し、他の作業から分離します。

Gitflowでは複数のリポジトリでの動作は適いません

マイクロサービスの出現により、 個々のチームがリポジトリとワークフローを制御し、誰がチェックインするのかが制御可能なところ、およびいかにワークフローが機能するか、と言ったマイクロリポジトリ(「互いに直交している」と叫び出すコメンター)のアイデアを推し進める動きも多くなって来ました。

複数のチームでgitflowのような複雑なブランチモデルを*試した*ことや、全員が同じページにいることを望んだことはありますか? あり得ないでしょう。システムは直ぐに様々なリポジトリで様々な形に改訂されたマニフェストとなり、全てはどこにあるかを知っている人だけがYAMLを叩き出し、マニフェストを更新します。「何が生成されるか」について注意していないと、実存する問題となってしまいます。

Gitflowはmonorepoでも機能しません

リリースの調整が困難であるが故にマイクロリポジトリが機能しない場合、リリースに際して全てのイクロサービスチームはたった一つの大きなブランチワークフローさえ順守すれば良いのではないでしょうか?

他のチームがリリースに手をこまねいているとき、これにはほんの2、3秒、あるいはチームが「直ぐに消さなければならない」と口にする程の時間し掛かりません。チームがまとまらず独立化し、マイクロサービスも独自に展開している場合はmono-repoで作成した集中型ブランチモデルにワークフローをうまく結び付けることは適いません。

Gitflowを使用すべき者、(使用すべきで無い者)とは誰か?

組織のリリースサイクルが毎月、または四半期ごとである場合、またチームが複数のリリースと並行して作業している場合、Gitflowは適切な選択と成り得るかも知れません。チームがスタートアップである場合やインターネットに接続しているウェブサイトあるいはウェブアプリケーションに携わっている場合で一日に複数のリリースがある場合は、gitflowは適していません。チーム規模が小さい(10人未満)場合、gitflowは作業するには過剰なセレモニーとなり、あまりに多くのオーバーヘッドが掛かってしまいます。

一方、チームが20人以上で並行してリリースに取り組んでいる場合、gitflowはチームを混乱させないように十分なセレモニーを提供し保証してくれます。

OK、解りました。私のチームはgitflowを使用すべきではありません。では、何を使うべきでしょうか?

私には答えられません。全てのブランチモデルが、全てのコンテキストで全てのチーム、全てのカルチャーで機能するとは限りません。CDを試してみると、プロセスを出来る限りスムーズにするものが欲しくなります。トランクベースの開発や機能フラグを信頼しきっている人たちもいます。しかし、それらはテストの観点から見ても、私を恐ろしいほどに震え上がらせてしまうものです。

私が唱える重要ポイントは、自身のチームに対してこう質問してみることです。このブランチモデルは問題解決に対し、どんな役割を果たすのでしょうか? どんな問題が発生するでしょうか? このモデルにより、どんな種類の開発が促進されるでしょうか? そうした姿勢を奨励することを望みますか? 選択したブランチモデルは、最終的にはソフトウェア製作にあたり人間同士がより容易に連携し合うことに繋がります。そしてブランチモデルでは、インターネット上で誰かが書いたもので「成功した」と主張するのではなく、それを使用する特定の人間のニーズに応えるということを考慮する必要があります 。

著者の注釈:このような投稿では非常によくある「有害と思われる」俗名の使用について考えてみました。しかしその後グーグルで検索してみると、既に他の誰かがGitflowは有害と思われると書いていることが判りました。本記事もまた、時間を費やしてでも読む価値があります。


コメントを読む

新着ピック  






















新着ニュース

東大卒プロゲーマー「ときど」はスランプに陥っていた——ウメハラからの助言、そしてたどり着いた「努力2.0」

5分でできるS3とCloudFrontを利用したセキュアな静的Webサイトの作り方 | Developers.IO

[初心者向け] AWS CDKのレイヤーについて調べてみた | Developers.IO

気化した過酸化水素で除染すればN95マスクも再利用可能に | TechCrunch Japan

Wheelsがハンドルとブレーキレバーがセルフクリーニングされる電動バイクを展開 | TechCrunch Japan

ロケット打ち上げスタートアップのSkyroraは消毒液とマスクの生産に注力 | TechCrunch Japan

AWSアカウント間でAmazon EventBridgeイベントを送受信してみた | Developers.IO

CloudFrontの作成や更新時間が約5倍高速になりました | Developers.IO

ポラロイドカメラが復活、新モデルPolaroid Nowが登場 | TechCrunch Japan

新型コロナ、過去2カ月の感染状況を比較した

市販の材料を使い1分で完成する医療用フェイスシールドの作り方をニューヨーク大学が無料公開 | TechCrunch Japan

「エスパーウィーク」は自宅で新ポケモン捕獲のチャンス 家で遊ぶ「ポケモンGO」まとめ

[オンラインハンズオン] はじめての自然言語処理(NLP)powered by LINE API Expert #jawsdays #jawsug #jawsdays2020 #LINE_API | Developers.IO

ソフトバンクGも出資の英OneWebが新型コロナで破産申請 74の衛星を残して

Looker 7でIDE(モデルやビューのWeb編集画面)のUIが改善されました #looker | Developers.IO

Lookerで「Liquid変数」を使ってWeb記事のURL情報をカスタマイズ #looker | Developers.IO

5分間で陽性がわかる米食品医薬局が新たに認可したAbbottの新型コロナ検査 | TechCrunch Japan

ソフトバンクなどからの追加資金を確保できずOneWebが破産を申請 | TechCrunch Japan

【小ネタ】スクリーンショットをカレントへ移動する処理をちょっと深掘り | Developers.IO

AIとビッグデータが新型コロナとの戦いで奇跡を起こすことはない | TechCrunch Japan

もっと見る
記事をPICKする
会員登録
Register
記事をPICKする

会員登録すると、もっと便利に利用できます。