コンテンツにスキップ

06.プルリクエスト規定

このドキュメントは、プルリクエスト（Pull Request, PR）の作成と運用に関するルールを定めます。PRは、変更をmainブランチやreleaseブランチに統合するための、唯一の公式な方法です。

1. PRの目的

  • 品質の担保: 変更内容をマージする前に、他の開発者によるレビューと、GitHub Actionsによる自動チェック（CI）を実施します。
  • 知識の共有: どのような変更が、なぜ行われたのかをチーム全体で共有し、属人化を防ぎます。
  • 議論の場: 変更内容に対するフィードバックや、より良い実装方法についての議論を行います。

2. PR作成のルール

2.1. タイトルと本文

  • タイトル: PRの目的が具体的で、一目で理解できるように記述します。
  • 本文 (Description):
    • 本文のどこかに、Closes #[Issue番号] または Fixes #[Issue番号] を必ず記述します。これにより、このPRがマージされた際に、関連するIssueが自動的にクローズされます。
    • 何を (What): どのような変更を行ったのかを簡潔に記述します。
    • なぜ (Why): なぜこの変更が必要だったのか、背景や目的を記述します。
    • UIの変更を伴う場合は、変更前後のスクリーンショットやGIF動画を貼り付けることを強く推奨します。

2.2. ドラフトプルリクエストの活用

  • まだ作業途中でレビューを依頼する段階ではないが、CIを走らせたり、他の人から途中経過のフィードバックが欲しかったりする場合には、ドラフトプルリクエスト (Draft Pull Request) を作成します。
  • 作業が完了したら、「Ready for review」ボタンを押して通常のPRに切り替えます。

3. レビューとマージのプロセス

3.1. マージ方法: Squash and merge

  • PRをマージする際は、原則として Squash and merge を使用します。
  • featureブランチ内の複数の作業コミット（「WIP」「fix typo」など）を1つの意味のあるコミットにまとめることで、mainブランチの履歴がPR単位で整理され、クリーンに保たれます。

3.2. Squash and merge のコミットメッセージ編集ルール

Squash and merge を行う際は、最終的にmainブランチに残すコミットメッセージを、以下のルールに従って丁寧に編集する必要があります。これにより、履歴の可読性と自動化（CHANGELOG生成など）との連携を両立させます。

3.2.1. 基本ルール

  • PRの「主要な目的」を代表する<type>を1つだけ選び、ヘッダーに設定します。
    • 1つのPR内にfeat, fix, refactorが混在している場合、優先順位が最も高いfeatを最終的なコミットの<type>とします。
    • <type>の優先順位: feat > fix > perf > refactor > その他
  • 主要な目的以外の副次的な作業内容は、コミットメッセージの本文に箇条書きでまとめます。

3.2.2. 具体的な編集例

PR内のコミット履歴 (作業過程):

  • feat: プロフィール表示機能を追加
  • fix: 既存の認証ロジックのバグを修正
  • docs: プロフィールAPIの仕様書を記述

Squash and merge 時に作成する最終コミット:

feat(profile): add user profile page and related logic

- Added functionality to display user profile information.
- Fixed a minor bug in the authentication logic.
- Wrote API specification for the new profile endpoint.

Closes #78

!!! success "このルールのメリット" - クリーンな履歴: mainブランチの履歴は、「機能追加」といった意味のある単位で整理されます。- 自動化との連携: CHANGELOG生成ツールは、この最終的なfeatコミットを正しく解析できます。- 文脈の保持: コミットの本文に作業内容が残るため、詳細な変更経緯も失われません。- リバートの容易性: 問題が発生した場合、この1つのコミットをリバートするだけで、機能全体を安全に取り消すことができます。

関連ドキュメント: