1. こわくないプルリク
Pull Request is not afraid
2013.06.14 - kanazawa.rb #10

2. Github
http://github.com

3. Pull Request

4. Pull Request

5. なにするもの？
自分のコードを
取り込んでもらう手続き

6. こわいの？
迷惑をかける
可能性があるので
ちょっとびびる

7. こわいの？
こわくはない
（迷惑の中身を知れば）

8. Let's Start

9. ルール
• 分岐元が同じブランチどうしで使える
• 以上

10. Fork は？
Fork は必須ではない
むしろ一人でもできる

11. master
work
A
A
B
1. checkout -b work
2. commit

12. A
A
B
マージして
master
work
1. checkout -b work
2. commit

13. A
A
B
いいよ
B
3. merge
master
work
1. checkout -b work
2. commit

14. Shared Repository Model
• 共用リポジトリで利用
• Collaborators
• Organizations

15. A
B
B
A B
4. push
A
1. clone
5. merge
master
work
2. checkout -b work
3. commit

16. Fork & Pull Model
• User 間で利用

17. A B
A
1. fork
B
A B
A
6. pull
master
work
master
5. push
2. clone
3. checkout -b work
4. commit

18. Send Pull Request

19. Send Pull Request

20. Send Pull Request

21. Send Pull Request

22. Receive Pull Request

23. Receive Pull Request

24. Merge Pull Request

25. Merge Pull Request

26. まったく簡単だ

27. 迷惑パターン

28. 迷惑パターン
• Pull Request 後のコミット
• コンフリクト
• 大量のコミット

29. Pull Request 後のコミット
• Pull Request の対象はブランチ
• クローズ前に追加コミットすると
• Pull Request の対象に含まれてしまう
• Pull Request 先に Notification が飛ぶ
• コードレビュー＆修正反映の用途に対応するため

30. A
B
A B
4. push
A
1. clone
master
work
2. checkout -b work
3. commit

31. A
B
A B
4. push
A
1. clone
master
work
2. checkout -b work
3. commit
C
C
D
D
5. commit 7. commit
6. push 8. push

32. Pull Request 後のコミット
• コードレビュー目的
• まったく問題ない利用法
• 別機能の開発目的
• 問題のある（迷惑な）利用法
• 別ブランチで作業をすることで解決

33. コンフリクト
• 元ソースの変更に追従していないと発生する
• こまめな pull & rebase で解決

34. A
B
X
A B
4. push
A
1. clone
5. merge
master
work
2. checkout -b work
3. commit
commit

35. B
master
A
B'
X
A
6. push
1. clone
7. merge
master
work
2. checkout -b work
3. commit
B'
B'
X
4. pull
A
commit
X
5. rebase

36. A X
A
1. fork
B
A B
A
6. pull
master
work
master
5. push
2. clone
3. checkout -b work
4. commit
commit

37. B
5. rebase
master
A X
A
1. fork
B'
A X
A
8. pull
master
work
master
7. push
2. clone
3. checkout -b work
4. commit
commit
B'
X
5. pull
B'

38. B
5. rebase
master
A X
A
1. fork
B'
A X
A
8. pull
master
work
master
7. push
2. clone
3. checkout -b work
4. commit
commit
B'
X
5. pull
B'

39. Tips : Fork 元から pull
1. git remote add upstream https://github.com/<org>/<rep>.git
2. git checkout master
3. git pull upstream master

40. B
5. rebase
master
A X
A
1. fork
B'
A X
A
8. pull
master
work
master
7. push
2. clone
3. checkout -b work
4. commit
commit
B'
X
5. pull
B'

41. Tips : rebase ? merge ?
• merge ではなく rebase
• 後述のコミットの集約を実現するため
• rebase 前にブランチを push していた場合
• rebase 後に push する際は -f オプションが必要
• rebase の功罪もあり merge 派もいる
• コミットの集約はしない運用

42. 大量のコミット
• コミット数が大量にある Pull Request
• コーディング作業時に細かにコミットしていれば
よくある状況

43. A P
A B
4. push
A
1. clone
5. merge
master
work
2. checkout -b work
3. commiiiiiiiiiiits
BBBBBBBBBBBBBBP
BBBBBBBBBBBBBBBP
PPPPPPPPPPPPPP

44. 大量のコミット
• Pull Request 先でのコミットログ肥大化
• 差分を確認するのが困難になる
• rebase -i で1コミットにまとめることで解決
1. git checkout work
2. git rebase -i master
3. pick, squash, squash, squash...

45. A
A
5. push
A
1. clone
6. merge
master
work
3. commiiiiiiiiiiits
BP'
P'
P
P'
2. checkout -b work
4. rebase -i (squash)

46. Tips : Pull Request Branch
• 作業用ブランチの履歴を残したい場合
• Pull Request 専用ブランチを作成する
1. git checkout work
2. git checkout -b pr-work
3. git rebase -i master
4. pick, squash, squash, squash...

47. Conclusion
• Pull Request は怖くない
• 機能毎のブランチング
• こまめな pull & rebase
• コミットの集約（rebase -i）

48. Conclusion
• Pull Request は怖くない
• 機能毎のブランチング
• こまめな pull & rebase
• コミットの集約（rebase -i）
"絶対" のルールはない
（なにがおこるか把握して使えばよい）

49. まずは自分のリポジトリで
ブランチさえ切ればすぐ試せる！

50. Thank you
Tomokazu Kiyohara
http://github.com/kiyohara
http://facebook.com/tomokazu.kiyohara

51. Extra
• http://blog.qnyp.com/2013/05/28/pull-request-for-github-beginners/
• http://kik.xii.jp/archives/179
• http://d.hatena.ne.jp/hnw/20110528