Git/GitHub
Git（「ギット」）とは、ソフトウェアのコードを管理するツールです。
現代のソフトウェア開発では広く使用されます。
ところが、いざ複数人でGitを使用してコードを共同管理しようとすると、様々な問題が必ず発生します。
問題解決に頭を悩ませることも少なくありません。
その共同管理のために、Gitフローという戦略が考え出されました。Gitフローに従って共同管理することで、問題発生の頻度は大変少なく（ゼロとは言いません）なります。
この記事では、Gitフローについて詳しく解説します。
北海道大学理学部数学科確率論専攻。 地方都市に居住していて、プロジェクトのテックリードを努めたりする傍ら、中小企業のDX支援なども積極的に行う。 後進に知識を伝えるべくライティング業務をしている。
Gitフローの基本
Gitとは？
まず、Gitについて簡単に解説します。
Gitは、分散型のソフトウェアコード管理ツールです。
ソフトウェアコードと書きましたが、ソフトウェアのプログラムに限らず、テキストファイルや普通のファイルならなんでも管理できます（但し、テキストファイル以外は管理してもあまりメリットはありません。Gitに保存しておくことは可能です）。
Gitの仕組みは、プロジェクトに参加するメンバーそれぞれのマシンの中に入っています。
どこか一つのサーバーで集中管理する仕組みではないため、安全性に優れています。
また、基本的には手元に、サーバーにあるコードが修正履歴などもすべて含まれた状態で保管されているため、過去に遡って調査することも可能です。
Gitで共同管理するとき、必ずサーバーを立てますが、サーバーは単なる原本です。
原本が更新されていくので、定期的に最新の原本をコピー（cloneする、pullすると言います）すれば手元のマシンも最新版に保たれる仕組みです。
サーバーを立てると言っても、Gitの管理を実装したサービスが何種類か出ていますので、それらのサービスを使用することが一般的となっています。
Gitフローとは？
と言っても、ただGitをサービスを利用して使い始めましょうと言っても混乱が起きます。
ソフトウェア開発は、
- 最新版をローカルに持ってきて
- ローカルでコードに修正を加えて動作を確認して
- 修正を加えたコードをサーバーに上げる（pushする、と言います）
ことの繰り返しです。
もし2の修正を複数人が同時にやったらどうなるでしょうか？
と言うよりも、共同開発なら「必ず」修正は同時に行います。
何も取り決めや戦略がない状態では、誰がどこを修正して、サーバーのコードがどういう状態なのかが、あっという間に分からなくなります。
そのため、修正を行う順番の戦略として、Gitフローが考え出されたのです。
サーバーのコードの状態を把握しておくための戦略だと考えてください。
サーバーのコードが把握できていなければ、サーバーからリリースする製品を取り出すことはできません。
Gitフローはリリースのために必須なのです。
Gitフローの種類
それでは、代表的なGitフローについて、簡単に解説します。
Gitフローにも種類があり、そのソフトウェア開発の規模に応じて使い分けます。
大規模でリリースが頻繁な製品はきっちりとしたGitフローを採用し、小規模だったりリリースがそこまで頻繁でもない製品はゆるやかなGitフローを採用することが多いようです。Gitフローの管理にもコストが発生しますので、開発会社の人員リソースなどにもよるでしょう。
以下では、コマンドの解説などは省略します。
Feature Branch Workflow (フィーチャーブランチワークフロー)
Feature Branch Workflowのポリシーを一言で説明すると、
「すべての機能開発はmainとなるブランチ（更新が続けられる流れのことです）ではなく専用のブランチで行う」
というものです。
サーバーのmainブランチをcloneしたら、そこから手元で新しいブランチを切り出します。
機能追加をそのブランチに対して行います。
機能追加が完了したら、誰かにコードをレビューしてもらい（たいていの場合ソフトウェア開発にはレビューという行為が付属します）、mainに含めていいですよ、となった場合、mainに統合（「マージする」と言います）します。
機能ごとにブランチがあるので、Feature（特徴） Branchと名付けられているわけですね。
Gitflow Workflow (ギットフローワークフロー)
Gitflow workflowは、少し古典的で、本格的なGitフローです。
Gitflowでは、以下の5種類のブランチを使い分けます。
- masterブランチ
リリースされたコードが保管してあるブランチ。 - developブランチ
開発を進めるブランチ。 - featureブランチ
新しい機能を追加するためのブランチ。 - releaseブランチ
リリースに向けたコードを整理するためのブランチ。 - hot-fixブランチ
緊急のバグ修正を行うためのブランチ。
各ブランチの特徴については、この記事の後半で詳しく解説します。
GitHub Flow (ギットハブフロー)
GitHubとは、Gitの管理サービスで代表的なサービスの一つのことです。
そのGitHub社が開発で採用しているGitフローになります。
masterブランチがあることはGitflow Workflowと変わりません。
ただ、Feature Branch Workflowと同様に、機能ごとにブランチを切り出し、開発が完了したものから順にmasterブランチにマージしていきます。
Gitflow workflowに比べるとシンプルなGitフローになっています。
メリットとしては、管理コストが低いことです。
ただデメリットもあり、あまり大人数の共同開発には向きません。
常に最新版をリリースするとも限らない製品ですと、そもそも採用できません。
Gitlab Flow (ギットラブフロー)
Gitlab Flowは、GitHub Flowの問題点を修正し、GitHub Flowにpre-productionブランチとproductionブランチを付け加えたGitフローです。
masterブランチから、pre-productionブランチにリリースする予定のコードを集め、リリースし、リリースが済んだらproductionブランチに移します。
この手間をかけることで、masterブランチのすべてをリリースしなければならないという問題が解決され、何がリリースされているのかの管理ができるようになるのです。
Gitflow workflowまで管理コストはかけられないが、リリースする内容は管理したい、というときに選択肢となるGitフローでしょう。
Bitbucket Flow (ビットバケットフロー)
Bitbucketも、Gitの管理サービスの一つです。
ただ、Bitbucket特有のGitフローがあるかというと、これと言って有名なGitフローはありません。
Bitbucket上でも、様々なGitフローを適用可能です。数あるGitフローのうちからプロジェクトに適したものを選択すればよいでしょう。
Gitフローの作成方法
さて、では、単にGitフローと言った時の（狭義の）Gitフローである、Gitflow Workflowについて詳しく解説していきます。
Gitflow Workflowは、ソフトウェア開発のGitフローにおいてデファクトスタンダードです。ソフトウェア開発を管理する場合、参加する場合にGitflow Workflowの理解は欠かせません。
以下では、単にGitフローと書いた場合にはGitflow Workflowを指すものとします。
Gitフローの導入手順
目標の明確化
Gitフローを導入する前に、
「何のためにGitフローを導入するのか？」
の「目標」を必ず明確にします。
ただなんとなく、で導入して上手く運用できるほどGitフローは簡単ではありません。それに、もしかしたらGitフローを導入しなくても済むプロジェクトかもしれません。
管理コストに見合ったものを導入することはソフトウェア開発プロジェクト運営の戦略の基本です。
ブランチの命名規則の設定
開発を進めていくと、Gitフローの5つのブランチ以外にも、ブランチを立てる必要が「必ず」出てきます。
そのときに、ブランチをどのように命名するのか、その規則を定めておきます。
開発者が混乱しないためです。
例えば、A社向けリリースとB社向けリリースを別に管理したい場合、releaseブランチは2種類作るかもしれません。
release_Aなのか、A_releaseなのか、ということです。
些細なことのように思われるかもしれませんが、管理の上からは重要なポイントです。
ブランチ戦略の定義
コード管理が機能するためには、各ブランチをどのように運用していくのかの定義を、必ず明文化しておきます。
暗黙の了解は、いつの日かそれを聞いていないメンバーによって崩れます。
もちろん、定義は時がたてば見直すかもしれませんが、管理上規則の明文化は必須の項目です。
ブランチ戦略は、リリースというソフトウェア開発の重大目標に向けてのものですから、規則を明文化することは必ずやっておいてください。
コミットメッセージの規則の設定
「コミット」とは、開発者がコードに修正を加えたときに、Git上で区切りとして行う行為を指します。
Gitで履歴を管理するのは、すべてこのコミットを基準として行われます。
コミットするとき、Gitはコミットを説明するメッセージを付け加えないとコミットできない決まりになっています。
そのメッセージが開発者によってバラバラなら、他の人にはなんのまとまりなのか判別がつきません。コミットメッセージの規則をプロジェクトで統一するのはやっておきましょう。
フィーチャー追加とマージポリシーの定義
機能追加と言っても、どの単位の機能なのかは、プロジェクトによってまちまちです。
どの単位でfeatureとするか、決まりを策定しておきます。
また、マージする際、
- レビューが必須なのか必須でないのか
- テストに通ることが必須なのか必須でないのか
も、プロジェクトによって違います。
マージする権利があるのはリーダーのみというプロジェクトもあるでしょう。
マージのポリシーも、同様に策定しておきます。
リリースとバージョン管理
ソフトウェア開発で必ず混乱を招くのが、リリースのバージョン管理です。
このバージョンには何の機能が入っていて何の機能が入っていないといったようなことが不明瞭になりがちなのです。
バージョンを明瞭にするためには、リリースの度ごとにドキュメントにまとめてリリース物に付与し、Gitにも追加しておくなど、一定の工夫が必要となります。
リリースは必ず来るものです。
バージョン管理については、プロジェクト開始段階で運用手順を策定してください。
ホットフィックスポリシーの設定
hot-fixは、緊急のバグ修正を行うものです。
ソフトウェアにおいては、緊急のバグ修正は「必ず」発生します。
緊急なので、あたふたして何の作業をしたのか分からないことになりがちです。
そのため、hot-fixをどのような手順で行うのか、そのポリシーを必ず定めましょう。
防災マニュアルがあれば避難がうまくいくのと同じ原理ですね。
コンフリクトの解決戦略
さて、Gitを使用していても、
「同じ個所を同時に複数の人が修正した」
場合、Gitはどちらの修正が正しいのか判断できません。これをコンフリクトと言います。
コンフリクトは、人の手で解決する必要があります。
そしてコンフリクトの解決には、たいてい大変な手間がかかります。
コンフリクトを起こした当事者同士の連絡の仕方、誰がコンフリクト解消に最終責任を持つのか、コンフリクトを解消した後の動作保証テストはどうするのか、そういった戦略は、実際にコンフリクトが起きる前の初期段階で定めておいてください。
ドキュメンテーション
ドキュメントは、コードを補完するものです。
先ほど少し述べたリリースの際のノートもドキュメントにあたります。
他にも、API設計書やテスト設計・報告書など、ソフトウェア開発なら生産されるドキュメントは必ずあります。
それらをどのように管理するのか定めておかないと、ドキュメントの内容とコードの内容はすぐ合致しなくなります。それではドキュメントを執筆する意味がありません。
ドキュメントの管理方針も定めておきましょう。
トレーニングと導入
さて、ここまでGitフローの導入手順を解説してきましたが、これだけ膨大な項目に上る規則を、プロジェクト参入初日のメンバーがすべて理解するのは不可能です。
そのため、プロジェクトに参入したメンバーには、Gitフローについてのトレーニングを課すことが一般的です。
誰がトレーニングするのかなどを、あらかじめ定めておくと混乱がないでしょう。
定期的な見直し
ちらっと触れましたが、規則は一度定めて終わりではありません。
ソフトウェア開発が続く限り、規則を見直す必要は必ず出てきます。
開発の実態に合わせて、Gitフローを定期的に見直しましょう。
Gitフローの規則は、規則のための規則ではありません。ソフトウェアの開発のための規則です。目的はソフトウェアの開発にあります。
Gitフローのブランチ戦略
さて、先述したgitフローの各ブランチについて、その詳細を解説していきます。
まず、前提として、masterブランチはリリースされたコードが整理されているブランチである、ということは書いておきます。これはイメージもしやすいと思われます。
まだリリースされていないコードやドキュメントはmasterブランチには入っていません。したがって、masterブランチは「一番進んでいる」＝「最新版の」ブランチではありません。
その前提のもとに、各ブランチを見てみましょう。
develop ブランチ
developブランチは、開発の主線となるブランチです。
チームのメンバーは最新のdevelopブランチに修正を加えていきます。
新しい機能を追加するとき、最新のdevelopブランチからブランチを派生させます。
派生させたブランチに修正を加えて、レビューを受け（受けない場合もあります）、承認されたらまたdevelopブランチにマージします。
developブランチは、「常に」、masterブランチより「進んでいます」。
開発途中でまだリリースされていない機能は常にあるからです。
featureブランチ
featureブランチは、developブランチから派生させた、新しい機能（＝feature）を追加するためのブランチです。
featureブランチは常に数種類同時に存在します。
最も多くみられる形態は、各開発者が各自の担当機能を各自のfeatureブランチとして作る形態です。
featureブランチは、機能が開発し終わった後、なるべく小さな単位で早いうちにマージします。長い期間developから切り離していると、先述したコンフリクトの危険性が高まります。
releaseブランチ
releaseブランチは、文字通りリリースのための準備をするブランチです。
developブランチから、リリースに使用するコードやドキュメントのみを抜き出し、releaseブランチに切り出します。
releaseブランチでリリースノートを追加する場合もあります。
リリースが終わったら、releaseブランチの内容をmasterブランチにマージします。
hot-fixブランチ
hot-fixブランチは少し運用が特殊です。
ソフトウェアは、リリースしてから緊急のバグ修正が必要になることが必ずあります。
この時、リリース済みのコードも、開発途中のコードも同時に修正します。（開発途中のコードも修正するのは、バグは修正しなければならないからです）
hot-fixブランチはmasterブランチより派生させて修正を行いますが、修正が終わった後（バグ修正がリリースされた後）、masterブランチとdevelopブランチの両方にマージします。
developブランチへのマージは注意が必要ですね。リリースされた後に既に他の箇所に修正が入っていますから。
最新のdevelopブランチでも動作するようなバグ修正を行うのが通常の流れです。
supportブランチ
さて、そのシステムのユーザー全てが、最新版のリリースを使用するわけではありません。
顧客によってリリースのバージョンが違うのはよくある話です。
その場合、supportブランチに過去のリリースの状態を保存しておき、そのバージョン特有のバグ修正はsupportブランチで行うことで、本体の修正が影響されない戦略をとることがあります。
どれくらいの数のsupportブランチがあるのかは、そのプロジェクトによってまちまちです。
GitフローとGitHubフローの比較
これまで述べてきたことを元にして、GitフローとGitHubフローの比較をすると次の表のようになります。
| Gitフロー | GitHubフロー |
|---|---|
| 本格的なワークフロー | 簡易的なワークフロー |
| 複雑な工程管理ができる | 複雑な工程管理には不向きである |
| 随意のバージョンのリリースがし易い | 常に最新版をリリースすることになることが多い |
| 管理コスト、トレーニングコストが高い | 管理コスト、トレーニングコストは低い |
このような特徴があるので、大規模なプロジェクトではGitフローを導入し、小規模なプロジェクトではGitフローを導入することが多いようです。
リリースの問題だけは管理したいという場合、Gitlabフローも検討に値するでしょう。
ただ残念ながら、どのワークフローを採用するにせよ、コンフリクトの問題だけはついて回ります。共同開発では致し方ありません。
コンフリクトの解消のルールだけは、いかなるワークフローにおいても定めておいた方がいいでしょう。
Gitフローのまとめ
以上、Gitフローについて解説してきました。
Gitのワークフローは、共同で開発するプロジェクトにおいては導入することが避けられないGitの取り決めです。
円滑に開発を進める上では大変重要なポイントになります。
ワークフローを導入しないでGitを使い始めると、Gitがただの個人のコード保管になってしまいます。
それでは、特に大規模なプロジェクトの場合、共同作業がうまくいきません。
とは言え、
「こんなこと自社で運営できるのかな…？」
Gitフローの複雑さを見て、そうお考えの方もいるかもしれません。
実際、Gitフローは強力な武器ですが、扱うのは簡単とは言えません。
そんなときには、プロダクトの開発を専門のシステム開発会社に任せてしまうのはいかがでしょうか？
株式会社Jiteraでは、Gitフローを熟知した開発メンバーが、御社のプロダクトの開発を一括して請け負います。
ソフトウェア開発は株式会社Jiteraにご用命ください。
