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.0http://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