Git branching modelを軽くまとめてみた
個人で開発をしている時、または数人で開発に取り組む時ですら、gitでバージョン管理を行う。しかしその管理の仕方は得てして適当なことが多い。自分も個人やチームで開発している時は、適当にブランチを切って、開発をして、リリースをしていた。
だが、サービスが大きくなった場合、そのようなやり方ではなかなかうまくことが進まない。いろんな人がいろんな考えを持っていろんなブランチを切ったりしたが最後、gitで何を管理しているのかが見えにくくなってしまう。
じゃあどうすればいいんだよと思った最中、プログラミングに造詣の深い人から以下の記事を紹介していただいた。
これ、最初読んだ時はわけわからなかった。「これが初心者から中級者へ上がる壁なのか。。。」と感じたことをよく覚えていいる。
だが、多くの物事がそうであるように、基本的に情報は「枝葉と末節」に分かれる。個人的には物事は全体感(枝葉)を軽く押さえてから、具体(末節)に降っていき、また全体に戻り、知識を体系化する、という流れが一番最適な学習プロセスだと思っている。
だとすると一番最初に重要となることは「軽く全体間を抑えること」になる。今回の記事では自分なりに持っている全体間の一部を共有したい。
最も重要masterブランチ
masterブランチについては馴染みの深い人も多いだろう。githubでリポジトリを作った直後から存在するあのブランチである。
上記git branchig modelではmasterブランチが最重要ブランチになる。なぜなら、このブランチにはリリースされているコードと全く同じコードが存在するからだ。ここでバグを起こしてしまったら、そのバグ発生箇所については、ユーザーが機能を利用できないという事態に陥るので非常に危険である。とにかく、このmasterブランチでのバグはできる限り避けなければいけない。
みんなが作業するfeatureブランチ
featureブランチは、開発人員が特定の作業をするために切るブランチのことをさす。このブランチで機能を開発した後に、下記で説明するdevelopブランチに反映をし、開発がうまくできているか確認を取る。
最初の確認場所のdevelopブランチ
developブランチでは、例えば開発チーム全員で作業内容がうまく機能しているかどうかを確認するために使う。ここには上記featureブランチで施した変更が一斉に反映されているため、どこかうまくいっていてどこがうまくいっていないのかが一目瞭然になる。
最後の砦のreleaseブランチ
releaseブランチもmasterに反映する前の確認場所のような存在である。上記developブランチとの違いは「データ」だ。developブランチでは「テストデータ」を用いてテストを行うが、releaseブランチでは「本番データ」を用いてテストを行う。すなわち、本番環境(masterブランチ)に最も近い状態でテストを行うことができる。
緊急時のためのhotfixブランチ
「masterに変更を反映してリリースを終えたよ！わーい！」と盛り上がってたのもつかの間、本番環境でバグを発見してしまった。そんな時にはこのhotfixブランチを作成する。hotfixブランチでは、主に本番環境反映後に起きたバグ修正を行う。
まとめ
- freatureブランチで作業する
- developブランチに反映し、テストする
- releaseブランチに反映し、テストする
- masterブランチに反映してリリース
- バグが発生した場合はhotfixブランチへ
というのが大枠の流れになるかと思う。このモデルを頭の中で理解できるようになると、普段gitのコマンドを打っている時も、自分がどこに何をpushしようとしていて、その後の流れはこうで、とかなんか色々意識できるようになるから楽しいです(笑)。
