Pull Requestオープンソースだけじゃない！！

PullRequestとは主に GitHub でこう呼ばれる

複数のリポジトリ・ブランチ間でのオープンな patch のやりとりこと

PullRequestのフロー1. ka4 君はあるリポジトリ A の develop ブランチを fork して、リポ

ジトリ A‘ を作り、そこに今回の変更を加えたコミットを追加した

2. そしてリポジトリ A の管理者 (ko8 君 ) に、「 A' の develop ブランチに変更おいてあるので pull してくれ」と要求する

3. ko8 君がそれを確認し、 A' -> A に merge を行う。

これが基本的な処理フロー

もっとわかりやすくするとこうなる

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 を行う。

こんな感じ

例題今回 tomoko 君は portal に新たに画面を追加すること

になった今回の追加により、既存の共通クラス（ common) の

DB 接続クラスを変更する必要がある共通クラスの管理者は ko8 君であるtomoko 君の他に ka4 君も別の画面の修正をしている

そんな場合の commonクラスの修正の仕方を考える

主な変更パターン①Tomoko 君は ko8 君に common クラスの変更・対応を依頼する

ko8 君の責任

common クラス

Ko8 君の責任ko8 tomoko

＋ 依頼

1. Tomokoは ko8に「こういう機能が足りないんだけど、追加しろよ！」と依頼する

2. Ko8は泣きながら対応する3. Tomokoはそいつを利用する

主な変更パターン①このパターンの問題• オーバーヘッドが大きい• Ko8 君がいつ対応してくれるかという問題•変更の依頼・対応は、コミュニケーションコストが大きい•「今すぐ欲しいのに」に対応できない•コミュニケーションミスで、修正されたのに「コレじゃ

ない」問題

主な変更パターン②Tomoko 君は ko8 君に確認をとり、変更しコミットする

ko8 君の責任

common クラス

tomoko 君の責任ko8 tomoko

確認 ＋

1. Tomokoは commonの修正箇所を探し当て、そこに変更を加える2. Ko8 に diff 見せて、「こういう変更してもいい？」って確認とる3. Ko8 は「大丈夫だ。問題ない」4. Tomoko はドヤ顔でコミットする

主な変更パターン②このパターンの問題•コミュニケーションのとれたチームじゃないと無理•仲悪いとかそういう意味じゃなくて、物理的に作業場所が遠い場合とか•こいつもコミュニケーションコストが大きい

主な変更パターン③Tomoko 君は変更せずに解決する方法を探す

ko8 君の責任common クラス

Tomoko 君の責任tomoko

＋

1. Tomokoは当該箇所に一切手を入れずに自分の希望の機能を提供されるようにした

2. Ko8の責任範囲には影響しないように自分の責任でコードを追加する感じ

主な変更パターン③このパターンの問題•こういうことを繰り返すと、謎のオプションが増え

たり、似た様なメソッドが増えたりカオス化するあれ？このメソッドあっちにもあったわ似たようなメソッドありすぎ、どれ使うの？どっちも使ってるから消せないやん

結局「あー、そこ樹海だから触らないで」ってなる・・・・　おめでとう。

主な変更パターン④Tomoko 君は勝手にこっそり変更する

ko8 君の責任

common クラス

tomoko 君の責任tomoko

＋

1. Tomokoは commonの修正箇所を探し当て、そこに変更を加える2. Tomoko は知らん顔でコミットする

主な変更パターン④このパターンの問題•言わずもがな、一番ダメなパターン•あとから ko8 が「この変更なんじゃこ

りゃ！？」ってなる•テストで見つかればいいが、予期せぬバグを

生む原因となる•あと Ko8 君のストレスが溜まる

PullRequestでのパターン

では、

プルリクエストを使うとどうなるのか

PullRequestでのパターンTomoko 君は ko8 君に確認をとり、変更しコミットする

ko8 君の責任

common クラス

tomoko 君の責任

ko8

tomoko

確認

＋

1. Tomokoはローカルブランチで commonに修正を加え、パッチをつくる2. Tomoko は Ko8 に pullRequest を送る3. Ko8 はそれを確認（レビュー、リファクタリング）する4. 変更を取り込む

パッチ

PullRequestでのパターン見た感じ、パターン②の「変更し、確認をとりコミットする」に似てるけど•Git の分散性、ブランチ機能を生かした効率

的なフローがシステムよって提供される•オープンにやりとりされるの点で異なる

PullRequestでのパターンそもそも、 Git の利点として•自分の元にリポジトリを持てる•気軽にブランチを切り気軽にマージできる

というのがあるけど、 Pull Request こそ、これを最大限生かした理想的な開発フローじゃないかー ( 棒）

PullRequestメリット•パッチは小さいにこしたことはない

ソースコードへの変更は、大きければ大きいほど影響範囲やバグの混入する確率も大きくなるので、パッチは小さければ小さい方が良い

小さな patch ごとにレビューが入るため、コストが小さく、議論が 1 点に集中できるため質も高い

小さな diff であればあるほど、小さなコストで確認ができる。それを繰り返すことが重要だ

PullRequestメリット•コードレビューの機会を設けれるいっぺんにたくさんのコードをレビューするのは非常に大変だし、コストが大きいけど、 pullrequest は小さい単位でできる

修正者が変更の影響範囲はわかっていたつもりで、それに対応したつもりだけど、想定できていなかった影響範囲について、有識者のチェックが入り、余計なバグを防げる

PullRequestメリット•レビューによってリファクタされるレビューされるということは、有識者が、それが

その機能を提供するための変更にとって良い変更なのか、がチェックされることになり、ベターからベストな修正にりファクタが可能

リファクタ自体もカオスになりきった大きなコードをあとからリファクタすることよりもコストが非常に小さく済む

PullRequestメリット•オープンだからそのやりとりが他の開発者もわかる

こういうやり取りをしてこの変更が加えられたのだ、ということが他の人に分かる形で残る

次に別の人が手を加えるときにどういう意図で書かれているのか両人の意図がすぐにわかる

まとめ•ちいさなパッチを常々レビューしよう

•そのために仕事でも Pull Request 使おう

•とりあえず、 gitHub でもいいからやってみよう

おまけgithub を用いた開発フローhttps://pepabo.github.io/docs/github/workflow.html

参考になるから一読してみてください！