GitFlow,GitHubFlow,GitLabFlowは使わない！ gitの新しいブランチモデル「GitFeatureFlow」を 考えたので紹介します

1. GitFlow,GitHubFlow,GitLabFlowはもう使わない！
GitFeatureFlow
を紹介します
by naoki koyama

2. 名 前：小山尚樹
勤務先：株式会社ぐるなび
スキル：2人の子供がいるので、
家事＆育児スキルがレベルアップ中
自己紹介
2

3. あらすじ
1-Gitのブランチモデル検討に困った。。。
2-GitFlow,GitHubFlow,GitLabFlowでもダメだった
3-GitFeatureFlowを考えた
4-2500回以上リリースしてるが、めちゃめちゃ楽になった
3

4. こんな人は必読
1-GitFlowを使ってる人
2-GitHubFlowをカスタマイズして使ってる人
3-動作確認後、すぐに本番リリースできない人
4-リリース日調整が大変な人
5-急なリリースが多く発生する人
4

5. 有名なブランチモデルが適用できなかった理由
GitFlow GitHubFlow GitLabFlow
フロー自体がかなり複雑で
毎日リリースしたり、リリー
ス日を変更するスタイルに
は向いていない。
本当は1番使いたい。
ただ、品質管理チームの
確認作業が発生する為、
即リリースができず使えな
い。
GitFlowよりシンプルだが、
リリース日の変更に柔軟
に対応できない。
5

6. ブランチモデルの比較 (あくまでも個人の感想です。)
比較する項目 GitFeatureFlow GitHubFlow GitFlow GitLabFlow
複数案件対応
◎ ◯ ☓ ◯
大規模開発向き
◎ △ ◎ ◯
小規模開発向き
◎ ◎ ☓ △
シンプルなフロー
◯ ◎ ☓ △
リリース時期の調整
◎ △ ◎ ◎
リリース日の変更
◎ △ △ △
コンフリクト関連
△ △ ◯ ◯
6

7. GitFeatureFlow
7

8. 説明の流れ
GitFeatureFlowはGitHubFlowを参考に考えているので、
下記の流れで説明します。
1-GitHubFlowの流れ
2-GitHubFlowを採用できない理由
3-GitFeatureFlowのポイント
8

9. 3-masterとの差分をレビュー
(pull request)
GitHubFlowの流れ
master
feature
branches
1-masterからbranchを作成
4-masterにマージして
本番環境へリリース
2-実装
9

10. GitHubFlowを採用できない理由
master
feature
branches
レビュー完了後、即本番環境へ出来ない。
つまり、リリース時間をコントロールできない。
【例】
開発者以外の動作確認を待つ必要がある。
iOSアプリの場合は、AppStoreの審査を通過する必要がある。
10

11. GitFeatureFlowの流れ
11

12. こんな開発を想定
1-動作確認やアプリ申請の為に、即リリースできない
2-毎日リリースする
3-急なリリースがよく発生する
4-大小様々なプロジェクトが同時に稼働している
5-リリース日の変更が多い
12

13. 3-masterとの差分をレビュー
(pull request)
GitFeatureFlowの全体の流れ
master
feature
branches
1-masterからbranchを作成
5-テスト環境での動作確認後、
masterにマージして
本番環境へリリース
test-env
テスト環境と同期されているブランチ
4-test-envとマージして、
テスト環境へリリース
動作確認を行う
2-実装
13

14. 3-masterとの差分をレビュー
(pull request)
GitFeatureFlowの流れ1
master
feature
branches
1-masterからbranchを作成
5-テスト環境での動作確認後、
masterにマージして
本番環境へリリース
test-env
テスト環境と同期されているブランチ
4-test-envとマージして、
テスト環境へリリース
動作確認を行う
2-実装
masterとfeature branchesの関係だけ見ればGitHubFlowと一緒です。
通常開発やバグ改修に関係なく、masterからfeature branchを作成します。 14

15. 3-masterとの差分をレビュー
(pull request)
GitFeatureFlowの流れ2
master
feature
branches
1-masterからbranchを作成
5-テスト環境での動作確認後、
masterにマージして
本番環境へリリース
test-env
テスト環境と同期されているブランチ
4-test-envとマージして、
テスト環境へリリース
動作確認を行う
2-実装
環境ごとにその環境と同期されているブランチが存在します。
例：テスト環境の場合はtest-env、ステージング環境の場合はstg-env等 15

16. 3-masterとの差分をレビュー
(pull request)
GitFeatureFlowの流れ3
master
feature
branches
1-masterからbranchを作成
5-テスト環境での動作確認後、
masterにマージして
本番環境へリリース
test-env
テスト環境と同期されているブランチ
4-test-envとマージして、
テスト環境へリリース
動作確認を行う
2-実装
テスト環境で動作確認をする場合は、test-envにfeature branchをマージします。
16

17. 3-masterとの差分をレビュー
(pull request)
GitFeatureFlowの流れ4
master
feature
branches
1-masterからbranchを作成
5-テスト環境での動作確認後、
masterにマージして
本番環境へリリース
test-env
テスト環境と同期されているブランチ
4-test-envとマージして、
テスト環境へリリース
動作確認を行う
2-実装
本番リリースが確定した時点で、feature branchをmasterへマージします。
17

18. 4-test-envとマージして、
テスト環境へリリース
動作確認を行う
3-masterとの差分をレビュー
(pull request)
GitFeatureFlowのフロー補足
master
feature
branches
1-masterからbranchを作成
6-ステージング環境での動作確認後、
masterにマージして
本番環境へリリース
test-env
テスト環境と同期されているブランチ
stg-env
ステージング環境と同期されているブランチ
5-stg-envとマージして、
ステージング環境へリリース
動作確認を行う
2-実装
補足：複数環境が存在する場合は、それぞれにfeature branchをマージします。
18

19. GitFeatureFlowのポイント
19

20. ポイント
1-feature branchが独立し、他のブランチと依存関係にない
2-環境ごとにその環境と同期がとれたブランチが存在する
3-feature branchを環境ごとのブランチにマージする
4-コンフリクト発生時も修正は必ずfeature branch内で行い、
master以外の他のブランチをマージしない
(masterだけはマージしてもOK)
5-レビューは常にmasterだけ行う
(他のブランチでレビューしない) 20

21. feature branchが独立し、
他のブランチと依存関係にない
とは？
21

22. 標準的なGitFlowを使って複数案件を対応している場合
22

23. GitFlowの場合
develop
feature
branches
release
branch
複数案件を対応中
GitFlowで複数案件を対応している場合は、developからrelease branchを分岐するので、
developが安定した状態である必要がある。 23

24. 1つの案件のリリース日が変更になったら・・・
24

25. 即死亡
25

26. 本当はGitFlowでも対応はできるが、
方法がかなり煩雑になるため、
出来る限りやりたくない。。。
26

27. 1つの案件のリリース日が変更になった
develop
feature
branches
release
branch
複数案件を対応中
２つの案件をdevelopにマージしている為、片方の案件をdevelopから
取り除く必要がある。つまりブランチ同士の依存関係ができてしまっている。 27

28. GitFeatureFlowの場合
28

29. 1つの案件のリリース日が変更になった
master
feature
branches
複数案件を対応中
テスト環境と同期されているブランチ
test-env
GitFeatureFlowで複数案件を対応している場合。
29

30. 1つの案件のリリース日が変更になったら・・・
30

31. ブランチをマージしなければいいだけ！
31

32. 1つの案件のリリース日が変更になった
master
feature
branches
複数案件を対応中
テスト環境と同期されているブランチ
test-env
赤くなっているのが、リリース日の変更があったブランチのマージ。
このマージをやめればいいだけ！ 32

33. 1つの案件のリリース日が変更になった
master
feature
branches
複数案件を対応中
テスト環境と同期されているブランチ
test-env
各ブランチが独立していて依存関係にないので、他のブランチを気にせず、
masterへのマージのタイミングを変えればいいだけ。 33

34. まとめ
テスト環境 ステージ環境 本番環境
GitFlow
GitFeatureFlow
feature A
feature B
develop
feature A
feature B
feature A
feature B
develop
feature A
develop
feature A
feature B
feature A feature A
GitFlowはdevelopをマージしていく為、AとB案件が依存状態にある。
GitFeatureFlowはAとB案件が独立している為、リリース日変更が容易。
feature B
Bを取り除くのが大変
feature A
develop
feature B
Bを取り除くのが大変
環境
Flow
34

35. GitFeature Flowの実際の作業
35

36. 事前準備
以下、事前準備です。
1-リポジトリ作成
2-環境ごとにmasterからブランチを作成
例：テスト環境の場合、test-envなど
3-環境ごとにブランチと同期を取れる仕組みを構築
とはいえ、テスト環境の場合は、test-envとrsyncを行うだけでいいはず。
36

37. 作業の解説
37
これから実際の作業を解説します。
わかりやすいように下記作業を詳細に解説します。
1-ある案件をコーディングして、レビュー後にテスト環境に反映
2-動作確認によりバグを発見し、再修正して、テスト環境へ再反映
3-ステージング環境へ反映し、動作確認後、本番リリースを行う

38. 作業1
「1-ある案件をコーディングして、レビュー後にテスト環境に反映」
01-masterからブランチ(ex:new_feature)を作成
(通常案件でもバグ改修でも同じフロー)
02-new_featureをコーディング、commit、push
03-masterとnew_featureの差分比較を行いレビュー
(pull requestがあれば尚良。ただし、マージは絶対にしない)
レビューは常にmasterとだけ行う
04-test-envにnew_featureをマージする
05-test-envをテスト環境へリリースする
38

39. 作業2
「2-動作確認によりバグを発見し、再修正して、テスト環境へ再反映」
06-テスト環境で動作確認し、バグを発見
07-new_featureをコーディング、commit、push
08-masterとnew_featureの差分比較を行いレビュー
レビューは常にmasterとだけ行う
test-envとレビューした場合は、他の案件の差分も出てしまう
09-test-envにnew_featureをマージする
10-test-envをテスト環境へリリースする
39

40. 作業3
「3-ステージング環境へ反映し、動作確認後、本番リリースを行う」
11-stg-envにnew_featureをマージする
12-stg-envをステージング環境へリリースする
13-ステージング環境で動作確認を行う
14-masterにnew_featureをマージする
15-masterを本番環境へリリースする
40

41. 補足
テスト環境 ステージ環境 本番環境
マージタイミング いつでも良い 本番リリースの
1日前に反映
毎日10:00に反映
マージ依頼方法
(マージしたいブランチごと
に依頼する)
依頼せず個人で反映 stg-envにpull request
してあるもの
masterにpull request
してあり、マイルストー
ンが当日のもの
マージするブランチ feature A
feature B
補足として、運用のコツです。(死守する必要はありません。)
複数案件を同時にリリースする場合は、環境ごとにマージするタイミングや依頼
方法を決めておくと自動リリースなどが行いやすいです。
環境
41
feature C
feature A
feature B
feature A
feature B

42. コンフリクトが起きた時は？
42

43. コンフリクトが起きた時は？
1-他のブランチをマージせず、コンフリクトが起きてる2つのブランチを確認して、
コンフリクトが起きてる「行」だけを正しい形に修正します。
2-正しい形になっているかどうかはmasterとの差分比較を見て、
その状態でリリース可能かどうかを判断します。
3-コンフリクトした時は、それぞれのブランチに最新版のmasterを
マージすると解消する場合があります。
-補足-
他のブランチをマージしないのは、それぞれのブランチの独立性を守ることで、
リリースの柔軟性を維持し、他の人の作業を気にせずリリースできるように
しているからです。
43

44. Q&A
44

45. Q:
GitFlowの場合は、1つの案件を進めると他の案件が進めづらいので、
リリース日と順番を厳粛に守るように運用しています。
GitFeatureFlowを使うとそれが解消されるのでしょうか？
A:
はい。解消されます。
リリース日の変更などに柔軟に対応できるようになり、
複数案件を同時に進めれるので、開発効率とスピードが格段に上がると思います。
45

46. Q:
複数案件をまとめてリリースする場合のマージはどこでやるんでしょうか？
A:
まとめてリリースする場合も1つずつfeature branchを環境ごとのブランチにマージしてい
きます。テスト環境、ステージング環境、本番環境の3つの環境に
リリースする場合は、案件ごとに3つのブランチにマージする事になります。
46

47. Q:
GitHubFlowでDockerを使って、ブランチ毎に確認環境を自動生成しています。
GitFeatureFlowの必要性がわからないのですが？
A:
1つの案件の確認で業務が回る場合は、とてもいいやり方だと思います。
ただし、複数案件が存在している状態を確認しようと思った時には、上記方法は使え
ません。
47

48. 最後に
48

49. 最後に
GitFeatureFlowを導入してから、3年弱、2500回以上リリースを行ってきましたが、この
フローが原因でのバグは一度も出ていません。
何よりリリース日を気にすることなく、シンプルなフローで作業ができて、
心理的にもいいことばかりです。
皆さんもステキなGit生活をお過ごし下さい！
49

50. おわり
50