commit-creator

コミットの作成

アクションを判断する

• メッセージのみの依頼ではテキストを作成します。実装のみの依頼では、作業ツリーの変更をローカルに残し、ステージング状態を維持します。
• コミット、履歴の書き換え、プッシュは、ユーザーの許可範囲に合致する場合に限って行います。コミットの依頼には、コミットの作成と必要なステージングが含まれますが、履歴の書き換えやプッシュは含まれません。PR の作成には、その作業に必要なコミットとプッシュが含まれます。完了したコミットや公開の依頼は、継続的な指示がない限り、その後の修正には適用されません。

変更を確認する

会話の記憶だけに頼らず、リポジトリの状態に基づいてメッセージを作成します。

git status --short --branch
git diff --cached
git diff

依頼されたコミットに含まれる、具体的な動作、ファイル、パッケージ、イシュー参照、バージョン変更を特定します。実質的な変更がない場合は、メッセージをでっち上げずに中止します。

ブランチとスコープを選択する

現在のブランチと、確認できる場合はリモートのデフォルトブランチを確認します。

git fetch origin --prune
git branch --show-current
git ls-remote --symref origin HEAD

• コミットする前に、現在のブランチが上流ブランチまたは最新のリモートデフォルトブランチより遅れているか、分岐している場合は報告します。該当するユーザーの許可範囲に含まれる場合に限り、マージ、リベース、または履歴の書き換えを行います。
• 現在のブランチがデフォルトブランチで、ユーザーがそのブランチへのコミットを明示的に依頼していない場合は、ブランチを作成するか、デフォルトブランチにコミットするかを尋ねます。ユーザーが対象ブランチを指定した場合、または現在のブランチへのコミットを指示した場合は、再確認せずに進めます。
• タスクが明確なブランチを作成する場合は、プロジェクトの命名規則に従い、元の大文字・小文字を維持したトラッカー ID を含めます。例：feat/gh-42-session-cache または fix/APP-123-token-refresh。ID だけでは特定できない場合は、リポジトリまたはプロジェクト名も含めます。

ステージング状態を維持する

• すでに確定しているコミットのスコープがある場合は、再確認しません。タスク対象のファイルが互いに独立している場合は、パスを限定してコミットし、未追跡のタスク対象ファイルのみを追加して、無関係なステージング状態を維持します。タスク対象の変更と無関係な変更が同じファイル内で重なり、意図する内容が不明確な場合は、コミットする前に確認します。
• ステージ済みの変更のみがあり、より狭いスコープが指定されていない場合は、ステージ済みの変更をコミットします。
• ステージされていない変更のみがあり、より狭いスコープが指定されていない場合は、現在の変更をすべてステージします。
• ステージ済みとステージされていない変更の両方があり、スコープが確定していない場合は、ステージ済みの変更のみをコミットするか、すべてをステージするかを確認します。
• 明示的に依頼されていない限り、ユーザーがステージしたファイルのステージングを解除したり、再度ステージしたりしてはいけません。

変更をまとめる

テストやドキュメントも含め、論理的にまとまった機能または独立した変更ごとにコミットを分けます。独立した依存関係の更新や無関係な作業も分けます。PR には複数のコミットを含めることができます。

1. 特に指定がなければ、修正は新しいコミットを作成します。マージ済みの作業に対する修正は、必ず新しいコミットにします。
2. コミットを更新する場合は、履歴と差分を確認して該当するコミットを特定します。対象が不明確な場合は確認します。独立したコミットと無関係なステージング状態を維持します。

メッセージを書く

メッセージ全体を英語で記述します。

<type>(<scope>): summary

- {emoji} concrete change
- {emoji} concrete change

• 要約は50文字以内で、命令形にし、末尾にピリオドを付けないでください。
• スコープには正確なパッケージまたはモジュールを指定します。真に複数のパッケージにまたがる変更の場合にのみ、all を使用してください。
• ユーザーが件名のみのメッセージを明示的に求めている場合を除き、本文には具体的な箇条書きを少なくとも1つ含めてください。
• 各箇条書きには論理的な変更を1つだけ記載し、箇条書きの間に空行を入れないでください。
• 実際に破壊的変更がある場合にのみ、! と BREAKING CHANGE: フッターを追加してください。
• 依頼、ブランチ名、またはリポジトリのコンテキストからタスクを特定します。現在のコミットに関するタスク要件と差分の分析が現在のセッションにある場合は、それを再利用してください。不足しているコンテキストは、正しい課題管理システムから読み取ってください。完了を示す参照を選ぶ前に、タスクの根拠が不足している場合や、完了したか不明な場合は確認してください。
• コミットによって検証済みの GitHub issue が解決される場合は、本文にクローズ参照を含めてください。同じリポジトリの場合は Fixes #42、別のリポジトリの場合は Fixes owner/repo#42 とします。既知のタスクについて、ユーザーに再確認を求めずに追加してください。
• 部分的な解決の場合は、Refs #42 のような通常の参照を使用してください。別の課題管理システムのタスクの場合は、検証済みのキーと URL を含めてください。

次の種類を使用してください：feat ✨、fix 🐛、docs 📚、style 💄、refactor ♻️、perf ⚡、test ✅、build 🔧、ci 👷、chore 🔨、revert ⏪。

依存関係の更新

変更された依存関係をすべて、変更前と変更後のバージョンを含めて個別に列挙してください。

- 📦 package-name: old-version -> new-version

曖昧な依存関係更新の箇条書きで、この一覧を置き換えないでください。

コミットを作成する

• コミットのみを依頼された場合は、コミットのためだけに余分なプロジェクトチェックを実行しないでください。ユーザーから依頼された場合、同じタスクでファイルが変更され、リポジトリの指示で検証が必須の場合、または失敗したフックの診断が必要な場合は実行してください。
• 要約と本文全体にそれぞれ1つずつ -m を使用するか、複数行の引用符の扱いが難しい場合は git commit -F- を使用してください。
• 箇条書きごとに -m を指定しないでください。Git によってそれぞれが別の段落になります。
• git commit に実行タイムアウトを設定しないでください。Git とすべてのフックが自然に終了するまで待ってください。Git フックは数分間無出力で実行されることがあり、タイムアウトを設定すると、必須のチェックが完了する前に終了するおそれがあります。
• 正確なエラーを報告し、修正するか、ユーザーに任せるか、--no-verify を使うかを提案してください。
• ユーザーから明示的な承認を得ずに、フックを回避してはいけません。
• 例が役立つ場合は、references/examples.md を参照してください。