git flowモデル - nekoharuyuki/PuzzleRPG-cocos2d GitHub Wiki

ブランチモデル

ブランチモデルとはブランチをどのように切って運用するかをまとめたものです。
git-flowとGitHub Flowが一般的に有名であり、さらにそれを派生させたチーム独自のモデルがある。いずれにせよ、どのようなブランチモデルを採用するか、ルールをチーム内で統一する必要があります。
今回はDriessen氏が自身のブログで公開した「A successful Git branching model」という記事から生まれたアイデアをまとめます。

git-flowモデル

複数人による開発をおこなう場合、Gitの運用ルールを決めずに開発を進めると、コンフリクトが頻繁に起こり、マージのミスが発生したりと、手間が発生する。しかし、そうした問題を回避し、最大限にGitを活用することができるブランチ戦略とリリース管理が「git-flow」です。

細かくブランチを切った厳格な運用モデル

masterブランチ、developブランチ、releaseブランチ、featureブランチ、hotfixブランチ、supportブランチの6種類を用意する。

git-flowを使用した開発では「メインブランチ」とそれ以外の「サポートブランチ」を使用します。

メインブランチ

メインブランチには「master」と「develop」の2つのブランチがあります。これらのブランチは常に存在します。

種類	用途
master	リリース済みのソースコードを管理する
develop	開発中のソースコードを管理する

サポートブランチ

タスクごとに「フィーチャー」「リリース」「ホットフィックス」のいずれかのブランチを作成し、作業を行います。

---

masterブランチ

リリース可能な完全品質を保証するブランチ。
releaseブランチからのマージのみで更新される。
masterブランチ上で直接作業したりコミットするのはNG。
tagはmasterブランチ上でのみ存在する。

developブランチ

開発の主軸になるブランチ。
masterブランチから派生させる。
developブランチ上で直接作業したりコミットするのはNG。
developブランチからfeatureブランチやreleaseブランチを切る。

releaseブランチ

リリース作業を行うためのブランチ。
developブランチから派生させる。
リリース作業が完了したらmasterブランチとdevelopブランチにマージする。
masterブランチにマージする際のコミットではtagを打つ。
マージされたら該当のreleaseブランチは削除する。

featureブランチ

機能追加および修正作業を行うためのブランチ。
developブランチから派生させる。
作業完了してレビューが通ったら、developブランチにマージする。
どのような機能追加を行うブランチなのかが一目で分かるようなブランチ名を心がける。
マージされたら該当のfeatureブランチは削除する。

hotfixブランチ

リリース済みのものの緊急修正用の作業を行うブランチ。
masterブランチから派生させる。
修正作業完了後はmasterブランチとdevelopブランチにマージする。
また、masterブランチにマージする際のコミットではリリースタグを打つ。
マージされたら該当のhotfixブランチは削除する。

supportブランチ

旧バージョンをサポートするためのブランチ。
必須ではないが、旧バージョンをサポートする必要がある場合は、masterブランチのtagからsupportブランチを派生させる。
旧バージョンでバグが発生した場合は、supportブランチ上で直接バグフィックス作業を行いコミットする。
また、バグが過去の複数バージョンにまたがる場合は、修正コミットは対象の全てのバージョンのsupportブランチにcherry-pickする。
サポートが完了したら該当のsupportブランチは削除する。

参考記事

A successful Git branching model
https://nvie.com/posts/a-successful-git-branching-model/