Git flowの活用事例

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

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

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

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

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

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

7. そこでひとまず 7

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

9. あれ、 9

10. ？時々出てくる「git-ﬂow」って何？ 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-ﬂow?? • 「ブランチ管理の戦略・ガイドライン」何をしたいのか何をしているのか何をしたのか、が分かりやすくなる 14

15. git-ﬂow? • ブランチ管理を一定のルールで運用 • ブランチ元・マージ先を目的別に制限 • リリースと開発ライン、作業とを分離作業が混ざらない 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 ﬁx/… develop feat/*,fix/* • 機能実装(不具合修正)開始∼完了まで生存 • 実際に作業を行うためのブランチ • developからブランチ作成 • 実装完了時はdevelopにマージ × 終わったらブランチ削除ブランチ元 - マージ先 develop(マージ後は削除) 22

23. hotﬁx/… 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-ﬂowを適用するとマイルストーン：masterを見るだけ作業は常にdevelopからのブランチで • １機能/修正に集中出来る管理を分けられる(スケールする) 25

26. なるほど便利そう 26

27. だけど 27

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

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

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

31. １.ブランチはタグで残す • feature,hotﬁxブランチのマージ後、ブランチ→タグに張り替える 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. 不具合の発生数を上集計してください司 • 不具合の数＝“ﬁx”または “hotﬁx” の付いたタグの数 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_ﬁles/ 17% data/vec_ﬁles 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-ﬂowはプロセス進行を助ける • 他者からも一目瞭然 • とはいえ銀の弾丸ではない • 運用ルールを守らないと意味が無い • は屋 56

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

58. 58

59. おまけ 59

60. • git-ﬂowのコマンドをスクリプト化するツールが公開されています • https://github.com/nvie/gitﬂow • 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

Git flowの活用事例

You are reading a preview.

Git flowの活用事例

More Related Content

Slideshows for you

Viewers also liked

More from Hirohito Kato

Featured

Related Books

Related Audiobooks