読者です 読者をやめる 読者になる 読者になる

by shigemk2

当面は技術的なことしか書かない

ブランチ戦略のイロハ

Git

人数が増えてくると、何を、どのくらいdeployするか戦略を立てないといけなくなる。

リリースモデルケース

A successful Git branching model » nvie.com

次にデプロイされるのは何なのかがある程度分かっているのが利点。

masterはmergeするのみ
developブランチで開発を行う。

developからfeatureブランチを作る
開発が終わったらfeatureブランチをdevelopにmerge
mergeしたdevelopをStagingチェックする
branchでbugfixする
developにmergeする

masterからbugが見つかったらhotfixesブランチを切り、
直接masterにmergeする

このスタイルだとばんばんdeployできない。

GitHub Flow

GitHub Flow – Scott Chacon
リリースマネージャーがいない(全員がdeployできる)
master(origin/master)からデプロイを行う(ローカルのmasterからブランチは切らない)
開発が完了したらPRを出す
PRを処理した人がdeployする。
レビューしないとPRを出せないようにする
小さいPRをちょくちょく出せる環境でないと機能しない

PRを出すなら他のひとのPRもレビューする!!
(テストで守られているのが大前提)

ふわっとレビューしてふわっと出すスタイルなので、
テストをきちんと書くこと。

masterと本番はイコールなので、masterにmergeしたら
すぐにdeployすること!