Mastering Git Stage and Commit: Your First Changes

Mastering Git stage and commit basics is the first real step toward using Git confidently. Staging lets you choose exactly what goes into the next snapshot, and committing records that snapshot with a message future readers can understand.

If you treat every commit as a small, reviewable unit of work, Git becomes much easier to use. You can inspect changes, split unrelated edits, and recover from mistakes without panic.

How the Staging Area Works

Git does not automatically commit every file you edit. It separates your work into the working tree, the staging area, and committed history.

The working tree is your project folder. These are the files you edit in your editor.

The staging area is Git's checklist for the next commit. When you run git add, you are not saving history yet. You are selecting changes for the next commit.

The repository history is the sequence of commits already recorded.

Start by checking status:

git status

Git will show untracked files, modified files, staged changes, and your current branch. This command is safe to run anytime and should become a habit.

To stage a new or modified file:

git add README.md

To stage all changes under the current directory:

git add .

That command is convenient, but use it carefully. It can stage unrelated files, local config, or generated output if your .gitignore is incomplete.

For a safer review, inspect the diff first:

git diff

Then stage only what belongs together:

git add src/app.js
git add README.md

After staging, check what will be committed:

git diff --staged

This shows the exact staged snapshot. If something looks wrong, fix it before committing.

Making Your First Commit

Once the right changes are staged, create a commit:

git commit -m "Add project README"

The message should describe the change, not the action you took. "Add project README" is more useful than "changes" or "update files."

A good commit usually has one clear purpose. For example, suppose you update a deployment script and also fix a typo in a documentation page. Those are separate changes. Stage and commit them separately:

git add scripts/deploy.sh
git commit -m "Add deployment health check"

git add docs/setup.md
git commit -m "Fix setup guide typo"

This makes review easier. It also makes rollback easier if the deployment change causes a problem but the documentation fix is fine.

If you run git commit without -m, Git opens your editor. That is useful when you need a longer message:

Add deployment health check

Verify the service endpoint before marking the deployment complete.
This helps catch failed starts earlier in the release process.

The first line should be short and direct. The body can explain why the change was needed or mention tradeoffs.

To see recent commits:

git log --oneline -5

This gives you a compact view of the latest history.

Staging Parts of a File

Sometimes one file contains multiple unrelated edits. Git can stage only part of a file with patch mode:

git add -p src/config.js

Git shows each change hunk and asks what to do. Common choices are:

• y: stage this hunk.
• n: do not stage this hunk.
• s: split the hunk into smaller pieces if possible.
• q: quit patch mode.

Patch staging is useful when you are cleaning up before a commit. For example, you might have one file where you added a new timeout setting and also reformatted a comment. Stage the timeout change for one commit, then stage the comment cleanup for another.

If you staged something by mistake, unstage it without discarding your work:

git restore --staged src/config.js

Your file remains modified in the working tree. It is simply removed from the staging area.

If you want to discard unstaged changes in a file, be careful:

git restore src/config.js

That command throws away local edits in that file. Run git diff first so you know what you are losing.

For more recovery patterns, see how to undo Git mistakes.

Commit Hygiene for Everyday Work

Small, focused commits are easier to review, test, and revert. They also make tools like git bisect more useful when you need to find where a bug started.

Use these habits:

• Run git status before staging.
• Review git diff before git add.
• Review git diff --staged before committing.
• Keep unrelated changes in separate commits.
• Write messages that explain what changed.
• Avoid committing generated files unless the project expects them.
• Never commit secrets, private keys, or local .env values.

A practical workflow might look like this:

git status
git diff
git add src/server.js
git diff --staged
git commit -m "Handle missing health check response"
git status

That sequence is not flashy, but it catches most beginner mistakes. You know what changed, what is staged, what was committed, and what remains.

If your team uses pre-commit hooks or automated formatting, a commit may fail until you fix formatting or tests. Read the error message, run the suggested command, stage the resulting changes, and commit again.

When to Ask for Help

Ask for help if you accidentally staged or committed secrets, if you committed to the wrong branch, or if you are unsure whether to amend, revert, reset, or make a new commit. Those choices have different effects, especially after a push.

You should also ask before rewriting commits that other people may have pulled. A simple local cleanup can turn into a team problem if it changes shared history.

Staging and committing are the core loop of Git. Review your changes, stage intentionally, commit in focused pieces, and write messages that make sense a month from now.