2026年10月8日にGitのcommit、add、revert、reset公式マニュアルを再確認した。commitはstagingされたスナップショットを履歴へ記録し、addは次のcommitへ内容を選び、revertは既存commitの効果を打ち消す新しいcommitを作り、resetは参照とindex・作業ツリーの状態を動かし得る。公開済み履歴、未共有履歴、バックアップ、レビュー、承認を分け、resetを共有履歴の安全な取り消しとして説明しない。
コミットは、Gitに変更のまとまりを記録する操作です。写真を撮るイメージは役立ちますが、撮影対象は「いま保存してある全ファイル」ではなく、通常はindexへ選んだ内容です。メッセージは、そのまとまりを後で理解する手掛かりになります。
30秒で要点
- ファイルの保存、stage、commit、pushは別工程。ローカルのcommitだけでは別の機器にバックアップされません。
- 何を含めるかを差分で確認し、1つの意図を説明できる単位で記録します。
- メッセージには変更対象と内容を入れ、理由が重要なら補います。言語や文末はチームでそろえれば十分です。
保存した内容とコミットする内容は違う
作業ツリーは編集するファイル群、indexは次のcommitの準備領域、HEADは現在の履歴の位置です。git-addは実行時点の内容をindexへ入れます。addした後で同じファイルを編集しても、その新しい編集が自動でstageされることはありません。git-commitの通常の動作は、このindexから新しいcommitを作ることです。
図では、HEADにv1、stage済みの内容にv2、編集中の内容にv3があります。このままcommitすると記録されるのはv2で、作業ツリーのv3は未stage変更として残ります。新しいcommitが1つ増えても、作業ツリーが必ず差分ゼロになるわけではありません。
ログイン機能を記録する練習
最初のcommitがある練習用リポジトリで、index.htmlにログイン画面を追加した場面です。script.jsの別機能の修正やold-style.cssの削除を一緒に入れるかは、同じ意図を構成するかで判断します。名前が同じ日付の変更というだけでまとめません。
1. 対象を選ぶ
git status
git diff
git add index.html
git diff --cachedstatusは状態の一覧、diffは未stageの差分、diff --cachedはcommit予定の差分です。git add .でまとめることもできますが、無関係な変更や公開してはいけない設定を含めないよう先に確認します。1ファイル内で意図が混じる場合は、公式のgit add -pによる部分選択も候補です。
2. 内容を言葉にして記録する
git commit -m "ユーザーログイン機能を追加"
git log -1 --oneline
git status --shortcommit後にはログと残りの差分を確認します。広い履歴を見る元のgit logも同じ確認役割です。表示されるa1b2c3d4e5f6のような文字列はcommitを識別する表記の例であり、日時の順番を表す連番ではありません。短縮値はリポジトリ内で識別できる長さを使います。
メッセージは「何を、なぜ」で選ぶ
表が収まらない場合は、横にスクロールできます
| 例 | 読み手が分かること | 追加したい情報 |
|---|---|---|
ユーザー登録機能を追加 | 対象機能と追加という変更 | 必要なら目的や制約を本文に書く |
ユーザー登録機能を追加しました。これにより、ユーザーがアカウントを作成できるようになりました。 | 同じ内容を長く繰り返している | 表題を短くし、理由や注意を分ける |
ログイン画面のデザインを改善 | 画面は特定できる | 余白・エラー表示など実際の変更を具体化する |
デザインを改善 | 対象が分からない | どの画面かを補う |
パフォーマンスを改善するため、画像を最適化 | 変更意図は分かる | 寸法や形式の変更、実測の有無を区別する |
画像を最適化 | 画像に触れたことだけ | 対象と処理内容を書く |
たとえば「ログイン失敗時に入力内容を保持」は、確認すべき動作まで想像しやすい表題です。速くなったと未測定の効果を断定する必要はありません。敬体か常体か、英語か日本語かはGitの成立条件ではなく、読み手との約束です。
粒度とWIPを決める
変更行が少なければよいのではありません。画面と対応する検証を一緒に記録した方が、1つの変更として理解しやすい場合があります。一方、機能追加と無関係な一括整形が混じると原因調査が難しくなります。
作業途中を示すWIPもローカルで経過を保つ用途があります。ただし、共有するブランチでどの状態を許すか、統合前にどう整理するかを決めます。「commitできたから完成」という判断は避け、テストやレビューの状態を別に扱います。
取り消しは目的と共有状態で分ける
表が収まらない場合は、横にスクロールできます
| 目的 | 操作の考え方 | 注意 |
|---|---|---|
| stage対象を外す | git reset -- index.htmlはindex側を戻す | このpath指定形式はHEADや作業ファイルを動かさない |
| 共有済みの変更の効果を取り消す | revertで逆の変更を新commitとして記録する | 後続変更と競合する場合がある |
| 未共有の履歴の位置を変える | resetのcommit指定などを目的別に検討する | modeでindex・作業ツリーへの影響が違う |
この表はgit-resetとgit-revertの異なる役割を整理したものです。--hardは作業内容を上書きし得るため、単にエラーを消すための手順にはしません。merge commitのrevertには親の選択など追加の判断があります。
次は、作業ツリーがきれいで、直前の通常commitだけを取り消す練習です。重要な変更のあるリポジトリで無条件に実行しないでください。
git status --short
git revert --no-edit HEAD
git log -2 --oneline履歴は削除されず、取り消すためのcommitが1つ追加されます。元の変更と逆変更を追えることと、障害時の復旧手順が適切であることは別です。実際のサービスではデータや公開状態も確認します。
記録を失わないために確認すること
ローカルcommitがあっても、その端末の故障で履歴を失う可能性があります。必要な履歴を許可されたremoteへ送る運用やバックアップを別に用意します。pushしていない履歴、未追跡ファイル、外部データまで自動的に保護されるわけではありません。
1人開発でも、未来の自分が理由を読み取れるメッセージは役立ちます。チームでは「1つの意図」「対象が分かる表題」「統合前の確認」の最小セットから始め、困った例が出たときに規則を足す方が実用的です。