Gitの運用方針を立てることになったのでひとまずGit flowを学ぶ

2 min読了の目安(約2600字IDEAアイデア記事

はじめに

状況はタイトルの通りなのですが...まあそんなことになりました。

参画してきたプロジェクト全てでGitを使用してきたため、なんとなく方針のイメージは立ちます。が、イメージはあくまでイメージでしかなく...自分の中で納得感を持って言語化できるほど明確にはなっていないというのが正直なところです。

ということで、今一度Git flowを学び直そうと思ったのが本記事を書こうと思った背景です。

ブランチの分類

Git flowにおいてブランチはメイン・ブランチサポート・ブランチの2分類が存在します。

メイン・ブランチとはリポジトリに恒久的に存在するブランチです。
一方で、サポート・ブランチとは最終的には削除されるブランチです。

メイン・ブランチ

masterブランチ

リリースしたソースコードを置いておくブランチです。

developブランチ

次のリリースに向けた最新版のソースコードを置いておくブランチです。

本ブランチはmasterブランチから切られます。

$ git checkout -b develop master

サポート・ブランチ

featureブランチ

項目 説明
ブランチ元 develop
マージ先 develop
ブランチ命名 master, develop, release-?, hotfix-? 以外

新しい機能を開発するためのブランチです。開発がスタートしたら様々な機能を実装することになると思います。そのときは本ブランチの出番です。命名はそこまで厳しく定められているわけではありませんが、ここでは feature-{チケットNo} とします。

$ git checkout -b feature-1 develop

実装を終えたらdevelopブランチにマージしましょう。

$ git checkout develop
$ git merge --no-ff feature-1
$ git branch -d feature-1
$ git push origin develop

releaseブランチ

項目 説明
ブランチ元 develop
マージ先 develop と master
ブランチ命名 release-?

リリースに向けた調整を行うためのブランチです。developブランチがほぼほぼリリースしても問題ない状態になったら本ブランチが切られます。本ブランチではたとえば、バージョン表記や小さなバグ修正を行います。新しい機能の追加は禁止です。

ここでは、バージョン1.2のリリースブランチを作成するとします。

$ git checkout -b release-1.2 develop

リリースに向けた調整を終えたらいよいよリリースです。つまり、masterにマージします。
合わせてタグも付けておきます。

$ git checkout master
$ git merge --no-ff release-1.2
$ git tag -a 1.2
$ git push origin master

developブランチにもマージをします。

$ git checkout develop
$ git merge --no-ff release-1.2
$ git push origin develop

リリースが無事に済んだら本ブランチを削除します。

$ git branch -d release-1.2

hotfixブランチ

項目 説明
ブランチ元 master
マージ先 develop と master(例外あり)
ブランチ命名 hotfix-?

リリースされているソースコードに緊急の修正対応をするためのブランチです。バージョン1.2リリース後に深刻な不具合が発覚したとします。この場合本ブランチを切ります。

$ git checkout -b hotfix-1.2.1 master

修正を終えたらリリースです。つまり、masterブランチにマージします。
合わせてタグも付けておきます。

$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag -a 1.2.1
$ git push origin master

次にdevelopブランチ(例外としてreleaseブランチがある場合はreleaseブランチ)にもマージします。
※releaseブランチがあってもリリースが待てない場合はdevelopにもマージすることはあり

以下コマンドはdevelopブランチにマージをする例です(releaseブランチの場合も同様)。

$ git checkout develop
$ git merge --no-ff hotfix-1.2.1
$ git push origin develop

リリースが無事に済んだら本ブランチを削除します。

$ git branch -d hotfix-1.2.1

さいごに

プルリクとかも組み込みたいのでGitHub flowも確認したいですね。
その後両手法のメリットデメリットを整理した上で(さらに必要に応じて両者を組み合わせつつ)適切なGit運用方針が策定できたらと思います。一度自分の中で落とし込めたらずっと使えると思うので(バージョン管理としてGitが使われ続ける限り!)。

参考