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時にチェックが強制されることでチーム開発でも秩序が守られるのはありがたいことです。