【Git】git ステージングとは？git add との関係を初心者向けに具体的な手順を解説
はじめに
Git で開発をしていると、ファイルの変更をどのように管理すればいいのか悩むかもしれません。
実は Git にはステージングという仕組みがあり、コミットする前の変更を一時的に管理することができます。
このステージングをうまく使うと、コミットの粒度を自由に調整しやすくなります。
大きな変更をまとめたり、小さな修正を細かく分けたりして、履歴をきれいに保てることが大きなメリットです。
今回は、このgit ステージングをテーマに、実際のコマンド例と実務の活用シーンを交えて解説します。
この記事を読むとわかること
- ステージングの基本概念
- 実務での具体的な活用例
- ステージにファイルを追加・削除する手順
- 変更取り消し時の注意点とコマンド例
- ブランチ戦略とステージングの関連性
これらを踏まえて、コミット時に迷わないためのコツを見つけていきましょう。
Gitにおけるステージングとは？
Git は、バージョン管理システムの中でも分散型という特徴があります。
そこで重要になるのが、ワーキングツリー・ステージ・リポジトリという 3 つの領域をうまく使い分けることです。
ワーキングツリーには現在作業中のファイルがあり、そこで行った変更をステージに一時保存します。
そして、ステージされた内容をコミットすると、ローカルリポジトリに確定された履歴として残る仕組みです。
ステージングの役割
ステージングは「コミットする候補を選ぶ場所」です。
作業中のファイルをすべてコミットに含めるのではなく、細かく選択することでコミットの履歴を整理しやすくなります。
例えば複数のバグ修正や機能追加を同時並行で行っているとき、ステージングを活用すると不要な変更を混ぜ込まずにコミットをまとめられるのが便利です。
実務での活用シーン
レビューを受けやすくするため
大量の変更をひとまとめにコミットすると、レビューする側も混乱しやすくなります。
そこで機能ごとにコミットを区切ると履歴が把握しやすくなり、レビュワーが確認しやすい形に整理できます。
バグ修正と機能追加を分けるため
1 つの作業中でも、機能追加のほかに細かいバグ修正が混在するかもしれません。
ステージングで変更を分ければ、コミットを分離して履歴が明確になります。
あとで差し戻しやすい状態を作るため
コミットを小分けにしておけば、あとから「特定の修正だけを取り消したい」といった場合にも柔軟に対処しやすいです。
ステージへのファイル追加と削除
ステージングを利用する上で重要なのが、どのようにファイルをステージに追加・削除するかです。
基本的には git add や git restore、git rm といったコマンドを使います。
基本的なステージングコマンド
git add <ファイル名>
変更したファイルをステージに追加します。
git restore --staged <ファイル名>
ステージに追加した変更を取り消して、ワーキングツリーの変更だけを残します。
git rm --cached <ファイル名>
すでにステージングしたファイルをステージから削除し、ワーキングツリーにはファイルを残します。
ファイルをステージングする流れ
一般的な流れとしては、次の手順を踏みます。
- ワーキングツリーでファイルを編集する
- コマンドラインで
git add <ファイル名>を実行してステージに追加 - コミットを実行して履歴を残す
ファイル追加の例
例えば、新しく index.html を作成して、以下のようにステージングからコミットまで行うことができます。
git add index.html git commit -m "Add index.html for homepage"
ここで git add index.html は、編集済みの index.html をステージに追加するという意味です。
ファイル削除の例
一方、不要なファイルをプロジェクトから削除したいときは、まずワーキングツリーからファイルを削除し、その後でステージに削除を反映します。
例えば old_script.js を削除したなら、次の手順です。
rm old_script.js git rm old_script.js git commit -m "Remove old_script.js as it is no longer needed"
git rm old_script.js で削除の変更をステージに追加し、コミットで確定させる形です。
変更の取り消しとステージからの削除方法
作業を進めていると「変更をステージに追加したけれど、やっぱりコミットしたくない」というケースがあるかもしれません。
こうしたときは git restore --staged <ファイル名> や git reset コマンドなどを使ってステージングをやり直すことができます。
実践的なシナリオ例
たとえば、誤って多くのファイルを git add . ですべてステージしてしまったとしましょう。
「本当は一部だけをコミットしたい」という場合、以下のように全ファイルをステージから外す方法があります。
git restore --staged .
これで一度ステージを空にしてから、改めてコミットしたいファイルだけを git add すれば、不要な変更を含めずに済みます。
一度ステージから除外したファイルの内容は、ワーキングツリーにはまだ残っています。改めて git add すれば再度ステージに追加できます。
コミットとステージの関係
ステージに変更を追加したら、その状態をコミットで記録します。
コミットはプロジェクトの履歴を管理するための最小単位と考えるとわかりやすいでしょう。
コミットの仕組みをもう一度確認
Git では、コミットを実行した時点でステージにあるファイルのスナップショットがリポジトリに保存されます。
つまり、コミットメッセージとともに「どのファイルのどの変更を保存したか」をまとめて記録するイメージです。
そのため、ステージにはコミットしたいファイルだけを正確に登録する必要があります。
ファイル追加や編集の規模が大きいほど、コミットごとの整理が役に立つでしょう。
ステージングを使いこなすヒント
細かくコミットを行う
1 つのコミットに含める変更が多すぎると、後で履歴を追いかけにくくなります。
ステージングの段階でファイルを選別し、コミットを小さく分割すると管理が楽です。
git add -p の活用
git add -p は対話形式でコミットに含めたい変更を選ぶ方法です。
細やかな差分を確認しながらステージするかどうか選択できるため、実務でも活用されやすいです。
ブランチとステージングの連携
Git はブランチを活用することで、並行開発やテストが非常にしやすくなっています。
そこにステージングを合わせて使うと、コミットの内容をよりクリアにまとめることが可能です。
ブランチ戦略におけるステージの重要性
機能別ブランチを立てる
新機能を開発するときは、メインブランチから分岐したブランチ上で作業します。
このときステージングを丁寧に行うと、余計なファイルや変更が混ざらず、メインブランチへプルリクエストしやすくなります。
修正の履歴を簡潔に保つ
ブランチごとにコミットが整然としていると、あとからどのブランチで何を修正したのかを追いやすいです。
ステージングを使ってコミットの単位を適度に保てば、チームで作業する際もトラブルが減ります。
複数の修正がブランチ上で混在したまま、ステージングやコミットを行うと履歴が混乱しやすくなります。特に共同作業では衝突の原因になることがあるため、ステージングで適切に変更を選別することが大切です。
まとめ
Git のステージングは、コミットする変更を事前に選り分けるための便利な仕組みです。
これを活用すると、不要なファイルまで含めてしまったり、大量の修正をひとまとめにコミットしてしまったりといったミスを防ぎやすくなります。
実務でも、機能追加・バグ修正・コードリファクタリングなどが同時進行するときに、ステージングでコミット単位を分けるのはよくあるパターンです。
コミットが整理されると、後からコードを見返すときや他のメンバーにレビューしてもらうときにも便利です。
ぜひ、git ステージングを習得して、プロジェクトの履歴管理をよりスムーズにしてみてください。
細かいコマンドの使い方に慣れておくと、チーム開発でも作業しやすくなるはずです。