社内で技術発表会を行ったときのスライドです。 git-flowの基本的なルール説明と、git-flow運用下での管理テクニックについて説明しています。

1. git-flowと
プロジェクト運営
1

2. 5秒で分かるあらすじ
• プロジェクトで困っていた
• git-flowをカスタマイズして取り入れた
• 並行作業と振り返りが楽になった
2

3. 2秒で分かるgit-flow
• 開発者も管理者も幸せになれる、
ブランチとマージの活用ガイドライン
3

4. 注意
• 「gitとは何か」は説明しません
• VCS(バージョン管理システム)の1つ
• ブランチ管理が超強力
• 多人数の開発にもスケール
• 正式なgit-flowはチーム運営の指針も含んでますが、
今回は説明しません
• 気になる方は原典へ
4

5. 抱えていた問題
• こんがらがったソースコード
• 作業の度に全機能調査
• 修正が複数領域に
• 他の開発者(非git)と並行作業
• 他サービスへの移植も頻繁に発生…
http://mrg.bz/iiF6bR
5

6. なんとかしたい
• １つの作業に集中したい
• 安心して複数作業を進めたい
• プロジェクトレビューの準備を楽にし
たい
• でも楽をしたい ← 大事
6

7. そこでひとまず
7

8. ソース管理にGitを使おう
• 今やVCSは必需品
• 作業も慣れている←手間にならない
• gitにも慣れている
• 多人数(多タスク)にもスケール
「うーん、もう少し活用できないか調べてみるか」
8

9. あれ、
9

10. ？時々出てくる
「git-flow」って何？
10

11. どんなものか
調べてみた
11

12. Git力
...... ！
12

13. feature
release branches
branches develop hotfixes master
Tag
Time
0.1
Major Severe bug
feature for fixed for
Feature
next release production:
for future hotfix 0.2
release
Incorporate
bugfix in
develop
「git-flow」
Tag
0.2
Start of
release
branch for
1.0
A successful Git branching model
From this point on,
“next release”
means the release
after 1.0
http://nvie.com/posts/a-successful-git-branching-model/ Only
bugfixes!
Bugfixes from Tag
rel. branch
may be 1.0
continuously
merged back
into develop
13

14. git-flow??
• 「ブランチ管理の戦略・ガイドライン」
何をしたいのか
何をしているのか
何をしたのか、
が分かりやすくなる
14

15. git-flow?
• ブランチ管理を一定のルールで運用
• ブランチ元・マージ先を目的別に制限
• リリースと開発ライン、作業とを分離
作業が混ざらない
15

16. 説明しよう
16

17. ２系統ブランチと命名規則
命名規則 役割 寿命
対外ブランチ。
master -
メイン マイルストーンの記録
ブランチ 開発用。トピックブランチ
develop -
の生成/合流対象
feat/... 機能追加用 作業開始
サポート
(hot)fix/... 不具合修正用 ∼
ブランチ release リリース準備用 作業完了
常にブランチ上で作業を進める
17

18. メインブランチ
18

19. master
master (branches)
• プロジェクト開始から完了まで
α1
生存
• いつでもリリース可能な状態 α2
• develop(release)のマージ先
• タグ＝マイルストーン : α, β1, β2,…
β1
masterの状態＝プロジェクトの進 β1.1
ブランチ元 最初から存在
マージ先 -
19

20. develop
develop feat/A feat/B fix/a
• プロジェクト開始から完了ま
で生存
• 開発中のバージョンを管理
• トピックブランチはdevelop
から作成し、developに合流
• developでは作業しない
ブランチ元 -
マージ先 master(マージ後も存在し続ける)
20

21. サポートブランチ
21

22. feat/… and fix/…
develop feat/*,fix/*
• 機能実装(不具合修正)開始∼完了ま
で生存
• 実際に作業を行うためのブランチ
• developからブランチ作成
• 実装完了時はdevelopにマージ ×
終わったらブランチ削除
ブランチ元 -
マージ先 develop(マージ後は削除)
22

23. hotfix/…
master hotfix/* develop
• 修正開始∼修正完了まで生存 α1
• 臨時作業をこなすためのブランチ
不具合発見
• リリース直後の不具合修正
• masterからブランチ作成
×
実装完了時はdevelop/masterにマージ
α1.1
終わったらブランチ削除
ブランチ元 master
マージ先 develop, master(マージ後は削除)
23

24. マージのルール
• mergeは必ずnon fast-forwardで！
• デフォルトはfast-forward
git merge <ブランチ名> --no-ff
• あるいは設定でデフォルト変更
git config --global --add merge.ff false
24

25. git-flowを適用すると
マイルストーン：masterを見るだけ
作業は常にdevelopからのブランチで
• １機能/修正に集中出来る
管理を分けられる(スケールする)
25

26. なるほど便利そう
26

27. だけど
27

28. オリジナルのスタイル
≠対象プロジェクトのスタイル
28

29. そこでテーラリング
29

30. 1. ブランチをタグとして残す
2. satelliteブランチで他者ソースを
管理
30

31. １.ブランチはタグで残す
• feature,hotfixブランチのマージ後、ブラ
ンチ→タグに張り替える
git branch -d feat/lpr && git tag feat/lpr
あとから履歴が追いやすい
例：実施した修正作業の数をカウント
git tag -n | grep hotfix/<旧ブランチ名> | wc -l
31

32. 2.他開発者の歴史を区別
• メインブランチを１本追加
• メインブランチ
• サポートブランチ
サテライトブランチ
32

33. satelliteブランチ
develop satellite
• プロジェクト開始から完了まで生存 他者
の更新
• 他開発者(非git)の作業を追跡
• 子ブランチは特に作らない
他者
• satelliteにコミット後、すぐdevelopへ の更新
マージ
develop&各作業で最新を追跡可能
ブランチ元 (他開発者のVCSからクローン)
マージ先 develop(マージ後も存在し続ける)
33

34. このルールを適用すると
• マイルストーン：masterを見るだけ
• 作業は常にdevelopからのブランチで
• １機能/修正に集中出来る
終わった作業はタグでトレースできる
他開発者の作業状況：satelliteブランチ
いつでも他拠点のソースを取り入れられる
34

35. つまり
35

36. これが
master
他開発者
機能B
機能A
臨時修正
α1.1
36

37. こうなる
機能A 機能B develop misc. master satellite
他開発者
他者のソース
も随時同期
ライフタイム
が一目瞭然
α1.1
マイルストーン
そのもの
37

38. しかも
38

39. プロジェクト進行中
に生じる
39

40. 雑多な作業が
簡単に実現できると判明
40

41. お
この不具合を最優先で明日までに
客
様
直しておいてください
• 今の状態を一時的に退避
• gitの2段階コミットが活躍
• 作業が終わったらgit stash popで元通り
git stash
git co -b hotfix/problem …臨時作業開始
git stash pop …元の作業再開
41

42. お
この機能、別でも使いたいので
客
様
ソースを一式ください
• 機能=ブランチで作業してきたので簡単
• 変更されたファイルだけを抽出
• 分散していたら、コミットをcherry-pick
でまとめてから実行
git archive -o archive.zip HEAD
`git diff --name-only <ブランチ先頭> <ブランチ末尾> `
42

43. 実装が済んだので
自
分 コードレビューしてください！
• ブランチ＝レビュー対象
• 機能実装したときの変更履歴
＝ブランチの変更履歴
＝マージしたときのコミットログ(とdiff)
git archive -o archive.zip <マージコミット>
`git diff --name-only <ブランチ先頭> <ブランチ末尾> `
git log HEAD^..HEAD > CHANGELOG.txt
※ 複数人で開発していればgit-pullがベター
43

44. 発見した不具合、以前は出ていな
Tester
かったような気がします…
• 歴史の二分探索
• O(logn)で問題に到達
git bisect start HEAD alpha_2_0 …安全点(α2)から調査開始
テストして結果を git bisect good / bad
git bisect reset …調査終了。問題のコミットを調査
• スクリプトで自動実行も可能
git bisect run <スクリプト>
44

45. 不具合の発生数を
上 集計してください
司
• 不具合の数
＝“fix”または “hotfix” の付いたタグの数
git tag | grep "fix/" | wc -l
45

46. コード変更量を機能ごとに
上
司 カウントして教えてください
• ブランチ開始∼マージの期間に着目
• 各ファイルがどれだけ変更されたか
• 追加行数、削除行数
• 移動・削除ファイルのマスク可
(ブランチごとに実施)
git diff <ブランチ先頭>..<ブランチ末尾> --numstat
46

47. 変更の多かったモジュールは
上
司 どれですかぁ？図で見たいなぁ
git diff <初回コミット> --dirstat | sort
% git diff --dirstat=changes 127d6649 | sort -r
17.4% 3rdparty/lib/
modules
16.1% modules/ 3rdparty/lib
16%
10.5% data/vec_files/ 17%
data/vec_files
10.1% 3rdparty/ffmpeg/
10%
8.7% 3rdparty/ その他
7.7% samples/cpp/ 7%
6.0% samples/gpu/ 10%
5.1% doc/
4.7% doc/tutorials/ 9%
3.3% interfaces/swig/python/ 8%
3.1% interfaces/swig/octave/
計測対象：OpenCVソース(所要時間3分)
47

48. 要求定義 検収
基本設計 結合テスト
詳細設計 機能テスト
実装 単体テスト
「図解 はじめてのCMMIとプロセス改善」(橋本隆成著)から引用
48

49. 要件開発・管理 妥当性確認
プロジェクト管理
要求定義 検収
基本設計 結合テスト 監視と制御
詳細設計
技術解機能テスト
実装 単体テスト
リスク管理
検証
構成管理 品質保証 測定・分析
構成は「図解 はじめてのCMMIとプロセス改善」(橋本隆成著)から引用
49

50. 結果として
50

51. 1つ1つの作業に集中出来た
振り返りが楽になった
心理的負担が減少した
51

52. 1つ1つの作業に集中出来た
• 他の作業・ソースが邪魔をしない
• 必要になればマージすればOK
52

53. 振り返りが楽になった
• コードレビューが行いやすくなった
• 機能のコンテキスト調査にブランチを見るだけ
• 不具合調査が効率的に行えた
• 調査開始ポイントを１分で特定できたことも
• レトロスペクティブの準備が簡単だった
• 集計作業が(ほぼ)機械的に行えた
53

54. 心理的負担の低減
• 割り込み作業にも安心して取り組めた
• 適当なコードでもどんどんコミットし
て後で整理できた
• 常にmaster==安定版
• デプロイ対象にゴミが混じらない
54

55. しかし課題も
× サテライトブランチの運用に失敗した
• 終盤の頻繁な更新で運用を徹底出来ず
• 集計作業に支障をきたした
• 自動化すべきだった…
× gitの知識が求められる
• 適切な運用・集計などで差がつく
(プロジェクト終了後に知った知識も…)
△ 他ツール(Jenkins,Gerrit)と連携できると良かった
55

56. まとめ
• Gitとgit-flowはプロセス進行を助ける
• 他者からも一目瞭然
• とはいえ銀の弾丸ではない
• 運用ルールを守らないと意味が無い
• は 屋
56

57. ご清聴ありがとうございました
57

58. 58

59. おまけ
59

60. • git-flowのコマンドをスクリプト化する
ツールが公開されています
• https://github.com/nvie/gitflow
• OS XならSource Treeなどがサポート
60

61. チームで開発する場合
• サーバー or リーダーのPCに中央リポジトリ
• developとmasterだけ生き続ける
• リリース前にreleaseブランチで作業
• 各メンバー
• ローカルのdevelop = 中央のdevelop
• ソースリリース＝中央へのPull Request
61

62. gitここが便利
• コミット前の整理が容易
• git rebase -i / git merge --squash
• 作業の途中で別の作業をしやすい
• git stash / git stash pop
• リポジトリがゴミ溜めにならない
• 軽くて強力なブランチ＆マージ
• svnな環境でもgit-svn使えば幸せ
62

63. Windowsでも使える
• msysGit 1.7.10からUTF-8対応
• Visual Studio(2012.2 & TFS)でもサポート
• http://blogs.msdn.com/b/bharry/archive/
2013/01/30/git-init-vs.aspx
• TortoiseGitも(今ならあまり)遅くない
• Win版SourceTreeも開発中！
63