Git-Branching-Modelについてまとめてみた | プログラミング学習

個人で開発をしている時も数人で開発をしている時も、エンジニアは大抵の場合の置いて、gitでバージョン管理を行う。しかしその管理の仕方は得てして適当なことが多い。自分も一番最初にチーム開発を経験した時は、適当にブランチを切って適当にマージをしていた。

だが、サービスが大きくなった場合、そのようなやり方ではなかなかうまくことが進まない。いろんな人がいろんな考えを持っていろんなブランチを切ったりしたが最後、gitで何を管理しているのかが見えにくくなってしまう。

実はgitのブランチ管理にはベストプラクティスが存在している。それがgit-branching-modelというものである。

引用元: http://keijinsonyaban.blogspot.com/2010/10/a-successful-git-branching-model.html

中央レポジトリであるmaster/developブランチ

masterブランチについては馴染みの深い人も多いだろう。githubでリポジトリを作った直後から存在するブランチである。

git-branchig-modelではmaster/developブランチが中央レポジトリとなり、masterブランチには本番環境用のコードが、developブランチには開発環境用のコードを管理する。順番として、developブランチに実装したコードを反映して、開発環境での動作を確認し、開発環境での動作が安定したら、developの変更をmasterへマージする。developからmasterへ変更を反映するタイミングが製品リリースの瞬間である。

個別機能を開発するfeatureブランチ

featureブランチは、個人が新たな機能を開発する際に切るブランチで、developから分岐させる。特に命名規則はないが、ブランチ名として、「feature/hoge-hoge」みたいな感じで切るとわかりやすいと思う。featureブランチで作業が終わり次第、developブランチにプルリクエストを投げて、大丈夫そうであればマージされる。

検証のためのreleaseブランチ

releaseブランチに関しては、実務で取り扱ったことがないので腹落ちしてない部分が多いが、上記紹介したサイトによると、releaseブランチの役割は以下の通りである。

リリースブランチは新しい製品リリースの準備をサポートする。それらは最後の瞬間の詰めをしっかりと行わせてくれる。その上、マイナーなバグフィクスや、リリースのためのメタデータ(バージョン番号、ビルド日時、他)の準備までさせてくれる。これらの全ての作業をリリースブランチ上で行うことで、 develop ブランチは次の大きなリリースのための機能を受け取るために、キレイな体でいられる。

develop ブランチのソースコードが安定し、リリースの準備ができたとき、 develop ブランチの全ての変更は master ブランチへマージされ、リリース番号をタグ付けされることになる。(これをどうやるかの詳細は、あとで述べる。)

masterとdevelopの間にあるブランチみたい。developとreleaseを分ける利点は、開発と検証の環境を分けることによって互いに分業が進むことですかね。

緊急事態対応のためのhotfixブランチ

本番環境で緊急のバグが発生した時に、masterから分岐して作られるブランチ。hotfixブランチは機能開発のメンバーとバグ修正のメンバーの円滑な分業のために存在するらしい。

作業流れまとめ

  1. freatureブランチで作業する
  2. developブランチに反映し、テストする
  3. releaseブランチに反映し、テストする
  4. masterブランチに反映してリリース
  5. バグが発生した場合はhotfixブランチへ

というのが大枠の流れになるかと思う。このモデルを頭の中で理解できるようになると、普段gitのコマンドを打っている時も、自分がどこに何をpushしようとしていて、その後の流れはこうで、とかなんか色々意識できるようになるからいいと思う。