Git Commits

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:
Automatically stages all modified tracked files
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
-amis 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
