-
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ステータスもインテグレートしているので
-
総合的な人の手によるレビューに加えて
技術的なテストも
-
ブランチのコンテンツに対してのみならず
-
ブランチとその送り先の
予測マージもに対しても行うので
-
マージが行われた際に
-
どのようになるかわかります
-
そのマージが変更不可である
というわけではありません
-
予測マージを実際に行い
どうなるかを確認して
-
このマージを行った場合に
-
うまくいくかどうかを
知らせてくれます
-
もしCIから良いレポートが出て
他の人から
-
スレッドにいくつかthumb upや
shipをもらったら
-
Merge Pull Requestのボタンを
押す時です
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
GitHub