git-flow

gitのブランチ管理

何処かで聞いた4ブランチ管理

1. master メインのリリースツリー
2. hotfix リリース物件の修正パッチ用
3. dev 開発用ブランチ
4. release リリース試験用

もう一つあった様な

本題 git-flow

快適な平行開発を実現するためのブランチ活用案。

平行開発対象の種別

• hotfix
• release
• feature

各種別毎に複数ブランチ存在可。それぞれの開発が終われば、メインのmaster/developにマージし消滅するブランチ。

平行開発ブランチのマージ先

• hotfix -> 製品master
• release -> 製品master
• feature -> 開発develop

そして、実が熟して来たら、

develop -> release

整理すると5種類のブランチを使用する形態

master/developが永続ブランチ

hotfix/release/featureが事象駆動型の期間限定ブランチ。

1. develop 開発用メインブランチ
2. feature 機能開発用。 developから分岐し、developに戻り削除。
3. release リリースに向けた作業。developから分岐し、master/developの二つのブランチにマージし削除。
4. master 製品用メインブランチ releaseをマージし、tagを付ける。
5. Hotfix masterから分岐し、masterにマージし消滅。

master、developが永続的ブランチ。

feature/release/hotfixが事象駆動型の期間限定ブランチ

git-flowの概念と課題

• gitの目指すもの
• gitの課題
• git-flowの方法 Vincent Driesseが提唱するブランチモデル

gitの目指すもの

快適な平行開発？

何が快適？

さて

もっと簡単にならないの？と思う場合、

• 案1. master一本
  • hotfixが大変
• 案2. master+develop
  • hotfix用はmasterを直接修正？ 製品リリース版とはtagで区別する？
  • 開発破棄がrevertの嵐？

案2のmaster+developをベースに必要な時に必要なブランチを作成するのが良いのかも。

そもそもブランチは破棄される前提でモデルを検討すると良いかも。

始まり

リリース後に下記の分岐

• master -> dev
• master -> hotfix

あるいは、

master -> release, developに分岐 releaseで整理 -> master/devマージ

参考

Vincent model

http://nvie.com/posts/a-successful-git-branching-model/

http://danielkummer.github.io/git-flow-cheatsheet/index.ja_JP.html

ブランチモデル実績

https://havelog.ayumusato.com/develop/git/e513-git_branch_model.html