git-commit

Conventional Commits に準拠した Git コミット

Conventional Commits 1.0.0 の仕様に従って Git コミットを作成します。差分からタイプ、スコープ、要約を判断します。

メッセージ形式

<type>(<scope>): <summary>

<body>

<footer>

• スコープ、本文、フッターは省略可能です。スコープを付けない場合は、<type>: <summary> と記述します。
• 要約は命令形で記述します。「added」や「adds」ではなく、「add」のようにします。
• 1 行目は 72 文字以内にします。末尾にピリオドは付けません。
• 本文には、何を変更したか、そしてその理由を記述します。
• フッターはそれぞれ Token: value または Token #value の形式で記述します。例：Refs: #456 または Closes #123。Conventional Commits ではどちらの形式も使用できますが、Git がトレーラーとして認識するのは Token: value のみです。トークン内では、スペースの代わりに - を使用します。

タイプ

Conventional Commits で定義されているのは feat と fix のみです。その他のタイプは Angular の規約（@commitlint/config-conventional）に由来します。リポジトリ独自のリストがある場合は、そのリストに従ってください。

Type	Use it for
feat	新機能
fix	バグ修正
docs	ドキュメントのみ
style	ロジックを変更しないフォーマットのみ
refactor	機能追加やバグ修正ではないコード変更
perf	パフォーマンスの改善
test	新規または変更したテスト
build	ビルドシステムまたは依存関係
ci	CI の設定
chore	その他の保守作業
revert	以前のコミットの取り消し

破壊的変更

コロンの前に ! を付けるか、BREAKING CHANGE: フッターを追加します。トークンは大文字で記述します。BREAKING-CHANGE: も正しい形式です。

feat(api)!: remove the v1 endpoints

BREAKING CHANGE: Clients must use the v2 endpoints.

ワークフロー

1. リポジトリのルールを確認する

メッセージを書く前に、コミットのルールを確認します。

• commitlint の設定。例：commitlint.config.js または .commitlintrc.json。
• CONTRIBUTING.md。
• 直近のメッセージ：git log --oneline -10。

リポジトリのルールがこのスキルと異なる場合は、リポジトリのルールに従ってください。

2. 変更を確認する

git status --porcelain
git diff --staged
git diff

変更がない場合は、ユーザーに伝えてください。空のコミットは作成しないでください。

3. ファイルをステージする

各コミットには、1 つの論理的な変更を含めます。ステージしたファイルに複数の変更が含まれている場合は、まず別の変更に関するファイルをステージ解除します。その後、この変更に関するファイルをステージします。

git reset -q -- path/to/other-file1 path/to/other-file2
git add -- path/to/file1 path/to/file2
git add -- '*.test.*'
git add -- src/components/

• glob は引用符で囲みます。引用符がないと、シェルが glob を展開し、サブディレクトリ内のファイルを見つけられません。
• git add -p や git add -i は使用しないでください。これらのコマンドは人の入力を待ちます。
• マージの競合を解決した後は、git add --resolved を使用します。このコマンドは解決済みのファイルのみをステージします。ファイルに競合マーカーが残っている場合、コマンドは停止します。
• git diff --staged --name-only でステージ済みファイルの一覧を確認します。.env ファイル、credentials.json、秘密鍵などのシークレットはコミットしないでください。

4. メッセージを書く

各要素は差分から判断します。

• タイプ：変更の種類。
• スコープ：変更の影響を受けるモジュールまたは領域。
• 要約：変更内容を 1 行で記述したもの。

5. コミットする

段落ごとに別の -m オプションを指定します。Git は段落の間に空行を入れます。このコマンドは Bash、PowerShell、その他のシェルで動作します。

git commit -m "feat(auth): add token refresh"
git commit -m "fix(parser): accept empty input" -m "An empty file caused a crash." -m "Closes: #123"

長いメッセージの場合は、一時ファイルにメッセージを書き込みます。その後、git commit -F <file> を実行します。

6. コミットが正しいことを確認する

git log -1 --stat
git status --porcelain

安全に関するルール

• Git の設定を変更しないでください。
• ユーザーから指示がない限り、--no-verify を使用しないでください。フックは .git/hooks または Git の設定に存在する場合があります。
• フックに失敗した場合、Git はコミットを作成しません。問題を修正し、ファイルを再度ステージングして、同じ git commit コマンドをもう一度実行してください。前のコミットが変更されるため、--amend は使用しないでください。
• ユーザーから指示がない限り、コミット履歴を変更しないでください。git reset --hard、git rebase、または実験的な git history コマンドを使用しないでください。
• ユーザーから指示がない限り、プッシュしないでください。デフォルトブランチへの強制プッシュはしないでください。