Download to read offline
[社内勉強会]Pull requestを使おう
- 1.
- 2.
- 3. PullRequestのフロー 1. ka4君はあるリポジトリA のdevelopブランチをforkして、リ ポジトリA‘を作り、そこに今回の変更を加えたコミットを追 加した 2.そしてリポジトリAの管理者 (ko8君) に、「A' の develop ブ ランチに変更おいてあるのでpullしてくれ」と要求する 3. ko8君がそれを確認し、A' -> A に merge を行う。 これが基本的な処理フロー もっとわかりやすくするとこうなる
- 4. PullRequestのフロー２ 1. 今回portalの精算画面と勤怠画面を修正することになった 2. Erika君はportalのmasterブランチから新たに精算修正ブラン チ（feat_account)を作成して修正を追加した 3.Toru君もmasterブランチから新たに勤怠修正ブランチ （feat_time)を作成して修正を追加した 4. そして二人はportalの今回の修正の管理者 (ko8君) に、各々の ブランチ（ feat_account、feat_time)からmasterへのpull リク エストを要求する 5. ko8君がそれを確認(レビュー)しmaster に merge を行う。 こんな感じ
- 5.
- 6. 主な変更パターン① Tomoko君はko8君にcommonクラスの変更・ 対応を依頼する ko8君の責任 commonクラス Ko8君の責任 ko8 tomoko ＋ 依頼 1.Tomokoはko8に「こういう機能が足りないんだけど、追加しろよ！」と 依頼する 2. Ko8は泣きながら対応する 3. Tomokoはそいつを利用する
- 7. 主な変更パターン① このパターンの問題 • オーバーヘッドが大きい • Ko8君がいつ対応してくれるかという問題 •変更の依頼・対応は、コミュニケーションコストが 大きい • 「今すぐ欲しいのに」に対応できない • コミュニケーションミスで、修正されたのに「コレ じゃない」問題
- 8. 主な変更パターン② Tomoko君はko8君に確認をとり、変更しコミッ トする ko8君の責任 commonクラス tomoko君の責任 ko8 tomoko 確認 ＋ 1.Tomokoはcommonの修正箇所を探し当て、そこに変更を加える 2. Ko8にdiff見せて、「こういう変更してもいい？」って確認とる 3. Ko8は「大丈夫だ。問題ない」 4. Tomokoはドヤ顔でコミットする
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15. PullRequestでのパターン Tomoko君はko8君に確認をとり、変更しコミッ トする ko8君の責任 commonクラス tomoko君の責任 ko8 tomoko 確認 ＋ 1. Tomokoはローカルブランチでcommonに修正を加え、パッチをつくる 2. TomokoはKo8にpullRequestを送る 3.Ko8はそれを確認（レビュー、リファクタリング）する 4. 変更を取り込む パッチ
- 16.
- 17.
- 18. PullRequestメリット •パッチは小さいにこしたことは ない ソースコードへの変更は、大きければ大きいほど影響 範囲やバグの混入する確率も大きくなるので、パッチ は小さければ小さい方が良い 小さな patch ごとにレビューが入るため、コストが小 さく、議論が1点に集中できるため質も高い 小さなdiff であればあるほど、小さなコストで確認が できる。それを繰り返すことが重要だ
- 19.
- 20.
- 21.
- 22.
- 23.