Pretty Good Branch Strategy for Version Control System such as Git or Mercurial.

1. Pretty Good
Branch Strategy
for Git/Mercurial
Git/Mercurialのためのわかりやすいブランチ戦略
makoto kuwata
http://www.kuwata-lab.com/

2. Version Number

3. Ver.1.2.3

4. Ver.1.2.3
Major Version
・大幅な機能拡張
・後方互換性はないことが多い

5. Ver.1.2.3
Minor Version
・後方互換性を保ったままでの拡張
（やむを得ず保たれないこともある）

6. Ver.1.2.3
Patch Level
・バグ修正が目的（機能拡張はしない）
・後方互換性は極力保たれる

7. Version v.s Branch

8. Ver.1.2.3
Development Branch
Release Branch
Release Tag

9. Major Version Development Branch
1 1
N N
Minor Version Release Branch
1 1
N N
Patch Level Release Tag

10. Practical Example

11. Major Versionごとに
開発用ブランチを用意
dev-1
(ver 1.x用branch)

12. dev-1
(ver 1.x用branch)
dev-2
(ver 2.x用branch)
Major Versionを上げるたびに
新しい開発用ブランチを作成

13. Minor Versionごとに
リリース用ブランチを作成
rel-1.0
(ver 1.0用branch)
dev-1
(ver 1.x用branch)

14. リリースに伴う作業は
リリース用ブランチで行う
rel-1.0
(ver 1.0用branch)
dev-1
(ver 1.x用branch)

15. リリースしたら
タグを打つ
r1.0.0
rel-1.0
(ver 1.0用branch)
dev-1
(ver 1.x用branch)

16. リリースのたびに
タグを打つ
r1.0.0 r1.0.1
rel-1.0
(ver 1.0用branch)
dev-1
(ver 1.x用branch)

17. Patch Levelを上げるたびに
これを繰り返す
r1.0.0 r1.0.1 r1.0.2
rel-1.0
(ver 1.0用branch)
dev-1
(ver 1.x用branch)

18. Minor Versionを上げるときは
新しいリリース用ブランチを作成
rel-1.0 rel-1.1
(ver 1.0用branch) (ver 1.1用branch)
dev-1
(ver 1.x用branch)

19. Other Topics

20. • リリースブランチは削除しない（git flowとは違う！）
• "master" や "trunk" は使わない （プロジェクトによって
開発用だったりリリース用だったりするので混乱の元）
• Topic Branch は強く推奨される
• リリースブランチに適用したコミットは、必要なら
cherry-pickで開発用ブランチにも適用する（逆も可）
• git cherry -v rel-1.0 dev-1 e!
esom
aw

21. Conclusion

22. r1.0.0 r1.0.1
rel-1.0 rel-1.1
(ver 1.0用branch) (ver 1.0用branch)
dev-1
(ver 1.x用branch)
dev-2
(ver 2.x用branch)

23. One More Thing...

24. ~/.gitconfig
[alias]
st = status -sb
ci = commit
co = checkout
correct = commit --amend
switch = checkout
fork = checkout -b
join = merge --no-ff
stage = add
staged = diff --cached
stashed = stash list
history = log --oneline --graph --date=short --decorate
commitdiff = cherry -v

25. おしまい