複数のファイルを並行して編集しているとき、いま確定できる1ファイルだけをコミットしたい場面はよくあります。この記事では、安全に1ファイルだけをコミットする方法をまとめます。いつもはなるべく細かくコミットするようにしてるので、たまにこういうシチュエーションになると「どうやるんだっけ・・・」ってなるので、個人的にメモしておくっていう話でもあります＿(　_´ω`)_ﾍﾟｼｮ

シチュエーション

次の3ファイルに変更があるものの、まずは config.js の変更だけをコミットしたい・・・こんなケースを想定してみます。

• config.js（設定の修正：コミットしたい）
• app.js（機能開発中：まだコミットしたくない）
• style.css（デザイン調整中：まだコミットしたくない）

基本手順（最短・安全ルート）

1) 変更状況の確認

git status

出力例

On branch main
Changes not staged for commit:
  modified:   config.js
  modified:   app.js
  modified:   style.css

no changes added to commit

2) 対象ファイルだけをステージング

git add config.js

3) ステージングの確認

git status

出力例

On branch main
Changes to be committed:
  modified:   config.js

Changes not staged for commit:
  modified:   app.js
  modified:   style.css

4) コミット

git commit -m "config.jsの設定を更新"

5) 残りの変更を再確認

git status

出力例

On branch main
Changes not staged for commit:
  modified:   app.js
  modified:   style.css

no changes added to commit

上記ではステージされた config.js だけがコミットされ、他のファイルの進行中の変更はそのまま残ります。

応用：よく使うパターン

パターン1：複数ファイルだけをまとめてコミット

git add config.js utils.js
git commit -m "設定ファイルとユーティリティを更新"

パターン2：ファイルの一部だけをコミット（パッチモード）

同じファイルの変更をハンク単位で選びたいときはパッチモードが便利です。

git add -p config.js

対話例

diff --git a/config.js b/config.js
@@ -10,7 +10,7 @@
 const config = {
-  apiUrl: 'http://localhost:3000',
+  apiUrl: 'https://api.example.com',
   timeout: 5000
 }

Stage this hunk [y,n,q,a,d,s,e,?]?

主な選択肢

• y：このハンクをステージ
• n：このハンクをスキップ
• q：終了
• a：このファイルの残りのハンクをすべてステージ
• d：このファイルの残りのハンクをすべてスキップ
• s：ハンクをさらに分割
• e：ハンク内容を手動編集してステージ
• ?：ヘルプ表示

補足：git commit -p でもコミット直前にハンク選択ができます。

パターン3：うっかりステージしたものを取り消したい

git restore --staged config.js

# すべてのステージを取り消す
git restore --staged .

従来はgit resetを使っていましたが、現状ではgit restore --stagedを使います。

なお、作業ツリーの変更自体を捨てたい場合は、git restore config.js（ステージではなくファイル内容を巻き戻す）を使います。オプション--stagedがないと変更自体がなくなってしまうので注意。

パターン4：ディレクトリ単位で追加

git add src/
git commit -m "srcディレクトリの変更を反映"

実践：段階的にコミットして履歴を綺麗に保つ

# 1) 変更の確認
git status
# 例: config.js, app.js, style.css, README.md が変更

# 2) 設定関連だけをコミット
git add config.js
git commit -m "feat: API URLを本番環境に変更"

# 3) ドキュメント更新をコミット
git add README.md
git commit -m "docs: インストール手順を更新"

# 4) 残りの変更を確認（まだコミットしない）
git status
# 出力: app.js, style.css が変更

メッセージの feat: / docs: は Conventional Commits の形式。チーム開発で可読性が上がります。

コミット前の「見える化」コマンド

差分の確認

# ステージ前（作業ツリー↔インデックス）
git diff config.js

# ステージ済み（インデックス↔HEAD）
git diff --staged config.js    # --cached と同義

# 作業ツリーの全変更（ステージ・未ステージをまとめて）
git diff HEAD config.js

最終チェック

# ステージ済みファイルの一覧
git diff --staged --name-only

# ステージ済みの詳細差分
git diff --staged

# コンパクトな状況表示
git status -s   # --short と同義
git status -v   # ステージ済みの差分行も表示

さらに一歩：知っておくと便利なテク

インタラクティブ・インデックス

git add -i

ファイル選択やパッチ選択を対話式でまとめて処理できます。

一時退避（stash）を活用

他ファイルの未ステージ変更を一時退避して、対象ファイルだけをコミットしたいとき。

# 未ステージの変更だけを退避（インデックスは保持）
git stash --keep-index

# 退避した変更を戻す
git stash pop

「除外して追加」する高度なパス指定（pathspec）

「ほぼ全部をステージしたいが、この2ファイルだけ除外したい」場合は、除外マジックを使えます。

# 例: カレント配下のほぼ全てを追加しつつ、2ファイルを除外
git add . ':(exclude)app.js' ':(exclude)style.css'

うっかり追加を防ぐため、慣れるまでは 明示的にファイル名を列挙 する方が安全です。

よくある誤解と注意点

1. git add . は原則使わない
   変更多数の場面では、意図しないファイルまでステージされがち。
   → 必要なファイルだけを列挙するか、パッチモードで選びましょう。

2. コミットメッセージは具体的に
   「何を、なぜ」変更したか（背景や影響範囲）を残す。
   Conventional Commits（feat:, fix:, docs:…）も有効。

3. 関連する変更はまとめる
   1コミット＝1論理単位。レビューと履歴追跡が楽になります。

4. こまめに差分を確認
   git status / git diff / git diff --staged をループさせて、意図通りのステージになっているかをチェック。

5. ステージ取り消しは git restore --staged が推奨
   旧コマンドの git reset <path> でも同じ効果ですが、最新Gitの意図（作業ツリーとインデックス操作の分離）に沿うのは restore 系です。

まとめ

• やることは「対象だけをステージしてコミット」。
• 部分コミットは git add -p / git commit -p が強力。
• 取り消しは git restore --staged がわかりやすく安全。
• 差分の見える化を習慣化して、履歴を論理的な塊で綺麗に保ちましょう。

参考

1. git add
2. Conventional Commits