なになれ

IT系のことを記録していきます。

GitHubを雰囲気で使っている(pull request)

GitHubでチーム開発を実施するようになり、pull requestの時には色々気をつけることがあるなと思い、整理したいと思います。

要約

レビューイ時

  • pull requestの内容を分かりやすく
  • レビュアーからコードレビューを受ける
  • checksでの設定項目をクリアする
  • masterブランチの最新をマージする
  • masterブランチへマージする

レビュアー時

  • 気になったことにコメントする
  • 変更を承認する

説明(レビューイ時)

pull requestの内容を分かりやすく

他者が理解できるような内容を記述することが求められます。具体的には以下のようなことを実施しています。

  • プロジェクト管理ツールなどの関連URLを載せる
    • 開発の背景などが書かれているためです
  • やったことを書く
    • コード変更の差分だけでは意図が伝わりづらいためです
  • 特に確認してほしいことを書く
    • 開発に際して不安に思っていることがある場合には、それを明確に伝えることでフィードバックを得やすくなります

レビュアーからコードレビューを受ける

コードレビューで指摘を受けた場合には、改めてローカルのブランチで開発を行います。
その際にpull requestのタイトルに[WIP]をつけておくと良いと思います。

WIPというGitHub Appsが導入されている場合にはmasterへのマージを抑制することが可能です。
GitHub Apps - WIP · GitHub

checksでの設定項目をクリアする

前述のWIPやCircle CIといったAppが連携されている場合にchecksの項目にステータスが表示されます。
各Appが成功する条件を満たして、変更内容をマージ可能にする必要があります。

masterブランチの最新をマージする

pull requestの元になっているブランチに対して、masterブランチの最新をマージする必要があります。

masterブランチへマージする

これまでの内容をクリアすることでようやくmasterブランチにマージすることができます。
GitHub Flowのようにmasterブランチとtopicブランチしか存在しないブランチ戦略を採用している場合にはsquash and mergeで無駄なコミットログをまとめてマージするのがオススメです。

説明(レビュアー時)

気になったことにコメントする

Files changed画面でソースコードにコメントを残す
Reviewing proposed changes in a pull request - GitHub Help

変更を承認する

必須レビュー機能が設定されている場合、レビューの結果がApproveされていないとマージできません。
Approveを選択して変更を承認します。

まとめ

PR時にチェックが強制されることでチーム開発でも秩序が守られるのはありがたいことです。