コミット — 概要、フォーマットルール、Git の操作

Git のコミットとは

Git のコミットは、特定の時点でのプロジェクトファイルの状態を保存するオブジェクトです。各コミットには、追跡対象の全ファイルのスナップショット、親コミットへの参照、メタデータが含まれます。他のバージョン管理システムとは異なり、Git はコンテンツアドレス可能ストレージを使用します — 各オブジェクトはその内容の SHA-1 ハッシュで識別されます。

開発者が変更をコミットすると、Git はコミットオブジェクトを作成します。これには、ツリーオブジェクト（ファイル構造）、親コミットハッシュ、作成者、コミッター、日付、メッセージが保存されます。このオブジェクトは不変です — 一度作成されたコミットは、ハッシュを変更せずに修正することはできません。この不変性がプロジェクト履歴の整合性を保証します。

# 変更をステージしてコミット
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# コミット詳細を表示
git log --oneline -3
git show HEAD

# すべての変更をステージして1ステップでコミット
git commit -a -m "Update dependencies to latest versions"

コミットは有向非巡回グラフ（DAG）を形成し、新しいコミットはそれぞれ前のコミットを参照します。これにより、履歴の移動、変更の取り消し、コードベースの進化の分析が可能になります。Git DAG の構造を理解することは、高度なコミット操作の基礎です。

変更を正しくコミットする方法

Git でのコミットプロセスは 2 つの段階で構成されます。ステージングエリア（インデックス）に変更を追加し、コミットを作成します。ステージングエリアにより、開発者はワーキングディレクトリで多くのファイルが変更されていても、コミットに含める特定の変更を選択できます。

原子性のルールは、良いコミットの主要な原則です。各コミットは1 つの論理的な変更を含むべきです。開発者がバグ修正とコードリファクタリングを行う場合 — これらは 2 つの別々のコミットにすべきです。アトミックなコミットは、コードレビュー、変更のロールバック、履歴分析を簡素化します。

コミットする前に、コード内にデバッグ出力、コメントアウトされたブロック、偶発的な変更が残っていないか確認する価値があります。これには git diff --cached コマンドを使用し、コミットに実際に何が含まれるかを表示します。git status による追加確認で、ステージングエリアのファイル一覧が表示されます。

• 変更を確認 — git diff --cached でコミットに含まれる内容を確認
• 品質を確認 — コミット前にコードがリンターとテストを通過する必要がある
• メッセージを書く — 変更目的の明確な説明
• ステージングファイルを確認 — git status でファイル一覧を確認

コミットメッセージの書き方ルール

コミットメッセージは、将来の開発者向けの変更のドキュメントです。良いメッセージは、「何が変更されたか」「なぜ変更されたか」の質問に答えます。Conventional Commits 規約（Angular チーム、2016）は多くのプロジェクトで標準となり、フォーマットを定義しています：型(スコープ): 説明。

良いコミットメッセージは、ヘッダー（50 文字以内）と本文（オプション、1 行 72 文字以内）で構成されます。ヘッダーは命令形で書きます：“Add” であり “Added” や “Adds” ではありません。Capitalization やヘッダー末尾のピリオドは使用しません — これは Git の国際的な慣習です。

悪いメッセージ：“fix things” や “update” — 情報を伝えません。1 ヶ月後、開発者は何が、なぜ変更されたかを理解できません。良いメッセージ：“fix(payment): handle timeout in stripe callback” — 何がどこで修正されたかがすぐに明確です。

コミット時のよくある間違い

開発者、特に初心者は、コミット時によくある間違いを犯しがちです。最も一般的なのは大きすぎるコミットで、数十の変更が混在しています。そのようなコミットは部分的に元に戻せず、コードレビューが苦痛になります。

2 番目に多い間違いは、不適切なコミットメッセージです。“fix”、“update”、“changes”、“wip” のようなメッセージは、将来の開発者にコンテキストを提供しません。6 ヶ月後には、誰も何が修正されたかを覚えていません。ルールは簡単です：1 年後に履歴を見て特定の変更を探している自分を想像してください。

3 番目の間違いは、コンパイルされていない、または動作しないコードをコミットすることです。コミット後、コードは少なくともコンパイルできる必要があります。ビルドを壊さないことは、共有ブランチへのコミットの基本要件です。そのため、コミット前にビルドとテストを実行します。

4 番目の間違いは、機密データをコミットすることです。API キー、パスワード、トークンは Git 履歴に入るべきではありません。機密情報が既にコミットされている場合、新しいコミットで削除するだけでなく、git filter-branch や BFG Repo-Cleaner を使用して履歴全体から削除する必要があります。

コミット操作の高度なテクニック

Git はコミット履歴を管理するためのツールを提供します。最も便利なものの 1 つは git commit --amend で、最後のコミットに新しい変更を追加したり、メッセージを修正したりできます。開発者がファイルを含め忘れたり、メッセージをタイプミスした場合に便利です。

# 最後のコミットメッセージを修正
git commit --amend -m "fix(auth): correct token validation logic"

# 最後のコミットに忘れたファイルを追加
git add missed-file.txt
git commit --amend --no-edit

# 最後の3コミットをインタラクティブリベース
git rebase -i HEAD~3

インタラクティブリベースは、履歴を書き換える強力なツールです。コミットの結合（squash）、メッセージの変更（reword）、並べ替え（reorder）、コミットの削除（drop）が可能です。ただし、リベースは履歴を変更するため、まだリモートリポジトリにプッシュされていないローカルコミットにのみ使用します。

コミットを取り消すには 2 つの方法があります。git revert は、前のコミットの変更を打ち消す新しいコミットを作成します — 履歴を保持する安全な方法です。git reset はコミットを履歴から削除します — コミットが既にプッシュされている場合は危険です。チーム開発では、公開されたコミットを取り消すには git revert のみを使用します。