Git flowの活用事例

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

1

5秒で分かるあらすじ

• プロジェクトで困っていた• git-flowをカスタマイズして取り入れた

• 並行作業と振り返りが楽になった

2

2秒で分かるgit-flow

• 開発者も管理者も幸せになれる、ブランチとマージの活用ガイドライン

3

注意• 「gitとは何か」は説明しません

• VCS(バージョン管理システム)の1つ

• ブランチ管理が超強力

• 多人数の開発にもスケール

• 正式なgit-flowはチーム運営の指針も含んでますが、今回は説明しません

• 気になる方は原典へ

4

抱えていた問題• こんがらがったソースコード• 作業の度に全機能調査

• 修正が複数領域に

• 他の開発者(非git)と並行作業

• 他サービスへの移植も頻繁に発生…

http://mrg.bz/iiF6bR

5

• １つの作業に集中したい

• 安心して複数作業を進めたい

• プロジェクトレビューの準備を楽にしたい

• でも楽をしたい ← 大事

なんとかしたい

6

そこでひとまず

7

ソース管理にGitを使おう

• 今やVCSは必需品

• 作業も慣れている←手間にならない• gitにも慣れている

• 多人数(多タスク)にもスケール

「うーん、もう少し活用できないか調べてみるか」

8

あれ、

9

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

10

どんなものか調べてみた

11

Git力

...... ！

12

Time

release branches masterdevelop hot!xesfeature

branches

Feature for future

release

Tag

1.0

Major feature for

next release

From this point on, “next release”

means the release after 1.0

Severe bug !xed for

production:hot!x 0.2

Bug!xes from rel. branch

may be continuously merged back into develop

Tag

0.1

Tag

0.2

Incorporate bug!x in develop

Only bug!xes!

Start of release

branch for1.0

A successful Git branching modelhttp://nvie.com/posts/a-successful-git-branching-model/

「git-flow」

13

git-flow??

• 「ブランチ管理の戦略・ガイドライン」何をしたいのか

何をしているのか

何をしたのか、

が分かりやすくなる

14

git-flow?

• ブランチ管理を一定のルールで運用

• ブランチ元・マージ先を目的別に制限

• リリースと開発ライン、作業とを分離

作業が混ざらない

15

説明しよう

16

２系統ブランチと命名規則

命名規則 役割 寿命

メインブランチメインブランチ

サポートブランチサポートブランチサポートブランチ

master対外ブランチ。マイルストーンの記録

-

develop開発用。トピックブランチの生成/合流対象

-

feat/... 機能追加用 作業開始～

作業完了(hot)fix/... 不具合修正用

作業開始～

作業完了release リリース準備用

作業開始～

作業完了

常にブランチ上で作業を進める17

メインブランチ

18

master

• プロジェクト開始から完了まで生存

• いつでもリリース可能な状態

• develop(release)のマージ先

• タグ＝マイルストーン : α, β1, β2,…

masterの状態＝プロジェクトの進捗

ブランチ元マージ先

最初から存在-

master

β1.1

α1

α2

β1

(branches)

19

#x/a

develop

• プロジェクト開始から完了まで生存

• 開発中のバージョンを管理• トピックブランチはdevelop

から作成し、developに合流

• developでは作業しない

ブランチ元マージ先

-

master(マージ後も存在し続ける)

develop feat/A feat/B

20

サポートブランチ

21

feat/… and fix/…

• 機能実装(不具合修正)開始～完了まで生存

• 実際に作業を行うためのブランチ

• developからブランチ作成

• 実装完了時はdevelopにマージ

終わったらブランチ削除

ブランチ元マージ先

-

develop(マージ後は削除)

develop feat/*,#x/*

×

22

hotfix/…

• 修正開始～修正完了まで生存

• 臨時作業をこなすためのブランチ

• リリース直後の不具合修正

• masterからブランチ作成

実装完了時はdevelop/masterにマージ

終わったらブランチ削除

ブランチ元マージ先

master

develop, master(マージ後は削除)

master hot#x/*

×

α1.1

develop

不具合発見

α1

23

マージのルール• mergeは必ずnon fast-forwardで！

• デフォルトはfast-forward

git merge <ブランチ名> --no-ff

git config --global --add merge.ff false

• あるいは設定でデフォルト変更

24

マイルストーン：masterを見るだけ

作業は常にdevelopからのブランチで

• １機能/修正に集中出来る

管理を分けられる(スケールする)

git-flowを適用すると

25

なるほど便利そう

26

だけど

27

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

28

そこでテーラリング

29

1. ブランチをタグとして残す

2. satelliteブランチで他者ソースを管理

30

１.ブランチはタグで残す• feature,hotfixブランチのマージ後、ブランチ→タグに張り替える

あとから履歴が追いやすい例：実施した修正作業の数をカウントgit tag -n | grep hotfix/<旧ブランチ名> | wc -l

git branch -d feat/lpr && git tag feat/lpr

31

2.他開発者の歴史を区別

• メインブランチを１本追加

• メインブランチ

• サポートブランチサテライトブランチ

32

satelliteブランチ• プロジェクト開始から完了まで生存

• 他開発者(非git)の作業を追跡

• 子ブランチは特に作らない

• satelliteにコミット後、すぐdevelopへマージ

develop&各作業で最新を追跡可能

ブランチ元マージ先

(他開発者のVCSからクローン)

develop(マージ後も存在し続ける)

develop satellite他者の更新

他者の更新

33

• マイルストーン：masterを見るだけ

• 作業は常にdevelopからのブランチで

• １機能/修正に集中出来る

終わった作業はタグでトレースできる

他開発者の作業状況：satelliteブランチ

いつでも他拠点のソースを取り入れられる

このルールを適用すると

34

つまり

35

これがmaster

α1.1

機能A機能B

臨時修正

機能B

他開発者

機能A機能A

36

develop機能B機能A satellitemisc. master

こうなる

α1.1

他開発者

ライフタイムが一目瞭然

マイルストーンそのもの

他者のソースも随時同期

37

しかも

38

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

39

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

40

• 今の状態を一時的に退避

• gitの2段階コミットが活躍

• 作業が終わったらgit stash popで元通り

git stash git co -b hotfix/problem …臨時作業開始 git stash pop …元の作業再開

この不具合を最優先で明日までに直しておいてください

お客様

41

• 機能=ブランチで作業してきたので簡単

• 変更されたファイルだけを抽出

• 分散していたら、コミットをcherry-pick

でまとめてから実行

git archive -o archive.zip HEAD \ `git diff --name-only <ブランチ先頭> <ブランチ末尾> `

この機能、別でも使いたいので　ソースを一式ください

お客様

42

• ブランチ＝レビュー対象• 機能実装したときの変更履歴＝ブランチの変更履歴 ＝マージしたときのコミットログ(とdiff)

git archive -o archive.zip <マージコミット> \ `git diff --name-only <ブランチ先頭> <ブランチ末尾> `git log HEAD^..HEAD > CHANGELOG.txt

実装が済んだのでコードレビューしてください！自

分

※ 複数人で開発していればgit-pullがベター

43

• 歴史の二分探索• O(logn)で問題に到達

発見した不具合、以前は出ていなかったような気がします…Tester

git bisect start HEAD alpha_2_0 …安全点(α2)から調査開始 テストして結果を git bisect good / bad git bisect reset …調査終了。問題のコミットを調査

git bisect run <スクリプト>

• スクリプトで自動実行も可能

44

• 不具合の数＝“fix”または “hotfix” の付いたタグの数

git tag | grep "fix/" | wc -l

不具合の発生数を集計してください上

司

45

• ブランチ開始～マージの期間に着目

• 各ファイルがどれだけ変更されたか• 追加行数、削除行数• 移動・削除ファイルのマスク可

(ブランチごとに実施)git diff <ブランチ先頭>..<ブランチ末尾> --numstat

コード変更量を機能ごとにカウントして教えてください上

司

46

% git diff --dirstat=changes 127d6649 | sort -r

17.4% 3rdparty/lib/

16.1% modules/

10.5% data/vec_files/

10.1% 3rdparty/ffmpeg/

8.7% 3rdparty/

7.7% samples/cpp/

6.0% samples/gpu/

5.1% doc/

4.7% doc/tutorials/

3.3% interfaces/swig/python/

3.1% interfaces/swig/octave/

変更の多かったモジュールはどれですかぁ？図で見たいなぁ

上司

git diff <初回コミット> --dirstat | sort

3rdparty/lib17%

modules16%

data/vec_files10%

10%

9%

8%

その他7%

計測対象：OpenCVソース(所要時間3分)

47

要求定義

基本設計

詳細設計

実装 単体テスト

機能テスト

結合テスト

検収

「図解 はじめてのCMMIとプロセス改善」(橋本隆成著)から引用48

要求定義

基本設計

詳細設計

実装 単体テスト

機能テスト

結合テスト

検収

プロジェクト管理

監視と制御

リスク管理

構成管理

妥当性確認

品質保証 測定・分析

要件開発・管理

検証

技術解

構成は「図解 はじめてのCMMIとプロセス改善」(橋本隆成著)から引用49

結果として

50

1つ1つの作業に集中出来た

振り返りが楽になった

心理的負担が減少した

51

1つ1つの作業に集中出来た

• 他の作業・ソースが邪魔をしない

• 必要になればマージすればOK

52

振り返りが楽になった• コードレビューが行いやすくなった

• 機能のコンテキスト調査にブランチを見るだけ

• 不具合調査が効率的に行えた• 調査開始ポイントを１分で特定できたことも

• レトロスペクティブの準備が簡単だった• 集計作業が(ほぼ)機械的に行えた

53

心理的負担の低減• 割り込み作業にも安心して取り組めた

• 適当なコードでもどんどんコミットして後で整理できた

• 常にmaster==安定版

• デプロイ対象にゴミが混じらない

54

しかし課題も× サテライトブランチの運用に失敗した

• 終盤の頻繁な更新で運用を徹底出来ず

• 集計作業に支障をきたした

• 自動化すべきだった…

× gitの知識が求められる

• 適切な運用・集計などで差がつく(プロジェクト終了後に知った知識も…)

△ 他ツール(Jenkins,Gerrit)と連携できると良かった

55

まとめ• Gitとgit-flowはプロセス進行を助ける

• 他者からも一目瞭然

• とはいえ銀の弾丸ではない

• 運用ルールを守らないと意味が無い

• 餅は餅屋

56

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

57

58

おまけ

59

• git-flowのコマンドをスクリプト化するツールが公開されています

• https://github.com/nvie/gitflow

• OS XならSource Treeなどがサポート

60

チームで開発する場合• サーバー or リーダーのPCに中央リポジトリ

• developとmasterだけ生き続ける

• リリース前にreleaseブランチで作業

• 各メンバー• ローカルのdevelop = 中央のdevelop

• ソースリリース＝中央へのPull Request

61

gitここが便利• コミット前の整理が容易

• git rebase -i / git merge --squash

• 作業の途中で別の作業をしやすい

• git stash / git stash pop

• リポジトリがゴミ溜めにならない

• 軽くて強力なブランチ＆マージ

• svnな環境でもgit-svn使えば幸せ

62

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