更新履歴
- 【完全ガイド】WinMergeでバイナリ比較をする方法
- SwaggerとOpenAPIの違いを徹底解説!仕様とツールの関係性を理解する
- 【Python】ファイル存在チェックの実装方法(pathlib、os.path)
- Pythonで文字列を除去する方法を完全解説!strip・replace・正規表現
- スタック領域とヒープ領域の違いとは?メモリ管理から使い分けまで徹底解説
- Python Docstringの書き方完全ガイド|主要スタイルの比較と保守性を高める記述
- シングルトン(Singleton)デザインパターンを徹底解説!Java実装例・メリット・デメリット
- サインインとログインの違いとは?意味・使い分けをわかりやすく解説
- 静的サイトと動的サイトの違いを徹底比較!メリット・デメリットと選び方を解説
- モノリスとマイクロサービスの違いを徹底比較|メリット・デメリットと失敗しない選定基準
- RESTとSOAPの違いを徹底比較!特徴・メリット・使い分けを解説
- 同期・非同期とブロッキング・ノンブロッキングの違い|概念と使い分けを徹底比較
- マルチプロセスとマルチスレッドの違いを解説!メリット・デメリット・使い分け
- hostsファイルとDNSの違いとは?優先順位・仕組み・使い分けを解説
- Excelで複数行を1行にまとめる方法まとめ【関数・PQ対応】
- レスポンスタイムとターンアラウンドタイムの違い【基本情報対策】
- ステートレスとステートフルの違いを徹底解説!エンジニアが知るべき仕組みと具体例
- shとbashの違いを徹底解説!シェルスクリプトの使い分け
- 【徹底比較】イーサネットとWi-Fi違いと選び方を解説
- 【徹底解説】UTF-8 BOMあり・なしの違いと選び方
お役立ちツール
Gitユーザにお勧めの本
Gitで変更を記録する前に行う操作が「ステージング(staging)」です。ステージングはファイルをすぐにコミットするのではなく、まず一時的なエリアに変更を登録しておくことで、より柔軟な履歴管理を実現できます。この一時的なエリアに登録するのが、ステージングでgit addコマンドを利用します。
「ファイルを編集したけど、どこまでコミットに含めるべきか?」──そんなときに活躍するのがステージングの仕組みです。本記事では、git add とステージングの基本概念から、実践的な使い方、そしてプロが意識しているベストプラクティスまでわかりやすく解説します。
ステージングとは?──コミット前の「準備エリア」
Gitのステージング(staging)とは、コミットする前に変更内容を一時的に保持しておくエリアのことです。このエリアにファイルの変更を登録することで、どの変更を次のコミットに含めるかを明確に指定できます。
ステージングを活用することで、以下のようなメリットがあります。
-
意図した変更だけをコミットできる
- 不要な修正を混ぜずに、目的ごとにきれいな履歴を残せます。
-
複数の変更を分けて記録できる
- 複数の修正を分けてコミットすれば、後からの変更追跡やレビューが格段に楽になります。
-
差分確認が容易になる
- ステージングした変更のみを確認できるため、意図しない修正を防げます。
git addで変更をステージングする
ステージングエリアに変更を追加するコマンドが git add です。
git addの基本構文
git add ファイル名例:main.py の変更をステージングする場合
git add main.pyこれで main.py の修正が「次回コミットに含める変更」として登録されます。
複数ファイルやディレクトリをステージングする
変更が複数のファイルにまたがっている場合や、ディレクトリ単位でステージングしたい場合には、次のような方法があります。
git add ファイル1 ファイル2 ファイル3 …git add ディレクトリ名/拡張子(ex:.py)を指定してステージングすることもできます。
git add *.pyすべてのファイルをステージングする
カレントディレクトリ以下の全変更を一括でステージングするには .(ドット)を使います。
git add .ただし、このコマンドは不要なファイルまでステージングしてしまう可能性があるため注意が必要です。
ステージングの状態を確認する
現在どのファイルがステージングされているのかを確認するには、git status コマンドを使います。
git status$ git statusOn branch 202504_afterYour branch is ahead of 'origin/202504_after' by 1 commit. (use "git push" to publish your local commits)
Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: ccc.txt
Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: aaa.txtこのコマンドの出力では、Changes to be committedのセクションに表示されるファイルがステージング済みであることを意味します。それに対して、Changes not staged for commitに表示されているのは、まだステージングされていないファイルです。
Changes to be committed:ステージング済みのファイルChanges not staged for commit:まだステージングされていないファイル
ステージング済みの差分を確認する
ステージング済みの差分を確認するには以下コマンドが便利です。
git diff --stagedこれにより、次回のコミットに含まれる変更内容を確認できます。
変更を部分的にステージングする
1つのファイル内に複数の修正が混在している場合は、git add -p が便利です。
このオプションを使うと、変更を「ハンク(hunk)」と呼ばれる小さな単位で確認しながらステージングができます。
git add -p主な操作は以下の通りです。
| 入力キー | 内容 |
|---|---|
| y | この変更(ハンク)をステージングする |
| n | この変更(ハンク)をステージングしない |
| q | 以降の変更(ハンク)は表示せず終了する |
| a | 残りのすべてをステージング |
| d | 残りをすべてスキップ |
| s | 変更(ハンク)をさらに細かく分割する |
| e | 手動で変更内容を編集してステージングする |
これにより、1ファイル内の複数の修正を目的ごとに分けてコミットすることができます。
ステージングで意識したいベストプラクティス
git addによるステージングを効果的に使うために、以下のポイントを意識しましょう。
-
小さな単位でgit addする
ひとつのコミットには、できるだけ意味のある単位で変更を含めましょう。これにより、履歴が読みやすくなり、トラブル時の原因追跡も容易になります。
ポイント
「1コミット=1トピック」を意識して、小分けにステージング。 -
関連する変更だけをまとめる
機能追加やバグ修正といった目的別に変更を整理してからステージングすると、チームでのコードレビューもスムーズになります。
ポイント
機能追加・修正・リファクタリングを混在させない。 -
git add -pで部分的に選ぶこのオプションを使えば、変更の一部だけを対話形式で選んでステージングすることが可能です。細かく変更をコントロールしたい場合に非常に便利です。
ポイント
不要な修正を混ぜずに、意図的なコミットを作れる。 -
.gitignoreを活用するステージング対象から除外したいファイルやディレクトリがある場合は、.gitignore に明記しておくと意図しないコミットを防げます。
ポイント
一時ファイルやビルド成果物はステージング対象外に設定しておく。
まとめ:git addは「コミットの設計図」
git add は単なるファイル追加のコマンドではありません。
それは、「どの変更をコミットとして記録するかを設計するステップ」です。
ステージングを理解して使いこなすことで、
- コード履歴の可読性が向上し、
- チームレビューがスムーズになり、
- バグ修正の追跡もしやすくなります。
ステージングを理解し、適切に活用することで、バージョン管理の質を大きく向上させることができます。
日常的な開発で git add を何気なく使うのではなく、
「コミットの品質を決める操作」として意識してみてください。
Gitユーザにお勧めの本
以上で本記事の解説を終わります。
よいITライフを!