プルリクエストメッセージもちゃんと書こう【備忘録的共有】

◆ Live配信スケジュール ◆
サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。
⇒ 詳細スケジュールはこちらから
⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください

【5/21開催】Azure OpenAI ServiceによるRAG実装ガイドを公開しました
生成AIを活用したユースケースで最も一番熱いと言われているRAGの実装ガイドを公開しました。そのガイドの紹介をおこなうイベントです!!
https://tech-lab.connpass.com/event/315703/

今回は、コミットメッセージよりも大事とされているプルリクエストについて書いています。何を書いたらよいのか？というところから始まってテンプレ化まで行っています。コミットメッセージもプルリクエストもどっちも大事です。

どもども！今週は意外と忙しかったなとふと振り返っている龍ちゃんです。業務的な忙しさはあまりないのですが、面談と小さな業務がポコポコと流動的に生まれて脳がつかれています。結果的に忙しいほうが余計なことを考えなくて済むのでとても良いですね。

さて、前回の記事「Gitのコミットメッセージをしっかり書こうという話【備忘録的共有】」がTwitterで触れられているところを見てうれしい気持ちいっぱいで今週は始まりました。Twitterのコメントを見ていると「コミットメッセージよりもプルリクエストでやろう」という意見が多数見受けられたので、プルリクエストもちゃんと書こうということで記事をまとめていきたいと思います。n番煎じの記事ですのでツッコミをもらって知見をためていきたいと思います。

実際に二週間ほどコミットメッセージを運用してみましたが、意外とつらいですね。運用していて初めて知るつらさがあります。

プルリクエストに関しては、同僚のプルリクエストが素敵だったので真似をしていました。そのため、あまり注意されることはなかったです。少しだけ戦いの歴史があるので記していきたいと思います。今回のブログを読んでわかることです。

Gitのプルリクエストテンプレート：サンプル付き
Git上のプルリクエストテンプレート適応する方法
プルリクエストのガイドライン

以上三部作となっています。さくっと5分程度で読めて、3分ぐらいで適応できるので今すぐやりましょうね。ほな！本題に入っていきます。

1 Git：プルリクエストテンプレート
2 Git上のプルリクエストテンプレートを適応する方法
3 プルリクエストを書く時の注意書き
4 終わりに

Git：プルリクエストテンプレート

結論を先にぽっとおいておきます。こちらは同僚のプルリクエストテンプレートをパクってきています。

## チケットURL

## やったこと

## 作業の切り分け:次回の作業に引き継ぎ

## できるようになること
<!-- 特になし -->

## できなくなること
<!-- 特になし -->

## 動作確認
<!-- ローカルで確認済み -->
<!-- プレビュー環境で確認済み -->

## その他・問題点
<!-- レビューの際に考慮すべき事前情報 -->

こちらのテンプレートですが、いろんなサイトで触れられていて似たり寄ったりなところがあるということが素直な感想です。

Googleで「プルリクエスト　テンプレート」と検索して目を引いたものを置いておきますね。クラスメソッドと書いてあるとすごく信頼度が上がりますね。ほぼパクリになってしまっていますが、備忘録としてまとめているのでご容赦ください。

Git上のプルリクエストテンプレートを適応する方法

それでは適応方法について書いていきます。適応方法に関しては「GitHub」や「Azure Repo」などでそれぞれの方法があります。

テンプレートの名前は共通して「pull_request_template.md」というファイルを保存することが共通しています。先ほどのテンプレートをリポジトリのトップに保存しましょう。

注意しなくてはならないのは、メインのブランチに置いておかないと動作しないことです。ちなみに僕はこれで動かなくて悲しい気持ちになっていました。

プルリクエストを書く時の注意書き

それでは最後にプルリクエストを書くときに注意するべきことを書いておきます。「こんな観点が抜けとるぞ！」とか「これにも気をつけろ！」というお話は大歓迎ですので、お待ちしています。

とりあえず何よりも気を付けるべきなのはタイトルです。これはコミットメッセージと通じるものが大いにあります。タイトルは明確でわかりやすいことが求められます。このプルリクエストで何をしたのか、何が解決されたのか？ということがわかることが重要です。

次に気を付けることが「読み手がいること意識する」ということです。コミットメッセージでもそうでしたが、誰かが読みます。読まれたときに相手がそれを見ただけで、作業のすべてがわかることがベストです。これはプルリクエストだけでなくコミットメッセージ・コード・仕様書など提出するものすべてに当たると思います。

まぁつまりは以下のことですね。

終わりに

今回は、短めにまとめていきました。序盤でも書きましたがn番煎じの記事なので、記事としての価値は全くありません。ただ自分が経験したことはすべてブログにまとめていく所存なので、さくっとまとめておきました。やはり怒られた経験などは、強烈な記憶となって心にしみますね。ちなみにプルリクエストについては、今のところ怒られていないので大丈夫だと思っています….

これからもいろんな記事を出していきます。よろしくお願いします。

それではまた～