Pull requestは
どのGitHubレポジトリに
変更を加える上でも重要です
どのようにして効果的に使えるかを
見ていきましょう
♪ (音楽) ♪
Pull requestは別のコードベースで
変更を行うための手段です
あなたが中心的な貢献者である場合でも
離れて貢献している場合でも
使うことができます
中心的な貢献者ではない場合
このプロジェクトに参加して
自分で変更を加えて
オリジナルの作者に
その変更を提案として
pull requestを送ることができます
つまり不満を言うよりも
修正を加える方が簡単になるため
GitHubはオープンソースの
成長と発展を促進してきたのです
編集を行い 改善することで
皆の利益になります
これはクローズドプロジェクトや
社内プロジェクト 個人用レポジトリでも同じです
レポジトリにプッシュする権限があっても
ブランチで作業をして
コードをレビューしてもらうように
pull requestを送ります
つまりブランチを作成して
コミットをし始め
レビューしてもらう準備ができたら
そのpull requestにチーム内の人に
送り返せばいいのです
pull requestは会話であり
ブランチの現状を
一方的に教えるものではありません
むしろ会話や議論に似ていて
コードに加えられた修正は
時系列順に表示され
最終的に承認されるか
悪いケースだと
下向きの親指マークとともに「この変更は
あまり良くないのでは」と書かれるでしょう
いずれの場合においても
URLとpull requestは存続します
物事が拒否されたり
受け入れられなかったからと言って
議論をやめる必要はありません
承認されなかった理由や
今後どのような変更ができるかを
見つけ出して
以降のpull requestが
受け入れられるようにしましょう
これは後からチームに入った人のための
教育ツールとしても機能します
これらのpull requestは
どんな変更なら
ここで受け入れられるか
人が考えている例外や
要件やフォーマットは何かについての
会話なのであり
URLを保存しておいて
新しいメンバーの
教育ツールとして参照できます
つまり機能がどのように
生まれたかについての
メールを転送する必要がないのです
URLを教えるだけで
いつでも参照できます
私たちはまた人材だけでなく
技術的インプットにも関心があります
継続的インテグレーション
つまりCIシステムのうち
TravisやHudsonやJenkins
CirclecCIやTeam Cityなどは
どれもGitHub pull requestと
インテグレーションでき
ブランチのビルドステータス―
つまりpull rerquestの
基本ユニットを
会話に即して報告できます
つまり会話とコードの変更に即して
ビルドステータスがポップアップして
こう言うのです
「すべて合格でした」とか
「テストに通らなかったものもある」など
Mergeボタンのステータスも左右します
「Merge Pull Requestの
ボタンを押す前に―
全てのテストに通って
ブランチをクリーンにしてみてはどうですか？」
というような警告が出ることでしょう
さて人からのフィードバックをもらうための
CIステータスもインテグレートしているので