> ## Documentation Index > Fetch the complete documentation index at: https://lib.findy.co.jp/llms.txt > Use this file to discover all available pages before exploring further. # プルリクエスト > プルリクエストの基本と運用。テンプレートの設定手順、コミットメッセージとタイトルの規約、粒度の判断基準と維持する実践を説明します。 ## 概要 プルリクエストとは、リポジトリへの変更を提案し、その変更についてレビューなどの共同作業を行うための仕組みです。変更はブランチを介して提案されます。適用する内容を含むheadブランチから、変更の適用先であるbaseブランチに向けてプルリクエストを作成し、承認された内容だけが取り込まれます。 ## コミットメッセージ コミットメッセージは、コミットに含まれる変更内容を要約する説明です。書き方をチームの規約として統一すると、履歴のどのコミットが何を変更したのかを一定の形式で追跡できます。 規約には[Conventional Commits](https://www.conventionalcommits.org/ja/v1.0.0/)の形式が広く使われます。`<型>: <要約>`の形式で、先頭に変更の種類を示すプレフィックスを付けます。 | 型 | 用途 | メッセージの例 | | ---------- | ------------------ | -------------------------- | | `feat` | 機能の追加 | `feat: プロフィール画面に通知設定を追加` | | `fix` | バグの修正 | `fix: 日付フィルタの境界値のずれを修正` | | `docs` | ドキュメントのみの変更 | `docs: セットアップ手順を追記` | | `refactor` | 挙動を変えないコードの整理 | `refactor: 日付整形処理を共通関数に抽出` | | `test` | テストの追加・修正 | `test: 境界値のテストケースを追加` | | `chore` | ビルド設定・依存関係の更新などの雑務 | `chore: 依存パッケージを更新` | Conventional Commitsと合わせて、[Semantic Versioning](https://semver.org/lang/ja/)を使うことがあります。`MAJOR.MINOR.PATCH`の形式で、変更の互換性に応じて上げるバージョンレベルを決めます。ライブラリやAPIなど、互換性を管理する必要がある開発で利用することがあります。この2つを組み合わせると、コミットメッセージから変更内容を理解しやすくなり、リリースのバージョン番号を機械的に決定できるようになります。 | バージョンレベル | 用途 | バージョンの例 | | -------- | ------------- | ----------------- | | `MAJOR` | 後方互換性のない変更 | `1.4.2` → `2.0.0` | | `MINOR` | 後方互換性のある機能の追加 | `1.4.2` → `1.5.0` | | `PATCH` | 後方互換性のあるバグ修正 | `1.4.2` → `1.4.3` | 組み合わせる場合は、`<レベル>-<型>: <要約>`のように型の前にバージョンレベルを付けます。破壊的変更を伴う機能追加は`major-feat`、互換性に影響しない小さな機能追加は`patch-feat`のように、型だけでは決まらないバージョンレベルを明示できます。 コミットメッセージは`<型>: <要約>`の1行だけでも成立します。変更の背景や理由を説明したい場合は、空行を挟んで本文やフッターを加えます。 ```text 要約のみ theme={null} fix: 日付フィルタの境界値のずれを修正 ``` ```text 本文付き theme={null} refactor: 日付整形処理を共通関数に抽出 画面ごとに重複していた整形ロジックが3箇所で食い違っていたため、 共通関数に集約して仕様を一本化する。 ``` ```text Semantic Versioning付き theme={null} major-feat: 通知一覧APIのレスポンスをページネーション形式に変更 1回のレスポンスで全件を返す形式では通知の増加に耐えられないため、 ページネーション付きの形式に変更する。 BREAKING CHANGE: レスポンスのトップレベルが配列からオブジェクトに変わるため、 クライアントはitems配列から通知を取得するよう修正が必要。 ``` ## タイトル プルリクエストのタイトルは、変更内容を1行で要約する説明です。タイトルは一覧・通知・マージ後の履歴に表示されるため、本文を開かなくても変更内容を判別できる書き方に統一します。 タイトルはコミットメッセージをベースに、同じくConventional CommitsとSemantic Versioningの形式で決めます。コミットが1つのプルリクエストではそのコミットメッセージをそのまま使い、複数のコミットを含むプルリクエストでは変更全体を代表する型と要約を選びます。 ## テンプレート プルリクエストの作成時に説明欄に自動挿入されるMarkdownのテンプレートを用意することができます。テンプレートがあると、概要・変更点・動作確認といった説明の構成がプルリクエストごとにばらつかず、レビュアーに渡すべき情報を事前にルール化できます。 リポジトリに`.github/PULL_REQUEST_TEMPLATE.md`を作成します。 レビュアーが必要とする情報を、見出しとコメントで区切って並べます。 ````markdown theme={null} ## 概要 ## 背景/目的 ## 変更内容 -
使用したプロンプト ### 使用したLLMモデル ### プロンプト ```markdown ```
## テスト計画 - [ ] ユニットテストを追加・更新した - [ ] 既存のテストとCIがすべて通ることを確認した ## 動作確認方法 - [ ] ローカル環境で対象の機能を操作し、期待どおり動作することを確認した - [ ] 影響範囲の周辺機能が壊れていないことを確認した ## 対応issue ## 備考 ```` テンプレートはデフォルトブランチに存在して初めて適用されます。マージ後に作成されるプルリクエストから、説明欄に雛形が自動で挿入されます。 テンプレートの内容は定期的に見直しましょう。誰も埋めていないセクションは削ります。レビューで質問することが多い項目などがあれば、セクションとして追加します。 ## Draft Draftとは、レビューの準備が整っていないことを明示するプルリクエストの下書き状態です。Draft状態の間はマージがブロックされるため、作業途中の変更が誤って取り込まれることはありません。 未完成の段階でDraftとしてプルリクエストを開いておくと、実装や設計の方向性について、実コードの差分を見ながら早い段階でフィードバックを得られます。文書や口頭のすり合わせと違い、動くコードを前提に議論できるため、レビュアーと認識を早い段階で合わせられます。 必要なフィードバックが揃い、認識が合ったら、そのまま作業を継続しても、Draftのプルリクエストをcloseして新たにプルリクエストを作り直しても構いません。作業が進むほど方向転換のコストは膨らむため、早い段階で手戻りしてサンクコストを最小限に抑える手段としてDraftは有効です。 作成時に「Create draft pull request」を選択し、レビューを依頼できる状態になったら「Ready for review」でDraft状態を解除します。 ## 粒度 プルリクエストの粒度とは、1つのプルリクエストが1つのことに注力できているかという、変更内容の一意性です。差分の行数やファイル数ではなく、変更内容が一意であるかどうかで測ります。 ### サイズと粒度の違い サイズ（変更行数・ファイル数）と粒度（変更内容の一意性）は別の尺度であり、分割の判断に使うのは粒度です。判断基準は、差分が大きいかどうかではなく、プルリクエストの変更内容が一意である（1つのことに注力できている）かどうかです。 | 変更の例 | サイズ | 適切かどうか | 理由 | | ---------------------- | --- | ------ | ---------------------------- | | 1万箇所で利用している関数名の一括リネーム | 大 | 適切 | 変更内容が一意なので1つのプルリクエストで問題ありません | | データ取得・加工・描画をまとめて実装 | 小〜中 | 不適切 | 異なる変更内容が混在しているため分割します | | 20行のバグ修正＋ついでの無関係なリファクタ | 小 | 不適切 | 2つの変更が混在しているため分割します | ### なぜ粒度が重要か 焦点の絞られた差分は、レビューする範囲も絞られます。作業量の合計が同じでも、10の変更を1つのプルリクエストでレビューするより、1の変更を10個のプルリクエストに分けてレビューする方が、作成者・レビュアー双方の負担が小さくなります。 変更内容が一意な差分はレビュアーの頭に収まるため、レビューが後回しにされず、数分で終わります。 変更内容が一意なプルリクエストをrevertすれば、その変更だけを巻き戻し、余計なものを巻き込みません。 生存期間が短いブランチは、conflictが発生しにくくなります。 変更内容が一意なプルリクエストは影響範囲も絞られるため、障害時の切り分けが速くなります。 複数の変更内容が混在したプルリクエストは負の循環を生みます。レビュアーの認知負荷を上げ、レビューは後回しになり、ブランチは長く生き残り、conflictが積み上がって、次のレビューはさらに重くなります。 プルリクエストの粒度は、AIエージェントに作業させるときのコンテキスト管理の観点でも重要です。複数の要件や異なる内容を同じコンテキストで作業させると、焦点が分散して精度が落ちます。変更内容が一意なプルリクエストの粒度で作業させることで、コンテキストが1つのことに集中でき、実装・レビューともに精度が上がります。 ### 粒度を適切にするコツ #### 先に作業を分解する コードを書く前に独立して作業できるタスクへ分解し、各タスクが1つのプルリクエストに対応するようにします。詳細は[タスク分解](/ja/development/task-breakdown)を参照してください。 #### 迷ったら小さく分割する 適切な粒度に迷ったら、小さい粒度の方を選択します。レビューのやり取りの中で粒度について議論すれば、認識をレビュアーと揃えられます。 大きく作ったプルリクエストを後から分割するよりも、小さく作って後から粒度を大きくするほうが簡単です。迷ったときは小さく出し、段階的に肉付けしていきます。 #### レビューを最優先にする 粒度を小さくすると、マージしないと次の作業に着手できない場面が増えます。ここでレビューが滞るとボトルネックになり、開発スピード全体が低下します。そのため、レビュー依頼が来たら自分の作業より優先して対応します。 作業を中断するコンテキストスイッチが気になるかもしれませんが、粒度が適切なプルリクエストのレビューは数分、時には1分以内で終わるため、中断のコストはわずかです。粒度を適切に保つことが、レビューを最優先にする習慣がチームに根付く土台となります。 #### CIを高速に保つ 粒度を小さくするとプルリクエストの数が増え、それに比例してCIの実行回数も増えます。CIが遅いままだと、マージまでの待ち時間が積み重なって開発効率が逆に落ちます。 実行時間は10分切りが目安で、5分を超えたら遅いと判断して改善します。具体的な高速化の手法はCI/CDの[CIを高速に保つ](/ja/development/ci-cd#ciを高速に保つ)を参照してください。 #### デプロイとリリースを分ける コードを本番環境へ反映するデプロイと、機能をユーザーへ公開するリリースを別の出来事として扱うと、機能全体の完成を待たずに未完成の作業をマージできるため、プルリクエストを小さく出し続けられます。 詳細は[リリース](/ja/development/release-strategy)を参照してください。