Gitのステージング、実際に手を動かしてやっと理解した話

おはようございます、YASUです。

先日「ステージングのイメージがよく分からない」という話を書きましたが、昨夜ついに実際にターミナルを開いて、手を動かしてみました。結論から言うと、やっぱり「触ってみないと分からない」は本当でした。今日はその一部始終を、失敗談も込みで共有します。

結論

ステージングは、実際に git status を打ちながら「表示がどう変わるか」を目で追うと、一発で腹落ちします。理屈だけで理解しようとしていた自分に、正直「早く触ればよかった」と言いたいです。

まず、練習用フォルダを間違えかけた話

最初、普段使っているTypeScript練習用フォルダでそのまま始めようとしたのですが、よく考えたらそこにはこれまで積み上げてきた大事な設定ファイルやソースコードが入っています。うっかり巻き込んで壊すのも怖いので、急遽まっさらな git-practice フォルダを新しく作ることにしました。

cd ~
mkdir git-practice
cd git-practice

ここで地味に「あれ、mkdirってフォルダ作るコマンドだったんだ」と再確認。cd(移動)とmkdir(作成)、Gitとは関係ない基本のターミナル操作ですが、こういう地味なところも一つずつ体に入れていく感じです。

mkdir は「フォルダを新しく作る」コマンドです。make directory(ディレクトリを作る)の略で、mk(make)+ dir(directory)という成り立ちです。

初期化(git init)を実際にやってみる

まっさらなフォルダで git status を打つと、こんなエラーが出ました。

fatal: not a git repository (or any of the parent directories): .git

「このフォルダ、まだGitに何も伝えてないですよ」という意味です。ここで満を持して git init。

git init

Initialized empty Git repository と表示され、これでこのフォルダがGit管理下に入りました。

いよいよステージングの実感タイム

適当なテストファイルを2つ作ります。

echo "test1" > a.txt
echo "test2" > b.txt
git status

両方とも「Untracked files(未追跡)」として表示されました。ここまでは想定通り。ここから、片方だけステージングしてみます。

git add a.txt
git status

そしたら表示が、こう分かれたんです。

Changes to be committed:
    new file:   a.txt

Untracked files:
    b.txt

これです。これが見たかった瞬間でした。a.txtだけが「コミットされる予定」のグループに移動して、b.txtは置いてけぼり。文章で「机の上・荷造り箱・倉庫」と説明されるより、この画面を見た方が100倍理解が早かったです。

コミット、そして「片方だけ残る」現象

git commit -m "aファイルを追加"
git status

コミットした後にもう一度statusを見ると、a.txtはもう表示から消えて、b.txtだけが「Untracked」として残っていました。同じタイミングで作った2つのファイルなのに、ステージングしたかどうかだけで、片方だけが履歴に残る。これがまさに「編集した全部が自動でコミットされるわけではない」という話の実物でした。

ブランチを切って、合体(マージ)させる

ここまでで満足しかけましたが、せっかくなのでブランチも切ってみることに。

git checkout -b feature/practice
echo "practice" > c.txt
git add c.txt
git commit -m "PR練習用のファイル追加"

この状態で main ブランチに戻ると、c.txtが忽然と消えます(消えたわけではなく、feature/practiceブランチにしか存在しないだけなのですが、切り替えた瞬間にフォルダの中身がガラッと変わるのは、地味に面白い体験でした)。

git checkout main
ls
# → a.txt b.txt (c.txtがない)

ここでマージ。

git merge feature/practice
ls
# → a.txt b.txt c.txt (c.txtが復活)

Fast-forward という表示とともに、あっさりマージ成功。これが「合体」の正体でした。

実務で事故りやすいポイントも合わせて確認

ここまでやってみて、逆に「これ、実務で焦ってやると事故りそうだな」というポイントも見えてきました。

• ブランチを切らずに、いきなりmainに直接コミット・プッシュしてしまう
• git add .(全部まとめて追加)の癖で、パスワードなどが入った設定ファイルまで巻き込んでコミットしてしまう
• force push(強制上書き)で、他の人の変更履歴ごと消してしまう
• コンフリクト(競合)を焦って適当に解消し、大事な変更を消してしまう

こまめに git status で確認する癖、小さく分けてコミットする習慣は、まさにこういう事故の予防線になっているんだな、と実感しました。

まとめ

• ステージングは理屈より先に、実際に git status の表示の変化を見るのが一番理解が早い
• ブランチを切って作業→mainに合体、という一連の流れも、実際に手を動かすと一気に体に入る
• こまめな確認とこまめなコミットは、実務での事故予防にそのまま直結する

「習うより慣れろ」とはまさにこのことでした。次はGitHub上で本物のPull Requestまで作ってみようと思います。それでは、また明日!