(cache) 小規模チームでのGithub利用開発

気づくと1週間経っている恐怖(´ω｀)

いまうちの会社ではGH:Eを導入するほどの規模でもないので、Githubのビジネスプランを使って開発を進めています。
僕自身gitへの造形がそこまで深くなく、どのように開発を進めていくかかなり迷いがありましたが、現在ある程度フローを決めてスムーズに開発が進むようになってきたので、それをまとめておきたいと思います。

ベースはgit-flow

Githubを導入するにあたって、gitを利用した開発フローについて調べたのですが、やはり最初に出てくるのがgit-flowでした。
一方で、実際にgitを現場で利用されている方々に聞くと、「リリーススピードが早いとgit-flowは厳しい」という声も聞かれました。
そこで、小規模チーム（現在は3人）で開発を行う際にgit-flowをベースとして利便性の高い開発フローを考えてみました。

リリースまではmasterとfeatureブランチのみ

まずリリースまでですが、masterブランチとgit-flowでいうfeatureブランチのみを利用し、masterからブランチを切って自分の担当分の開発をしてmasterにpull reqを送ることを繰り返します。
検証も各ブランチとmasterでやります。

リリース直前にdevelopブランチを切る

リリース直前、リリースバージョンのコードが固まればそこでdevelopブランチをmasterから切ります。
かっこいいのでmasterにtag打ったりしましたが、ソーシャルゲームのリリースペースだと大体その後はタグ打つ暇とかないですorz

developブランチ作成後はfeatureとhotfixブランチを作る

developブランチを作成した後は、ブランチを2種類に分けます。

まずfeatureブランチ。こちらは大きめの機能を追加で開発したり、イベントを作成するブランチで、最新のdevelopから分岐させます。
そして開発とブランチ上での検証を終えたらdevelopブランチにpull reqを送ります。

一方hotfixブランチですが、こちらはリリース後に出てくるbug fixが主になります。こちらは最新のmasterからブランチを切り、masterとdevelopの両方にpull reqを送ります。

新機能リリース時はdevelop→masterでマージ

リリース後は大体bug fixに明け暮れるものですが（ちゃんとテスト書きましょうねorz）それが終わって次はイベントのリリースだ！という風になればdevelopブランチからmasterブランチにpull reqを送りマージします。

利点

この方法の利点は、まずリリースペースが早くてもついていけることです。若干慣れるまで時間が必要ですが慣れれば十分リリースペースを上げられます。
そして、新機能については十分な検証時間をとりつつもhotfixは即時反映することができること、です。

僕が自分で考えた開発フローなので、もっといいのあるわ(ﾟДﾟ)ｺﾞﾙｧ!!とか、それgit-flowでも出来るよ（実際出来ると思います）というご意見もあると思いますが、なかなか気に入っているので、スタートアップ等でまだ規模も大きくないしリリースペース早いし、というチームの方は導入してみてはいかがでしょうか！