コミットとは

コミットとは、バージョン管理システムの上で、ファイルの変更内容を1つの区切りとして履歴に記録する操作のことです。読み方はそのまま「こみっと」、英語では commit と書きます。英単語としては「確定する」「約束して引き受ける」という意味があり、開発の場面では「ここまでの変更を確定して、履歴に残す」という意味で使われます。

簡単に言うと、コミットはゲームのセーブポイントのようなものです。作業をひと区切りしたところでセーブしておけば、あとから「あのときの状態」に戻れますし、「いつ・誰が・どこを・なぜ変えたのか」を後から読み返せます。1人で開発しているときも、複数人で開発しているときも、この履歴があるかないかで、問題が起きたときの復旧のしやすさがまったく変わります。

コミットという言葉は、Gitをはじめとするバージョン管理システムの用語として使われるほか、データベースの世界でも「一連の処理を確定させる」という意味で使われます。どちらも「途中まで進めた作業を、正式なものとして確定させる」という点は共通しています。この記事では、開発現場でいちばんよく使われるGitのコミットを中心に説明します。

「コミットする」の意味：ビジネスと開発での違い

会議や目標管理で「目標にコミットする」と言うときは、英単語の「約束して引き受ける」の意味で、結果に責任を持って取り組むという宣言を表します。これに対して、開発で「コミットする」と言うときは、変更を確定して履歴に1件記録する操作を指します。同じカタカナでも、ビジネスのコミットは約束、Gitのコミットは記録の操作です。検索で「コミット 意味」と調べて出てくる説明が食い違って見えるのは、この2つが混ざっているためです。

1回のコミットには、変更後のファイルの状態に加えて、次のような情報がまとめて記録されます。

• 変更の内容：どのファイルの、どの行が、どう変わったか
• コミットメッセージ：その変更が何をしたものかを説明する短い文章
• 作成者と日時：誰がいつ記録したか
• コミットハッシュ：3f2a1c8 のような英数字の識別子。1つ1つのコミットを指し示す名前になります
• 1つ前のコミットへのつながり：履歴が数珠つなぎになるので、変更をさかのぼって追えます

Gitでは、コミットの前に「今回の記録に含める変更」を選ぶ段階があります。この置き場所はステージング（インデックス）と呼ばれ、git add で変更をそこに載せてから git commit で確定する、という2段構えになっています。この仕組みがあるおかげで、同時に複数のファイルをいじってしまったときでも、関係のある変更だけを選んで1つのコミットにまとめられます。コマンドの正式な説明は公式ドキュメントのgit-commit（git-scm.com）にまとまっています。

git commit の具体例（3行で1回の記録）

ターミナルで実際に打つコマンドは次の3つです。git status で変わったファイルを確かめ、git add で記録に含めるファイルを選び、git commit -m でメッセージを付けて確定します。

git status
git add src/login.ts
git commit -m "ログイン失敗時にエラーメッセージを表示する"

成功すると [main 3f2a1c8] ログイン失敗時に… のように、ブランチ名・コミットハッシュ・メッセージが1行表示されます。記録した履歴は git log --oneline で一覧できます。直前のコミットのメッセージだけを直したいときは、共有（プッシュ）する前なら git commit --amend で作り直せます。

記録したコミットは、リポジトリ（変更履歴を保管する箱）の中に積み上がっていきます。過去のコミットは基本的に消えないので、「昨日は動いていたのに今日は動かない」というときに、どの記録から様子が変わったのかを1つずつ確認していけます。

コミットとよく一緒に出てくるのが「プッシュ（push）」と「マージ（merge）」です。初心者がいちばん混乱しやすいところなので、何をする操作なのかを並べて整理します。

ポイントは、コミットしただけでは、その変更は自分のパソコンの外には出ていないということです。他の人に見せたり、共有サーバーに残したりするには、コミットのあとにプッシュが必要になります。逆に言えば、コミットは失敗しても他の人に影響しないので、気軽に何度でも行ってかまいません。

マージの前に変更内容を見てもらう仕組みがプルリクエストです。コミットの単位が整っていると、このレビューがぐっと読みやすくなります。ブランチやマージまで含めた全体像は、Git/GitHub入門：AIコーディング時代になぜ履歴管理が必須かで流れに沿って解説しています。

コミットには、変更の内容を説明する短い文章「コミットメッセージ」を添えます。ここが雑だと、履歴があっても後から読めません。良い例と避けたい例を比べてみます。

書き方のコツは3つです。1つ目は1行目を50字程度までの要約にすること。履歴の一覧では1行目しか表示されないことが多いためです。2つ目は「何をしたか」を動詞で言い切ること。3つ目は、背景や理由が長くなるときは1行空けて本文に書くことです。チームによっては fix: feat: のような接頭辞を付ける決まりを設けていることもあります。

AIコーディングエージェントに実装を任せると、一度にたくさんのファイルが書き換わることがあります。このとき、まとめて1回でコミットしてしまうと、あとから「どの変更が原因で壊れたのか」を切り分けられなくなります。

おすすめは、AIに作業を頼む前に、その時点の状態をコミットしておくことです。こうしておけば、出来上がりが期待と違ったときに、直前の記録へ戻すだけでやり直せます。そして、AIが出した変更は内容を確認してから、機能ごと・修正ごとに区切ってコミットしていきます。AIと進める場合の履歴管理の型は、AI時代のGit運用：コミット分割と差分レビューの実践手順にまとめています。

あわせて気をつけたいのが、記録してはいけないものを含めないことです。パスワード、APIキー、顧客データなどをうっかりコミットすると、履歴に残り続けます。環境変数や除外設定ファイルを使って、そもそもコミット対象に入らないようにしておくのが確実です。

• 大きすぎるコミットを作らない：1つのコミットに複数の目的が混ざると、後から一部だけ取り消すのが難しくなります。
• 動く状態で区切る：可能なら、その時点で動作する状態を記録します。戻り先として使えるかどうかが変わります。
• 秘密の情報を入れない：一度記録すると履歴に残ります。入れないことが最大の対策です。
• 共有済みの履歴は書き換えない：プッシュ済みのコミットを作り直すと、他の人の手元と食い違いが起きます。

手を動かして学びたい場合は、公式の解説書Pro Git 日本語版（git-scm.com）が無料で公開されており、基本操作から履歴の扱いまで順に読み進められます。コマンドを打つ画面そのものについてはターミナルもあわせて確認してください。

• リポジトリ
• バージョン管理
• プルリクエスト
• コードレビュー
• ロールバック
• ブランチ
• マージ
• プッシュ

• Git/GitHub入門：AIコーディング時代になぜ履歴管理が必須か
• AI時代のGit運用：コミット分割と差分レビューの実践手順
• AIが書いたコードのレビューとテスト

Q1. コミットとは何ですか？
ファイルの変更内容を1つの区切りとして履歴に記録する操作のことです。変更内容そのものに加えて、説明文（コミットメッセージ）・作成者・日時・識別子（コミットハッシュ）がまとめて残ります。

Q2. コミットとプッシュ（push）は何が違いますか？
コミットは自分のパソコンの中にある履歴へ記録する操作で、その時点では他の人には見えません。プッシュは、そのコミットを共有サーバー上のリポジトリへ送る操作です。共有するにはコミットのあとにプッシュが必要です。

Q3. コミットメッセージはどう書けばよいですか？
1行目に50字程度までの要約を書き、「何をしたか」を動詞で言い切ります。「修正」「update」のような一語では後から読めません。「ログイン失敗時にエラーメッセージが出ない不具合を修正」のように、対象と目的がわかる書き方にします。

Q4. コミットはどのくらいの単位で区切ればよいですか？
「1つのコミットで説明できることが1つ」になる単位が目安です。機能追加とバグ修正を1回にまとめず、意味のまとまりごとに分けておくと、あとから一部だけ取り消したり、原因を切り分けたりしやすくなります。

Q5. 間違えてコミットしてしまったら取り消せますか？
まだ共有していない直前のコミットなら、内容やメッセージを作り直せます。すでに共有済みのコミットは、打ち消す内容の新しいコミットを積む方法が安全です。なお、パスワードやAPIキーを記録してしまった場合は、履歴を直すだけでなく、その鍵自体を作り直してください。