A successful Git branching model を翻訳しましたを参考にしています。
- ここに入るコミットは、全て製品として公開することのできるもののみを含める。
- リリースする一つのバージョンを一つのコミットとし、それ以外のコミットを絶対に含めない。
- 「バージョン1.3に戻したい！」というような要求に応えられるようにするため。
- オリジンに必ず存在する。
- masterから派生する開発用のブランチ。
- 開発は基本的にこのブランチから始まる。
- このブランチは絶対に消さない。
- このブランチをどこかのブランチにマージすることもない。
- オリジンに必ず存在する。
- 開発者はオリジンからdevelopをローカルにpullし、developから新しいfeature-* ブランチを切る。
- developから派生するブランチ。
- 開発中に「この機能を加えたい」「この修正を加えたい」と思った時に作る。
- コミットはどんどんして良い。
- 必ずdevelopから派生し、developにマージする。
- マージしたら消しても良い。
- オリジンにはpushしない。
- Githubを使っている場合は、イシュー番号をつけても良い。
feature-issue-4など。
- developから派生するリリース（masterへのマージ）用の細かい修正をするブランチ。
- バージョン番号の修正とか細かいバグ修正とか。
- 必ずdevelopから派生し、developとmasterにマージする。
- どちらか片方だけにマージしてはいけない。
- オリジンにはpushしない。
- develop以外にmasterから派生する唯一のブランチ。
- masterの致命的なバグを修正する（マイナーバージョンをあげる）ためのブランチ。
- 必ずmasterから派生し、developとmasterにマージする。
- どちらか片方だけにマージしてはいけない。
- オリジンにはpushしない。
プロジェクトにジョインした開発者は、以下の手順で開発を進める。
- オリジンからレポジトリをクローンし、オリジンのmasterとdevelopをローカルにチェックアウトする。
- developからfeature-* という名前で新しいブランチを作成し、そのブランチ上で自分の開発を行う。
- feature-* での開発が終わったら、developにマージし、developをオリジンにpushする。
- developにマージする際に、オリジンのdevelopが進行している場合は先にdevelopをpullした上でマージする。
次回リリースに含める機能開発が終わった場合は、以下の手順でリリースする。
- 必要なコミットが全てマージされたdevelopブランチから、release-* ブランチを作成する。
- このrelease-* ブランチ上で、バージョン番号や細かい本番用の修正を行う。
- 本番用の細かい修正が終わったら、release-* ブランチをdevelopとmasterにマージする。
本番にクリティカルなバグが発見され、早期に修正しなければいけない場合は以下の手順で修正する。
- masterからhotfix-* ブランチを作成する。
- そのブランチ上で修正を行う。
- 修正が終わったら、hotfix-* ブランチをdevelopとmasterにマージする。
- developにマージする際に、すでに次回リリース用release-* ブランチが存在する場合はdevelopではなく、そのrelease-* ブランチにマージする。
- そのrelease-* ブランチは上記の「リリース手順」の手順によってdevelopに反映される。
developにマージする際はノンファストフォワード（--no-ff）マージ。
git merge --no-ff release-1.1.0など。
- どのブランチからマージされたかがわかりやすい。
- マージを取り消しやすい。 - マージコミットをリセットすればそのブランチからのコミットが全て消えるため。
masterにマージする際はスカッシュ（--squash）マージ。
git merge --squash release-1.1.0など。
- コミットを全て一つにまとめたいから。
- スカッシュマージコマンドはコミットを生成しないため、実行後自分でもういちど
git commitをする必要がある。