0:00:00.067,0:00:01.784
Pull requestは[br]どのGitHubレポジトリに
0:00:01.784,0:00:04.152
変更を加える上でも重要です
0:00:04.402,0:00:06.207
どのようにして効果的に使えるかを[br]見ていきましょう
0:00:06.975,0:00:08.689
♪ (音楽) ♪
0:00:11.512,0:00:12.829
Pull requestは別のコードベースで
0:00:12.829,0:00:15.550
変更を行うための手段です
0:00:15.742,0:00:17.814
あなたが中心的な貢献者である場合でも
0:00:17.814,0:00:19.764
離れて貢献している場合でも[br]使うことができます
0:00:20.014,0:00:22.431
中心的な貢献者ではない場合[br]このプロジェクトに参加して
0:00:22.431,0:00:24.212
自分で変更を加えて
0:00:24.212,0:00:26.088
オリジナルの作者に[br]その変更を提案として
0:00:26.088,0:00:27.967
pull requestを送ることができます
0:00:28.328,0:00:32.843
つまり不満を言うよりも[br]修正を加える方が簡単になるため
0:00:32.843,0:00:37.022
GitHubはオープンソースの[br]成長と発展を促進してきたのです
0:00:37.428,0:00:39.732
編集を行い 改善することで
0:00:39.732,0:00:41.280
皆の利益になります
0:00:41.280,0:00:46.515
これはクローズドプロジェクトや[br]社内プロジェクト 個人用レポジトリでも同じです
0:00:49.587,0:00:51.725
レポジトリにプッシュする権限があっても
0:00:51.725,0:00:54.270
ブランチで作業をして[br]コードをレビューしてもらうように
0:00:54.270,0:00:55.962
pull requestを送ります
0:00:55.962,0:00:57.709
つまりブランチを作成して
0:00:57.709,0:01:00.595
コミットをし始め[br]レビューしてもらう準備ができたら
0:01:00.595,0:01:03.861
そのpull requestにチーム内の人に[br]送り返せばいいのです
0:01:04.424,0:01:06.931
pull requestは会話であり
0:01:06.931,0:01:09.973
ブランチの現状を[br]一方的に教えるものではありません
0:01:09.973,0:01:12.650
むしろ会話や議論に似ていて
0:01:12.650,0:01:16.565
コードに加えられた修正は[br]時系列順に表示され
0:01:16.565,0:01:19.860
最終的に承認されるか[br]悪いケースだと
0:01:19.860,0:01:24.701
下向きの親指マークとともに「この変更は[br]あまり良くないのでは」と書かれるでしょう
0:01:24.701,0:01:29.106
いずれの場合においても[br]URLとpull requestは存続します
0:01:31.761,0:01:33.150
物事が拒否されたり
0:01:33.150,0:01:35.253
受け入れられなかったからと言って[br]議論をやめる必要はありません
0:01:35.392,0:01:37.514
承認されなかった理由や[br]今後どのような変更ができるかを
0:01:37.514,0:01:39.234
見つけ出して[br]以降のpull requestが
0:01:39.234,0:01:41.441
受け入れられるようにしましょう
0:01:41.613,0:01:43.753
これは後からチームに入った人のための
0:01:43.794,0:01:45.912
教育ツールとしても機能します
0:01:46.052,0:01:48.824
これらのpull requestは[br]どんな変更なら
0:01:48.824,0:01:51.150
ここで受け入れられるか[br]人が考えている例外や
0:01:51.150,0:01:53.517
要件やフォーマットは何かについての
0:01:53.517,0:01:55.254
会話なのであり
0:01:55.254,0:01:58.553
URLを保存しておいて[br]新しいメンバーの
0:01:58.553,0:02:00.134
教育ツールとして参照できます
0:02:00.797,0:02:03.427
つまり機能がどのように[br]生まれたかについての
0:02:03.427,0:02:05.305
メールを転送する必要がないのです
0:02:05.409,0:02:08.350
URLを教えるだけで[br]いつでも参照できます
0:02:11.517,0:02:13.715
私たちはまた人材だけでなく
0:02:13.715,0:02:14.906
技術的インプットにも関心があります
0:02:14.906,0:02:16.884
継続的インテグレーション[br]つまりCIシステムのうち
0:02:16.884,0:02:21.179
TravisやHudsonやJenkins[br]CirclecCIやTeam Cityなどは
0:02:21.179,0:02:23.645
どれもGitHub pull requestと[br]インテグレーションでき
0:02:23.645,0:02:26.323
ブランチのビルドステータス―
0:02:26.323,0:02:28.563
つまりpull rerquestの[br]基本ユニットを
0:02:28.563,0:02:30.824
会話に即して報告できます
0:02:31.208,0:02:34.184
つまり会話とコードの変更に即して
0:02:34.184,0:02:36.764
ビルドステータスがポップアップして[br]こう言うのです
0:02:36.764,0:02:39.997
「すべて合格でした」とか[br]「テストに通らなかったものもある」など
0:02:40.582,0:02:43.036
Mergeボタンのステータスも左右します
0:02:43.036,0:02:44.754
「Merge Pull Requestの[br]ボタンを押す前に―
0:02:44.754,0:02:47.015
全てのテストに通って
0:02:47.015,0:02:48.658
ブランチをクリーンにしてみてはどうですか？」
0:02:48.658,0:02:51.859
というような警告が出ることでしょう
0:02:52.049,0:02:56.870
さて人からのフィードバックをもらうための[br]CIステータスもインテグレートしているので
0:02:56.870,0:03:01.852
0:03:01.852,0:03:04.136
0:03:04.136,0:03:09.215
0:03:09.556,0:03:11.331
0:03:11.331,0:03:13.034
0:03:13.034,0:03:14.930
0:03:14.930,0:03:17.511
0:03:17.511,0:03:19.644
0:03:19.644,0:03:21.280
0:03:23.836,0:03:27.879
0:03:27.879,0:03:30.462
0:03:30.462,0:03:32.729
0:03:33.104,0:03:36.560
0:03:36.560,0:03:39.473
0:03:39.515,0:03:42.481
0:03:42.481,0:03:44.804
0:03:44.804,0:03:45.926
0:03:45.926,0:03:47.857
0:03:47.857,0:03:49.778
0:03:50.096,0:03:52.025
0:03:52.025,0:03:53.945
0:03:53.945,0:03:57.038
0:03:57.038,0:04:00.814
0:04:02.532,0:04:05.210
0:04:05.210,0:04:07.695
0:04:07.695,0:04:10.582
0:04:11.173,0:04:14.657
0:04:14.950,0:04:17.376
0:04:17.376,0:04:19.277
0:04:19.546,0:04:21.840