Gitの実践的運用について〜git-flow/GitHub flow〜

はじめに

こんにちは。このレッスンでは、Gitを実際の開発に使う際に最も一般的なワークフローであるgit-flow及びGitHub flowを学んでいきます。これらのワークフローはgitの良さを最大限生かしながら、開発を効率化させるアイディアが詰まっています。
たとえgitの運用をする立場にいなくても、その全体像が理解できれば、より使いこなしていくことができると思いますし、新しくチームに入った場合には、早くチームのプロセスになじむことができる可能性もあります。しっかりと学んでいきましょう。

レッスン１．git-flow/GitHub flowとは

まず、git-flow/GitHub flowとは何なのかをご説明させていただきます。
git-flowは2010年にオランダのエンジニアVincent Driessen氏が提唱した、gitの使い方のワークフローです。ただのエンジニアの提案が今ではgitを使う上でスタンダードなワークフローとなっています。
(英文ページ)https://nvie.com/posts/a-successful-git-branching-model/

一方で、GitHub flowは有名なGitホスティングサービスGitHubで使われているワークフローです。git-flowをベースとし、よりシンプルに開発が行えるようにしたフローで、こちらも人気があります。

では、どういった場面で使われるかと言いますと、gitを導入していて、コーディング→テスト→コミット、プッシュ→レビュー→リリースというプロセスを踏んでいるケースであれば使うことができますので、ほとんどのソフト開発の現場で使えるといっても過言ではありません。
そのため、これからgitを導入しようと考えている現場では、git-flow/GitHub flowの導入も最初からセットで考えていただいた方が良いかと思います。

レッスン２．git-flowの全体像

では、実際にgit-flowの全体像を見てみましょう。下記がgit-flowの全体像です。
左が昔で、右に行くにつれて時間が進んでいることを現したフローです。丸い点はコミットです。
これだけを見ても良く分からないと思いますので、次からは各ブランチの用途を説明していきます。

レッスン３．各ブランチの用途

ここでは上の図で出てきた、各ブランチの用途を説明します。

master

常に存在するメインブランチです。ここには常に安定版のコードを置くのが鉄則です。テストが完了し、リリースがいつでもできる状態にしておく必要があります。基本的にはリリースが発生しないと更新されないのでリリースの履歴を辿るのにも使えます。

hotfix

緊急リリース用ブランチです。通常のリリースプロセスを踏む余裕もないほど緊急性の高い案件の対策に使われます。修正が完了したら、developとmasterにマージします。マージが終わったら削除されます。

release

リリース用ブランチです。リリースが行われる際に作成され、リリースに必要な作業（バージョンの付与等）を実施しmasterとdevelopにマージされます。マージが終わったら削除されます。

develop

常に存在するメインブランチです。常に最新の開発用のコードが置かれます。しかしながら、開発用とはいえ最も更新が頻繁に行われる、いわば開発の中心となるブランチですので、ビルドエラーなど初歩的な問題や、ハングアップして他の開発者に影響を与えてしまうようなコードには気を遣わなければなりません。

feature branches

developから機能開発を行う際に作成されるブランチです。基本的には何か変更行う際にはまずfeature branchを作って変更を行い、終わったらdevelopにマージするというプロセスが一般的です。マージが終わったら削除されます。

レッスン４．実際の開発手順

では、git-flowを使った場合の開発手順をステップバイステップで説明していきます。たくさんのブランチがあるので一見複雑そうに見えますが、実際には２パターンしかありません。今回はその２パターンを説明していきます。

では、まずは通常のステップです。ある変更を入れてから、リリースまでどのようなステップを辿るのか見ていきましょう。

① 最初に、developからfeature branchを作ります。

② 次に、feature branchで機能開発やバグフィックスを行います。

③ 修正が終わったら、developにマージします。マージが完了したら、feature branchは削除します。

④ 続いてリリース作業に入ります。まずはdevelopからrelease用ブランチを作ります。

⑤ バージョン変更や、ドキュメント作成等、リリースに必要な変更を入れていきます。

⑥ 準備が整ったら、それらの変更をdevelop及びmasterに入れます。その後、masterからリリースを行って終了です。

では続いて、もう一つのステップとして緊急リリースの場合を見てみましょう。その場合にはhotfixブランチを使います。
① まずは、masterからhotfixブランチを作ります。

② hotfixブランチで対策を入れます。

③ 対策をmasterとdevelopに入れ、masterにてリリース作業を行います。hotfixブランチはその後削除します。

以上がgit-flowの使い方です。２つのステップを説明しましたが、実際にはhotfixはほとんど使われません。緊急の時ほど落ち着いて対処すべきですので、大抵は緊急リリースがあっても、通常のステップを踏むことが多いです。

レッスン５．GitHub flowの違い

ここでは、git-flowとよく対比されるGitHub flowの違いを説明したいと思います。
GitHub flowは前述したようにGitHubで使われるフローです。git-flowをベースとして、よりシンプルでGitHubの良さを最大限生かせるフローになっています。小規模なプロジェクトであればこちらのプロセスでも十分対応できます。

では、こちらもまずは全体図を見てみましょう。

GitHub flowはたったこれだけの構造です。非常にシンプルですね。イメージとしてはgit-flowのdevelopの部分だけを使ったような構造となります。

ブランチ構造の簡略化以外で大きな違いとしては、masterにマージをかけるときにGitHubのプルリクエスト、すなわちコードレビューがプロセスに組み込まれているところです。

プルリクエストは、入れるべき変更がすべて入れ終わったら、masterにマージしても良いほかの開発者やリーダーなどにレビューしてもらい、レビューが終わったらマージするGitHubの機能です。レビューはコード上にコメントを入れながら議論できるので、非常に便利な機能です。
そしてリリースはmasterで行いますが、GitHub flowにおいてもmasterはリリース可能なコードを置かなければなりません。これについては、レビューにより、初歩的な間違いに気づく可能性が高まりますので、そこで品質の確保ができるというわけです。

レッスン６．導入のポイント

では、実際にgit-flowを導入するとなった場合、どうすればよいのでしょうか？
恐らく最初からすべてを取り入れるのは難しいでしょう。それもそのはずで、開発のプロセスは現場ごとに違うからです。
git-flow/GitHub flowはあくまで万人に向けたワークフローですので、必ずこのすべての要素を取り入れなければならないものではありません。チームや会社のプロセスに合わないワークフローが足かせになっては本末転倒です。そのため、通常はこれらをベースにカスタマイズして導入するのが一般的です。
例えば、Hotfixの仕組みは不要だなとか、developでもテスト版を定期的にリリースしようなど、それぞれの開発現場に即した形で導入を検討しましょう。

Gitのホスティングサービスをどこにするかで、導入すべきワークフローを決める方法もあります。GitHub/GitLabだったらGitHub flow、tracpathだったらgit-flowというような具合です。
(https://tracpath.com/bootcamp/learning_tortoisegit.html#id26)

いずれにしてもチームのメンバーとベストな形をよく話し合って決めていきましょう。

まとめ

今回はgit-flow/GitHub flowについて学んできました。
Gitを導入しているチームでは、これらのワークフローのどちらかを導入していることがほとんどです。そのため、これらを学んでおくことで開発に参加する際に構造を理解するのに非常に有利になります。
また運用側としても、業界のスタンダードに準拠しておくことで、新しいメンバーの参画のハードルを下げることができますので、Git導入の際には併せて導入を検討してみてください。
それでは、お疲れ様でした。