この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
GitHub上でPull-RequestのReview完了後、大体期待されるものとしては以下の通りです。
- merge先ブランチのテストがコケない
- 関連するIssuesがクローズされている
- 不要になったブランチは削除されている
うまくいっていなかったり、残っているブランチを棚卸しをする際に「これ何だっけ」と確認の時間を割いてしまうのも勿体ないものです。私自身割とやらかしがちな所を含めて、スマートなレビュー後作業のポイントをおさらいしてみました。
Merge前後でテストを通す
Pull-Request中は、Merge先のブランチを取り込みつつテストを通しておきます。また、Reviewer達からApproveされた後は素早くMergeしておきましょう。Merge先のブランチが他のPull-Requestを受けて先に取り込んでいた場合、作業中のブランチに追加修正が必要になる可能性もあるため要注意です。
対処したIssuesを残さずまとめてクローズする
Issuesを紐つけて完了したい場合、Pull-Requestの最初のコメント欄に以下の通りにIssuesの番号を記載します。
fix #1, fix #2クローズするためのキーワードについては公式ドキュメントに記載されています。
Closing issues using keywords - GitHub Help
当該Pull-Requestが何の修正を担ったのか、後々確認しやすくなります。ガンガン使っていきましょう。
不要になったブランチを忘れずに削除する
Pull-RequestでMerge完了後はDelete branchを押して削除しておきましょう。「後で修正が必要になった時困る」という理由で残したくなるかもしれませんが復旧可能です。公式ドキュメントに手順が図解にて記載されています。
プルリクエスト中のブランチの削除と復元 - GitHub ヘルプ
あとがき
予定外の修正を抑えるためにも、時間を掛けすぎずにできるだけ素早くこなすことがポイントです。
紐つけたいIssuesについては一つ一つ確認する必要があります。Pull-RequestをDraftで作成し、修正するIssuesの番号をコメントに記載してから作業に入ることで漏れはある程度抑えられるはずです。
GitHubをより便利に使いこなしたい場合に、「それはやっていなかった」というポイントがあれば参考になると幸いです。
3
