[GitHub]最低限、これだけは知っておきたいプルリクエスト

最低限といいつつ、結構長くなってしまいましたが…。
職場によっては「プルリク知らないとかないよね?」って感じで圧をかけられる事もあるので、そうなる前に覚えてしまいましょう。

初日に「GitHub アカウント教えて!」なんて会社は大体そんな流れになります。
フォーク主体のプルリクしちゃってる場合、別の戦術が必要になりますが…。

プルリクエストとは

一言でいうと「承認制プッシュ」です。部下がプッシュした変更(プルリクエスト)を上司がチェックし、問題なければ main(master) にマージするという流れです。

  • 新卒でプログラムに慣れない子のコードレビューをしたい
  • クリティカルな部分なので、コードに問題がないか確認しながら進めたい

こういう場合に有効な手段です。

GitLab ではマージリクエストと言うらしいです。

下準備

GitHub(Web) と VSCode を使用します。また、Git が実行できる環境は整っているものとします。
それが終わっていない場合はこちらの記事などを参考にして、GitHub の使い方に慣れておいてください。

プルリクはその性格上、2人のやりとりで成り立っています。

左が先輩さん、右が新人君

今回は GitHub のアカウントを2つ用意し、その中でやりとりを演出します。
(先輩さんのアカウントはお借りしました)

なお、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、その他3か所にチェックを入れておきます。

こちらのサイトが詳しかったです。

はじめてのプルリク(承認)

[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
コメントがなくても問題ありませんが、新人君のやる気を促してあげるのも先輩の気遣い。

1つ前の画面に戻ると、赤ボタンから緑ボタンになっています。承認されたので、マージ許可が降りた、というわけです。
Merge pull Request > Confirm merge

マージ完了したので、Delete branch でブランチも消しておきます。

画面上部の <> Code を押して main ブランチを確認すると、staffB の内容が反映されました。

2回目のプルリク(リテイク有)

新人君、いま一度プルリク

承認に気を良くした新人君、続けて README.md をこんな風に編集。
コミット「どうですか!?」 > プッシュ

ちなみにこの「どうですか!?」実際にあったコメントです…

GitHub を確認。1回目と違い、Compare & Pull request が出ていません。

おそらく staffB ブランチをそのまま使っているせい?

仕方がないので今回は ちょっと違うルートからプルリクを送ってみましょう。
ブランチを選んでプルリクするイメージです。

先輩さん、ダメ出し

先ほどと同様の手順で、ソース確認画面まで遷移しましょう。

苦笑しかありませんが、こういう場合は「やり直し」を要求します。

どう修正するか的確に指示するのは難しいですよね。
新人君のレベルに応じて、修正内容をまるまる書いたり、あるいは少し考えさせるようにしたり。
コメントひとつで新人君が上手く育つこともあります。

さて、どのようなコメントをするにしろ、Request changes を選択してください。
これがやり直しの合図です。

新人君、修正す

新人君にはこのようなメールが届きます。

GitHub を確認してもマージが完了されていません。

先輩の言葉を胸に受け止めつつ、修正しましょう。

今回の間違いは明らかなので、サクッと修正しコミット&プッシュ。

先輩さん、再び確認す

新人君からメールが届いたので、確認します。
プルリクに追加されたリンクをクリックします。

問題なさそうなので、今回は Approve

その後、Merge pull request > Delete branch
これで修正対応完了です。

さいごに

なるべく図を多めにしているので長い記事になりましたが、オペレーション自体はそれほど手間でもありません。
是非とも上手に使って、スタッフのコードの質を上げていきましょう。

返信を残す

メールアドレスが公開されることはありません。

CAPTCHA