はじめに
RYDE株式会社CTOの芝原です。
前回の記事では、RYDEにおけるブランチ戦略とCI/CDパイプラインについてご紹介しました。今回はその続きとして、RYDEのエンジニアチームがどのようにプルリクエスト（PR）やコミットのルールを運用しているかをご紹介したいと思います。
各社それぞれ異なる開発ルールがあると思いますが、最も大切なのはチームが運用しやすく、効率的に開発を進められることです。この記事が、皆さんのチーム開発の一助となれば幸いです。
この記事を書いているまさに今日、新しいエンジニアがRYDEにジョインしてくれました。社内のオンボーディング的な内容として記載するついでにブログも書いてしまおうという魂胆です。
ブランチ
まずはブランチの命名規則と使い方についてです。RYDEでは、リリース管理のブランチを除き、大きく以下の2つに分けて考えています。
- ベースブランチ
- 作業ブランチ
ベースブランチ
大きめのプロジェクト（例えば、新しい決済手段としてPayPayを追加するなど）で、ある程度まとまった単位でリリースしたい場合、適切なサイズのPRのマージ先としてベースブランチを作成します。
これは以下のような命名規則になっています。
base/{Issue番号}-{作業内容}
例えば、Issue#999がPayPay決済の導入であれば base/999-paypay となります。
※ GitHub上では base/* というブランチ名のパターンに、ブランチプロテクションを設定して、force-pushなどができないように制限しています。
作業ブランチ
前回の記事でご紹介したブランチ戦略の中の「① 作業ブランチ」にあたるものです。
GitHubユーザー名をプレフィックスにつけることは共通で、対応するIssueの有無などによって以下の4つのルールで命名しています。
①大きいプロジェクトの子タスク（上のベースブランチが必要なPRもこれ）
{ユーザー名}/{Issue番号}-{ベースブランチの作業内容}-{作業内容}
例: unosk/999-paypay-refund-screen
②独立したIssueのあるタスク（1PRで完結する通常の作業ブランチ）
{ユーザー名}/{Issue番号}-{作業内容}
例: unosk/440-update-graphql
③対応するIssueのない軽微なもの
{ユーザー名}/{作業内容}
例: unosk/rubocop-auto-correct
④参照するIssueが別リポジトリの場合
{ユーザー名}/{リポジトリ名}-{Issue番号}-{作業内容}
例: unosk/pass-app-440-update-graphql
コミット
コミットは後で履歴を見返した際のヒントとなることを意識しています。
将来の自分やチームメンバーを助けるために、変更意図が伝わりやすい履歴を積み上げることを方針としています。
gitmoji を使って絵文字でコミットの種類を示す
コミットログを一目見ただけでその変更の意図が伝わりやすくなります。
✨ ユーザー登録機能を追加
🐛 ログイン時のエラーを修正
1コミットは1つの目的となるようにする
1行のコメントでやったことが説明できる量を目安に、複数の内容が詰め込まれないようにします。
なぜそのコードが追加/修正されたのか、経緯を追えるようにしておく
何をしたかだけでなく、なぜそうしたのかという意図が伝わる内容にします。
PR前にコミットを整理する
試行錯誤の履歴は後で見たときにノイズとなりますし、tmp や WIP のような後から意図がわからなくなるコミットは残さず、PRを作成する前にはコミットを整理します。
プルリクエスト
最後にプルリクエストについてです。
PRタイトルの先頭に絵文字でコミットの種類を示す
コミットと同様に、PRの意図を素早く把握できるようにします。
PRテンプレートのフォーマットで記載する
定められたフォーマットに従うことで、必要な情報が漏れなく記載され、スムーズがレビューが行えるようにします。
※ .github/PULL_REQUEST_TEMPLATE.mdで管理しています。
<!-- I want to review in Japanese. -->
## ✨ 概要
（変更の目的 もしくは 関連する Issue 番号）
## 🛠 変更内容
## 👻 影響範囲
## 👀 重点的にレビューしてほしい箇所
## 💻 画面キャプチャ
| 画面 A | 画面 B |
| ------------------ | ------------------ |
| （画面キャプチャ） | （画面キャプチャ） |
## ✔️ 動作確認した内容
## ☕ 補足
<!-- I want to review in Japanese. -->
1回1回のPRの精度を高める
タイポなどの凡ミスがないか、動作確認ができているかなどはレビューしてもらう前に確認し、レビューでの手戻りやレビュアーの負担を最小限に抑えます。
一つのPRが一つの目的となるようにする
一つのPRで解決する課題を明確にします。
多少面倒でも無関係な内容は別のPRで対応するようにします。
PRが大きくなりすぎないようにする
変更ファイルが12個くらいまでを目安としています。
ただし、分割されすぎてPRの目的が分かりにくくなるのは避けるようバランスを取っています。
最後に
RYDEにおけるプルリクエストとコミットのお作法についてご紹介しました。これらのルールは、チームメンバーが共通認識を持ち、スムーズかつ高品質な開発を進めるためのガイドラインとして機能しています。
エンジニア採用募集中！
RYDEでは、このような開発プロセスを大切にし、日々より良いものへと改善を続けています。もし、RYDEのエンジニアリング文化や開発に興味を持たれた方がいらっしゃいましたら、ぜひ採用ページもご覧ください。
RYDE PASSが取り組む移動交通の領域には、前例のない分野を自分たちで切り開く楽しさと、実生活で使える身近なサービスを創造していく喜びがあります。
共にサービスを成長させていく仲間を募集しています！
Discussion