Skip to main content

Command Palette

Search for a command to run...

Git Commits

Updated
3 min read
Git Commits
R

🎓 B.Tech CSE | 👨‍💻 Learning DSA & C++ | 🚀 Building projects & writing what I learn | 📚 Currently solving LeetCode & exploring Git/GitHub


Ever Wondered What Happens When You Commit (With Staged and Unstaged Changes)?

This is one of those Git behaviors that I use daily but don’t fully internalize until they slow down and think about it.

I had that moment today.


The Situation That Made It Click

I was working on multiple points:

  • I implemented point 1

  • I didn’t want to mess with its changes

  • So I staged point 1

  • Then I started working on point 2, which remained unstaged

At that moment, I thought:

Do I really need separate commits for everything?
Can I commit now and expect only the staged changes to go in?

So I had:

  • One file staged

  • One file unstaged

And I committed.

That’s when the picture became clear.

I already knew what git add . and git commit do—but I had never been in a situation where I had to reason about them consciously.
Earlier, it felt like walking forward just because “this is the path” — almost on autopilot.

This time, the dots connected.


A Common Situation

Assume this state:

  • 5 files are staged

  • 2 files are modified but not staged

git status

(This shows both staged and unstaged changes.)

Now you run:

git commit -m "commit message"

What Git Does at This Point

  • Git commits only the 5 staged files

  • The 2 unstaged files remain untouched in the working directory

This is not a special case.
This is how Git is designed.

  • Git does not commit “what changed”

  • Git commits what is staged


Why the Staging Area Exists

The staging area is not just an intermediate step.
It is a decision boundary.

  • Working directory → experimentation

  • Staging area → intentional selection

  • Commit → permanent history

Once you see staging as a selection mechanism, Git behavior becomes predictable.


Why git add . Suddenly Makes Sense

Earlier, I knew what this command did, but I didn’t have clarity.
It felt like following steps without understanding why—just moving forward because it eventually works.

git add .

This stages everything.

But the important realization is what it really means:

“At this moment, I consider all current changes ready to be committed.”

That includes:

  • Modified tracked files

  • New untracked files

Nothing more. Nothing less.


Selective Staging Is the Default Power Move

You are not required to stage everything.

git add file2 file3
git commit -m "commit only specific files"

This allows you to:

  • Keep commits focused

  • Separate unrelated changes

  • Maintain a clean history

This is not an advanced trick.
This is the intended Git workflow.


Where git commit -am Fits In

Now consider:

git commit -am "commit message"

This command does two things:

  1. Automatically stages all modified tracked files

  2. Commits them

Important limitations

  • It does not include untracked (new) files

  • It bypasses the explicit staging step

  • You lose fine-grained control

So in the earlier scenario:

  • The 2 unstaged tracked files will be committed

  • Any new files will still be ignored


-am is a convenience shortcut, not a replacement for staging

-a (auto-stage)

  • Stages only tracked files

  • Includes:

    • Modified files

    • Deleted files

  • Excludes:

    • New (untracked) files

-m (message)

  • Adds the commit message inline

Combined meaning:

Stage all changes to tracked files, then commit them