---
title: "コミットとは？Gitが変更履歴を記録する仕組みと粒度・メッセージ設計を実装視点で解説"
url: "https://www.issoh.co.jp/tech/details/13558/"
published: 2026-07-12
updated: 2026-09-27
categories: ["開発"]
publisher: "株式会社一創"
---

# コミットとは？Gitが変更履歴を記録する仕組みと粒度・メッセージ設計を実装視点で解説

コミット（`git commit`）とは、Gitで変更したファイルの状態を履歴として記録する最小の単位です。ソースコードのある時点のスナップショットに、誰が・いつ・なぜ変更したのかという情報を付けて確定させる操作を指します。コマンド自体は数秒で覚えられますが、実務で効いてくるのは「どの範囲を1つのコミットにまとめ、どんなメッセージを残すか」という設計判断のほうです。この記事では、コミットの内部的な仕組みから、粒度とメッセージの決め方、取り消しの操作、そして受託開発でチームとして運用へ落とす方法までを、実装者の視点で順に整理します。

## まとめ：コミットは変更履歴の最小単位で粒度とメッセージが後の価値を決める

先に結論を示します。コミットとは、ステージングした変更をリポジトリに確定させ、一意のハッシュ（識別子）付きで履歴に刻む操作です。技術的な要点は次の3つに集約できます。第一に、1つのコミットは「1つの目的」で閉じるように粒度を設計すること。第二に、コミットメッセージは後から履歴を読む人のための一次情報であり、Conventional Commitsのような規約で書式をそろえること。第三に、コミットは`git commit --amend`やリセットで作り直せるが、共有済みの履歴を書き換える操作はチームで合意した範囲に限ること。この3点を運用ルールにできれば、コミットはバグ調査・レビュー・リリース判断すべての土台になります。以降で仕組みと判断基準を掘り下げます。

## コミットとは何か──Gitが変更履歴を記録する仕組みと内部構造を理解する

Gitは変更を「差分」ではなくスナップショットとして扱います。コミットを実行すると、その時点のファイル群の状態がツリーとして保存され、コミット・オブジェクトがそのツリーと親コミットを指し示します。コミット・オブジェクトには、内容から計算されるハッシュ値（識別子）、作者と日時、メッセージ、そして直前のコミットへの参照が含まれるのが特徴です。この「親をたどれる鎖」が履歴の実体であり、あるコミットは過去のすべてのコミットとつながっています。

識別子は内容から算出されるため、同じ変更・同じメッセージ・同じ親でも作者や日時が変われば別のハッシュになります。つまりコミットは改ざんを検知できる仕組みを持ち、履歴の一貫性が保たれる構造です。ブランチは特定のコミットを指す軽量なラベルにすぎず、コミットを積むたびにブランチの参照が新しいコミットへ前進していきます。ここを押さえると、後述するリセットやamendが「履歴という鎖のどこを指し直すか」という操作だと理解できます。

| 要素        | 役割          |
| --------- | ----------- |
| ハッシュ（識別子） | コミットを一意に指す値 |
| ツリー       | その時点のファイル構成 |
| 親コミット     | 直前の履歴への参照   |
| 作者・日時     | 変更の責任と時系列   |
| メッセージ     | 変更理由の一次記録   |

## ステージングからコミットまでの基本操作と最小限のコマンドの流れ

コミットは「変更 → ステージング → コミット」という2段階で確定します。作業ツリーで編集したファイルは、まず`git add`でステージングエリアに載せ、そこに載っているものだけが次のコミットに含まれる仕組みです。この一段構えがあるおかげで、1回の作業で複数の変更をしても、コミットに含める範囲を選び分けられます。基本的な流れは次のとおりです。

```
git status
git add .
git commit -m "ユーザー登録のバリデーションを追加"
git log --oneline
```

`git status`で現在の変更とステージング状況を確認し、`git add`で対象を載せ、`git commit`でメッセージを付けて確定します。特定のファイルだけを載せたいときはドットの代わりにファイル名を指定する形です。ステージングから外したいときは`git restore --staged`で戻せます。`git log`は積み上がった履歴を新しい順に表示し、各コミットのハッシュとメッセージを確認できます。ここまでが、どの現場でも共通する土台の操作です。

## 良いコミットの粒度とは──1コミット1目的で履歴を設計する考え方

操作を覚えた次に問われるのが粒度です。原則は「1コミット1目的」です。機能追加とバグ修正とフォーマット整形を1つのコミットに混ぜると、後からその変更だけを取り消したり、レビューで意図を追ったりするのが難しくなります。逆に、意味のある単位で区切っておけば、問題のあるコミットだけを狙って戻せますし、`git bisect`のような二分探索でバグの混入点を特定する精度も上がります。

粒度を保つ実務のコツは、作業を始める前に「このコミットで何を完了させるか」を一文で言えるかを基準にすることです。一文で言えないなら、それは複数のコミットに分けるべき合図です。すでに変更が混ざってしまった場合は、`git add -p`で変更を部分的にステージングし、目的ごとにコミットを分割できます。粒度の設計は、後のレビューコストとバグ調査コストを前払いで下げる投資だと考えると判断しやすくなります。

| 粒度     | 後工程への影響      |
| ------ | ------------ |
| 大きすぎる  | 取り消し・レビューが困難 |
| 1目的で適切 | 戻す・追う・探すが容易  |
| 細かすぎる  | 履歴が冗長で読みにくい  |

## コミットメッセージの規約とConventional Commitsで標準化する

コミットメッセージは、半年後の自分や別の担当者が履歴を読むための一次情報です。「修正」「更新」だけのメッセージは、何をなぜ変えたのかを伝えられません。実務では、1行目に変更の要約、空行を挟んで本文に背景や理由を書く書式が読みやすいとされています。要約は「何をしたか」を現在形で簡潔に、本文は「なぜそうしたか」を残すと、後の調査で価値が出ます。

書式をチームでそろえる方法として広く採用されているのがConventional Commits（1.0系）です。`feat`（機能追加）、`fix`（バグ修正）、`docs`（文書）、`refactor`（挙動を変えない整理）といった接頭辞を付け、種別を機械的に判別できる形にします。これにより、変更履歴からリリースノートを自動生成したり、意味的なバージョン番号を自動で決めたりする仕組みへ接続できる点が利点です。規約は導入して終わりではなく、後述のレビューやCIで守られているかを機械的に確かめる運用まで含めて効果が出ます。

```
feat: ユーザー登録にメール形式のバリデーションを追加

未検証のアドレスによる登録失敗を防ぐため。
入力時と送信時の二段階で検証する。
```

## コミット履歴を運用する場面での修正・取り消し・チーム連携の判断

コミットは確定後でも作り直せます。直前のコミットにファイルの入れ忘れがあったりメッセージを直したりしたいときは`git commit --amend`で上書きする形です。まだ共有していないローカルの履歴なら、リセットで複数のコミットをまとめ直したり、順序を整えたりする運用も取れます。ここで判断の分かれ目になるのが「その履歴をすでに共有したか」です。

共有済みのコミットを書き換えると、他のメンバーの手元の履歴と食い違い、後から混乱を生みます。そのため、プッシュ済みの履歴を書き換える操作はチームで合意した範囲に限り、原則は打ち消しの新しいコミットを積む`git revert`で対応するのが安全です。revertは「取り消した」という事実そのものを履歴に残すため、監査や障害対応の記録としても筋が通ります。作り直し（amend・リセット）とは共有前の整理、打ち消し（revert）とは共有後の修正、という切り分けを持っておくと迷いません。コミットが積み上がる系統そのものの分岐については、[ブランチとは？バージョン管理で開発を分岐させる仕組み](https://www.issoh.co.jp/tech/details/13782/)で概念から整理しています。

| 状況        | 取るべき操作       |
| --------- | ------------ |
| 共有前の直前修正  | amend で上書き   |
| 共有前の整理    | リセットでまとめ直す   |
| 共有済みの取り消し | revert で打ち消す |

## 受託開発でコミット運用をレビューやCIと結び付ける実装の設計方針

個人の習熟に任せると、コミットの粒度やメッセージは担当者ごとにばらつきます。受託開発のように複数人・長期のプロジェクトでは、コミット運用をチームの仕組みへ落とすことで品質が安定します。具体的には、コミット単位でのレビューを前提にした粒度ルールを決め、メッセージ規約を明文化し、CIでその規約や自動テストの通過を機械的に確かめる、という三段構えです。コミットが小さく目的が明確であれば、レビューでの指摘は的確になり、差し戻しも局所で済みます。

こうしたルール整備や既存プロジェクトの運用改善は、内製化支援と保守運用の一環として外部の力を借りて進める選択肢もあります。一創では[保守運用・内製化支援サービス](https://www.issoh.co.jp/service/system/maintenance/)で、Git運用ルールの整備やレビュー体制づくりを含めた開発プロセスの改善を後押しする体制です。コミットの設計を、レビューの実務は[コードレビューとは？目的・観点・進め方](https://www.issoh.co.jp/tech/details/13384/)、開発と運用を結ぶ全体像は[DevOpsとは？実践・ツール・導入判断](https://www.issoh.co.jp/tech/details/13538/)と併せて設計すると、履歴が調査とリリースの両方で機能します。

## よくある質問

### git add とコミットの違いは何ですか？

git addは変更をステージングエリアに載せる準備の操作で、コミットはその載せた変更を履歴として確定する操作です。addで「次のコミットに含めるものを選び」、commitで「それを確定して記録する」という二段階の関係になります。

### コミットメッセージには何を書けばよいですか？

1行目に変更の要約、本文に変更した理由や背景を書くのが基本です。「何をしたか」だけでなく「なぜそうしたか」を残すと、後の調査やレビューで価値が出ます。Conventional Commitsのような接頭辞の規約を使うと書式をそろえられます。

### 間違ってコミットしたら取り消せますか？

取り消せます。共有前ならamendやリセットで作り直せますし、共有後は打ち消しの新しいコミットを積むrevertで対応します。共有済みの履歴を直接書き換えると他のメンバーと食い違うため、revertでの対応が安全です。

### どのくらいの単位でコミットすべきですか？

「1コミット1目的」が原則です。そのコミットで何を完了させるかを一文で言える範囲が目安になります。機能追加・バグ修正・整形を混ぜず、意味のある単位で区切ると、後から戻す・追う・原因を探すのが容易になります。

### コミットとプッシュの違いは何ですか？

コミットは手元のローカルリポジトリに履歴を記録する操作で、プッシュはそのコミットをリモートの共有リポジトリへ反映する操作です。コミットした段階ではまだ自分の手元だけの記録で、プッシュして初めてチームと共有されます。

## 関連記事

- [コードレビューとは？目的・観点・進め方と実装現場の運用設計を解説](https://www.issoh.co.jp/tech/details/13384/)
- [DevOpsとは？開発と運用を統合する実践・ツール・導入判断を実装視点で解説](https://www.issoh.co.jp/tech/details/13538/)
- [SDLCとは？ソフトウェア開発ライフサイクルの工程・モデル・DevOps連携を解説](https://www.issoh.co.jp/tech/details/13386/)
- [リポジトリとは？Gitでソースコードを管理する仕組みとローカル・リモートの使い分けを解説](https://www.issoh.co.jp/tech/details/13560/)

---

出典: [コミットとは？Gitが変更履歴を記録する仕組みと粒度・メッセージ設計を実装視点で解説](<https://www.issoh.co.jp/tech/details/13558/>)（株式会社一創）