Gitflowのreleaseブランチの扱いがよくわからなかったので、整理してみました。

1. GFLS 入門
GFLS means GitFlow Like Style
© 2015 Takahashi Fumiki

2. GFLS ≒ GitFlow
GitFlowと似てる

3. いつ使うの？
• 商用環境でミスをするこ
とが許されない怖い環境
• 計画的・定時リリースが
行われる環境
• 複数の開発者が存在する
環境
• 課題がたくさん存在し、
それが必ずしも採用され
るとは限らない環境
• 「あの広告表示機能、やっ
ぱいらないわ」という環
境
• Githubじゃないので、
GithubFlowできない環境

4. 基本ワークフロー
master
develop
feature
release
ロゴの差し替え
タブの追加
2015/03/12公開分
開発デプロイ
商用デプロイ

5. 基本原則
• masterブランチはどのコミットを商用環境にリリースしても問題のないブラン
チである。
• developブランチは開発の起点となるブランチであり、ステージング環境相当
である。
• すべての開発はdevelopブランチから枝分かれしたfeatureブランチで行う。
• 1つのfeatureブランチは課題管理システムにおける1つの課題に相当する。
• masterおよびdevelopへのデプロイはreleaseブランチを作成することで行う。
• masterブランチに対してのみ、例外的にhotfixブランチを作成することが許さ
れる。
• すべてのブランチをpushする。

6. 手順
• 課題に紐付いたfeatureブランチを作成する。名前はfeature/課題IDとする。各コミットには
課題への言及（およそのITSにはそういう機能がある）を含める。
• 必ず最新のdevelopブランチからfeatureブランチを作成する。
• リリースが決まったら、releaseブランチを最新のdevelopブランチから作成する。名前は
release/whatever-you-likeとする。
• releaseブランチに必要なfeatureブランチをマージしていく。競合が発生した場合は、
releaseブランチ上で解決する。
• マージする際は常にマージコミットを作成する。fast-forwardは行わない（他者から見て分か
りづらいため）
• releaseブランチが完了したらdevelopブランチからマージする。競合が発生した場合は
developブランチ上で解決する。
• developブランチはステージング環境相当であるため、この時点で確認は行われている。確認
して問題なければ、商用環境にリリースする。
• masterブランチにreleaseタグをつける。

7. よくある質問

8. Q.やっぱりいらない
develop
feature
release
ロゴの差し替え
タブの追加
2015/03/12公開分
このマージは
いらない

9. A. コミット取り消し
git reset - -hard
でブランチを戻してマー
ジしなおすか……
REVERT
git revert commit_id
で取り消し用コミット
を作成する

10. Q. 商用が真っ白に
master
develop
feature
release
ここで問題！
ヤベエｪｪ！

11. A. hotfixで治す
master
develop
hotfix developへのマージを忘れると、
masterとの差分が発生してしまう。
商用環境自体はmasterブランチを
一個戻せば治る。

12. Q.一部だけ必要に
develop
feature/hoge
BのJSがないと
開発が…
feature/fuga
A B C

13. A. Cherry Pick
develop
feature/hoge
feature/fuga
ただし、適切な粒度で開発され、細かくコミットされて
いることが条件。多くの場合、こんなに上手くいかない。
Aのコミットの
差分は来ない
A B C

14. Q. 放置したfeature
develop
release
feature
ずっと前に作ったのだが、たくさんの新機能が
すでにリリースされてしまった……

15. A. developをマージ
develop
release
feature
追いついた！

16. Q. テストサーバは？
master
develop
test

17. A. testブランチ作る
試したいfeatureブランチを集めたtestブランチを
都度作成する。いらなくなったら消す。
テストサーバに
デプロイ

18. Q. GithubFlowがよくね？

19. A. Github使うならYes
• Githubを業務に使ってない会社もあ
り、プルリクができない。
• コードレビューの体制がない場合もあ
る。
• テストコード？ なにそれ？ という
場所も多い。

20. 終わり
すてきなGitライフを！