最低限といいつつ、結構長くなってしまいましたが…。
職場によっては「プルリク知らないとかないよね？」って感じで圧をかけられる事もあるので、そうなる前に覚えてしまいましょう。
初日に「GitHub アカウント教えて！」なんて会社は大体そんな流れになります。
フォーク主体のプルリクしちゃってる場合、別の戦術が必要になりますが…。
プルリクエストとは
一言でいうと「承認制プッシュ」です。部下がプッシュした変更（プルリクエスト）を上司がチェックし、問題なければ main（master） にマージするという流れです。
- 新卒でプログラムに慣れない子のコードレビューをしたい
- クリティカルな部分なので、コードに問題がないか確認しながら進めたい
こういう場合に有効な手段です。
GitLab ではマージリクエストと言うらしいです。
下準備
GitHub(Web) と VSCode を使用します。また、Git が実行できる環境は整っているものとします。
それが終わっていない場合はこちらの記事などを参考にして、GitHub の使い方に慣れておいてください。
プルリクはその性格上、２人のやりとりで成り立っています。
今回は GitHub のアカウントを２つ用意し、その中でやりとりを演出します。
（先輩さんのアカウントはお借りしました）
なお、VS Code を使うものの、VS Code 拡張機能のプルリクは行いません。
GitLab、通常の Visual Studio、TurtoiseGit などを使っている人が（ほぼ）似たような手順で出来るよう、敢えてそのようにしていることをご了承ください。
[GitHub] 先輩さんがリポジトリを作成
先輩さんが GitHub で新規リポジトリを作成します。readme.md しかない空の状態です。
[GitHub] 先輩さん、新人君をリポジトリに招待
Settings > Manage access > Add people で新人君のアカウント名を入力し、招待。
（間違って他の人を招待しないように）
新人君は招待メールを承認する
新人君は先輩さんからの招待を承認しましょう。メールが届いているはずなので、View Invitation > Accept Invitation。
[GitHub] 先輩さん、マージ権限者を設定
デフォルトでは誰でもプルリクマージ可能なので、「新人君がプルリクした後自分でマージ」のような意味不明なマージもまかり通ってしまいます。
それを防護する方法です。
なお、プライベートリポジトリでこれを行う場合、有料アカウントが必要のようです。
パブリックリポジトリの場合は可能でした。
Settings > Branches > Branch Protection Rules > Add rule
Branch name pattern を main、その他３か所にチェックを入れておきます。
こちらのサイトが詳しかったです。
はじめてのプルリク（承認）
[vscode] 新人君、リポジトリをクローン
ようやく新人君の出番です。
メンバーに招待されたリポジトリを VS Code のワークスペースにクローンします。
F1（コマンドパレット）> git clone > 招待を受けた GitHub の URL
無事持ってくることができたら、ブランチを切り替えます。
画面左下の青い部分 main をクリック > ＋新しい分岐の作成 > staffB という名前でエンター
[vscode, GitHub]新人君、修正をプルリク
プルリクの準備は完了したので、README.md を編集します。
「(B) 説明を追加しました」と追記しました。
ソース管理を選択し、✔を押し、「コメントを追記しました」と記述してエンター。
プッシュすると以下のダイアログが出るので、OK。
ここまで作業したら、GitHub の自分のアカウントから、test リポジトリを参照してください。
Compare & Pull request というボタンが表示されていると思うので、押しましょう。
必要であれば説明文を書いて、Create Pull request。これでプルリク完了です。
Review Required、Merging is blocked とあるのは「あなたがマージすることはできません」というサインです。
（前述のマージ権限設定をしていない場合、ここにマージボタンが表示されてしまいます）
プライベートリポジトリの場合、有料アカウントでなければ Merge pull request に制限をかけられない事に注意してください。
[GitHub]先輩さん、プルリクを承認する
（設定でメール拒否していなければ）新人君からプルリク承認のメールが届いていると思います。
確認しましょう。
メールで来ていない場合は GitHub にアクセスし、直接確認することもできます。
Pull Requests > 「コメントを追記しました」を選択
オレンジで囲った部分をクリックして、編集内容を確かめます。
今回は問題ないものとし、Review Changes > Approve を選択 > Submit review。
コメントがなくても問題ありませんが、新人君のやる気を促してあげるのも先輩の気遣い。
１つ前の画面に戻ると、赤ボタンから緑ボタンになっています。承認されたので、マージ許可が降りた、というわけです。Merge pull Request > Confirm merge。
マージ完了したので、Delete branch でブランチも消しておきます。
画面上部の <> Code を押して main ブランチを確認すると、staffB の内容が反映されました。
２回目のプルリク（リテイク有）
新人君、いま一度プルリク
承認に気を良くした新人君、続けて README.md をこんな風に編集。
コミット「どうですか！？」 > プッシュ
ちなみにこの「どうですか！？」実際にあったコメントです…
GitHub を確認。１回目と違い、Compare & Pull request が出ていません。
おそらく staffB ブランチをそのまま使っているせい？
仕方がないので今回は ちょっと違うルートからプルリクを送ってみましょう。
ブランチを選んでプルリクするイメージです。
先輩さん、ダメ出し
先ほどと同様の手順で、ソース確認画面まで遷移しましょう。
苦笑しかありませんが、こういう場合は「やり直し」を要求します。
どう修正するか的確に指示するのは難しいですよね。
新人君のレベルに応じて、修正内容をまるまる書いたり、あるいは少し考えさせるようにしたり。
コメントひとつで新人君が上手く育つこともあります。
さて、どのようなコメントをするにしろ、Request changes を選択してください。
これがやり直しの合図です。
新人君、修正す
新人君にはこのようなメールが届きます。
GitHub を確認してもマージが完了されていません。
先輩の言葉を胸に受け止めつつ、修正しましょう。
今回の間違いは明らかなので、サクッと修正しコミット＆プッシュ。
先輩さん、再び確認す
新人君からメールが届いたので、確認します。
プルリクに追加されたリンクをクリックします。
問題なさそうなので、今回は Approve。
その後、Merge pull request > Delete branch。
これで修正対応完了です。
さいごに
なるべく図を多めにしているので長い記事になりましたが、オペレーション自体はそれほど手間でもありません。
是非とも上手に使って、スタッフのコードの質を上げていきましょう。
