Gitの運用方法の有名な３パターンについての考察
どうもこんにちはkoheiです。
あと少しで花粉の季節になると思うと憂鬱です。
花粉のない場所に逃げたいと思う今日このごろ。。
それでは本題、先日に下記のようなツイートをしました。
Gitについて、ちゃんと考えて運用しているプロジェクトとそうではないプロジェクトがはっきり分かれてるなと最近思いました。うまく運用できれば効率よく開発ができて結果的に工数が削減できるのに、考えることをやめてしまうのはもったいない！
— こうへい@フリーランスエンジニア (@kohei72901660) January 15, 2020
Gitについて、ちゃんと考えて運用しているプロジェクトとそうではないプロジェクトがはっきり分かれてるなと最近思いました。うまく運用できれば効率よく開発ができて結果的に工数が削減できるのに、考えることをやめてしまうのはもったいない！
というわけで、改めてGitの運用方法について考察したいと思いました。
今回はGitの運用方法について、ゆく使われる有名な３パターンについて私自身の考えを踏まえて解説していきます。
Gitの運用方法を決める理由
私自身、Gitの運用方法について決めないままmasterブランチにプッシュしているプロジェクトに参加したことがあります。
この場合、必ずといっていいほど、コンフリクトが頻繁に起こったりマージのミスが発生したり、バグ管理ができなくなります。
このような状態にならないためにも、開発初期の段階でGitの運用方法について決め、全ての開発者に共有されていなければいけないと私は思います。
ソースコード管理は開発者にとってとても重要なことだと私は思います。
失敗談
実際、あまり意識せずに開発している人もたくさん見てきました。
リリース用のブランチにバグ修正したソースがマージされていなくてお客さんの環境にリリースしてしまいクレームがくる。。
そして、クレーム対応や他のバグ修正についてマージされているかの確認をしなければいけなく余計は工数がかかってしまいました（涙）
当たり前だと思う方もいるかとは思いますが、結構あるんです！
そうではない人もいるということを認識した上でソース管理をしていかないと痛い目に合います。
ぜひ、ソース管理について意識してみてください。効率が圧倒的にかわると思います。
リリースはスピーディーに行うのが原則！そのためにもGitの運用方法について事前に決めて、しっかりとソース管理する必要がある。
Gitの運用方法の決め方
主に以下の観点から決めるのが良いかと思います。
- 管理のしやすさ(運用ミスのおきにくさ)
- リリースの頻度
- 理解のしやすさ
よく使われる運用方法３パターンについて
まずは、どのような運用方法が世の中で知られているかについて説明したいと思います。
Git flow
Vincent Driessen氏が考案した“A successful Git branching model” というブランチモデルになります。
以下のブランチに分けて運用していきます。
- master：実際の製品ファイルを置くブランチ、リリーズしたらタグ付けする。
- develop：開発ブランチ。リリース前の最新のブランチであり、リリーズの準備ができたらmasterブランチにマージします。
- feature：追加機能やバグ修正を行う開発用のブランチ。developブランチから分岐し、ソース修正後にdevelopブランチにマージします。
- release：リリース前に準備や微調整をおこなうブランチ。developブランチから分岐し、タグ付け（図：1.0）をします。調整後はmasterブランチにマージします。次にdevelopブランチにマージします。
- hot-fix：masterブランチで緊急修正を行うブランチ。masterブランチから分岐し、masterブランチにマージしタグ付けをします。
※参考画像
GitHub flow
GitHubの開発で使用されるフローモデルです。
以下のブランチに分けて運用します。
- master：常時デプロイ可能である。（常に安定しているブランチで、リリース可能な状態であるということ）
- 作業用ブランチ：masterブランチから分岐し、masterブランチにマージする。ブランチ名はなんの作業をしているかわかるようにする。
運用方法については以下となります。
- ローカルリポジトリの作業用ブランチは定期的（頻繁に）にリモートリポジトリの作業用ブランチにプッシュします。→他の開発者が確認できるようにするためと、同じ対応をすることをふせぐため
- コードレビューしてほしい場合はプルリクエストを作成する。→作成方法はGitHubのGUIから。作業用ブランチから他のブランチ（masterまたは他の開発者の作業用ブランチ）に対して作成します。
- プルリクエストがレビュー（承認）されたときだけ、masterブランチに作業用ブランチをマージが可能。→レビュー後なので、masterブランチは安定します。
GitLab flow
GitLabの開発で使用されるフローモデルです。
以下のブランチに分けて運用します。
- master：開発用のブランチ。直接変更（コミット）はしない。
- feature：開発用のブランチ。機能追加用。masterから分岐し、masterにマージする。マージ後は削除する。
- hotfix：開発用のブランチ。バグ対応用。masterから分岐し、全ブランチにマージする。全ブランチでマージ後は削除する。
- pre-production：リリース前のテスト用ブランチ。masterブランチから分岐し、productionブランチにマージする。Git flowでいうreleaseブランチ。
- production：リリース用ブランチ。
運用方法については以下となります。
- マージする場合はマージ（プル）リクエストを作成する。→ソースコードの品質が向上する※GitHub flowと同様
- hotfix/featureは頻繁にリモートリポジトリにプッシュする。→他の開発者が確認できるようにするためと、同じ対応をすることをふせぐため※GitHub flowと同様
- プルリクエストがレビュー（承認）されたときだけ、masterブランチに作業用ブランチをマージが可能。→レビュー後なので、masterブランチは安定します。※GitHub flowと同様
- コミットがトップダウンなので、すべてのブランチでテストされたことが保証される→管理が楽になる
３つの運用方法についての比較
では、私の考える３つの運用方法についての比較は以下になります。
１．管理のしやすさ(運用ミスのおきにくさ)
（管理しやすい）Git flow > GitLab flow > GitHub flow（管理しにくい）
２．リリースの頻度
（多い）GitHub flow > GitLab flow > Git flow（少ない）
３．理解のしやすさ（複雑さ）
（簡単）GitHub flow > GitLab flow > Git flow（複雑）
上記の比較を踏まえて、実際に運用するGitの運用方法を決めます。
どの観点も捨てがたい。。個人的にはGitLab flowが一番運用しやすいかと思ってます。
ただ、プロジェクトによっては別の運用方法がいい場合があるので、上記の指標をもとにしてベストな選択をすべきだと思います。※理由もなく、いつも使っているからといって同じ運用方法を使うべきではないということ。
実際に私が経験した運用方法はこれ！
なぜかというと、実際私が参加してきたプロジェクトで、上記すべての運用方法を経験したことがあるからです。
さらに、世の中には色んな人が考えた運用方法が存在します。
なので、ソース管理やリリースにかかる工数をできる限りなく少なくするためにより効率の良い運用方法を選択することがエンジニアにとって必要なスキルだと私は思います。
ぜひ、参考になれば幸いです。私自身も改めて勉強になりました！
余談
GitLabにはCI※１が存在し、より効率の良い開発ができるみたいです。経験したことないですが実際に参加したプロジェクトで取り入れてみたいです。
※１：Continuous Integrationの略。継続的インテグレーション。
人気記事：【最新】Git初心者におすすめの本５選【サービス利用で効率よく開発】
開発全般