Git Add, Commit and Status: Master the Core Workflow Without Losing Work

I've seen a junior dev delete three days of work because they didn't understand the difference between git add and git commit. They thought git commit -a would save everything, but it only saved tracked files — their new config file was gone forever. That's the kind of pain this article prevents.

The problem is that Git's core workflow — add, commit, status — is deceptively simple. Most tutorials show you the happy path: git add . then git commit -m "stuff". But in production, you need precision. You need to know exactly what's staged, what's not, and how to undo mistakes before they become permanent.

By the end of this, you'll be able to track changes with surgical precision, recover from accidental commits, and never again push a half-baked feature or lose work because you didn't stage the right files.

What Exactly Is the Staging Area?

Before you can commit, you need to understand the staging area. It's Git's middle ground between your working directory and the repository. Why does it exist? Because you don't always want to commit everything you've changed. Maybe you fixed a bug in one file but also made experimental changes in another. The staging area lets you pick and choose which changes go into the next commit.

Without a staging area, you'd have to commit every change as it happens — or use complex workarounds like creating temporary branches. Git's staging area gives you surgical control. It's the difference between dumping your entire toolbox on the table and carefully selecting the right screwdriver.

Here's how a typical workflow looks: you edit files, then use git add to stage specific changes. You can stage entire files or even individual lines within a file using git add -p. Then git status shows you exactly what's staged and what's not. Finally, git commit saves the staged snapshot.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

# Initialize a test repo
git init staging-demo
cd staging-demo

# Create two files
echo "Hello" > file1.txt
echo "World" > file2.txt

# Check status — both files are untracked
git status

# Stage only file1.txt
git add file1.txt

# Status now shows file1 staged, file2 untracked
git status

# Commit only the staged file
git commit -m "Add file1.txt"

# Status now shows clean working directory except file2
git status

git status: Your Safety Net

git status is the most underrated command in Git. It tells you exactly what's going on: which files are modified, which are staged, and which are untracked. I run it before every git add and before every git commit. It's like checking your mirrors before changing lanes — you'd be stupid not to.

Why is this so important? Because git add . is a shotgun — it stages everything in the current directory, including generated files, logs, and secrets. I've seen people accidentally commit API keys because they didn't check status first. git status shows untracked files in red, so you can add them to .gitignore before they become a problem.

git status also tells you if you're on the right branch, if you're ahead/behind the remote, and if there are merge conflicts. It's your dashboard. Learn to read it.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

git init status-demo
cd status-demo

# Create a file and stage it
echo "content" > tracked.txt
git add tracked.txt
git commit -m "Initial commit"

# Modify the file
echo "more content" >> tracked.txt

# Create a new untracked file
echo "secret" > secret.txt

# Run status
git status

# Output shows modified tracked file and untracked file

git add: Staging with Precision

git add moves changes from your working directory to the staging area. You can stage entire files (git add file.txt), multiple files (git add file1.txt file2.txt), or all changes in the current directory (git add .). But the real power is in staging parts of a file.

Use git add -p (or git add --patch) to interactively stage hunks. Git will show you each change and ask if you want to stage it. This is how you keep commits focused. For example, you might have a file with a bug fix and a formatting change. You can stage only the bug fix hunk, commit it, then stage the formatting change separately.

Another common pattern is git add -A which stages all changes including deletions. git add -u stages only modified and deleted tracked files (no new files). Know the difference — using the wrong one can leave out new files or include unwanted deletions.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

# Create a repo with a file
git init add-demo
cd add-demo
echo -e "line1\nline2\nline3" > file.txt
git add file.txt
git commit -m "Initial"

# Make two changes: fix a bug and add a comment
echo -e "line1\nline2_fixed\nline3\n# TODO: optimize" > file.txt

# Interactive staging — press 'y' for first hunk, 'n' for second
git add -p file.txt

# Check what's staged
git diff --cached

# Commit only the bug fix
git commit -m "Fix typo in line2"

# Now stage and commit the comment
git add -p file.txt
git commit -m "Add TODO comment"

git commit: Saving a Snapshot

git commit takes everything in the staging area and creates a permanent snapshot in the repository's history. Each commit has a unique hash, an author, a timestamp, and a message. The message is critical — it's how you and your team understand what changed and why.

Write good commit messages. The first line should be a short summary (50 chars max), then a blank line, then a detailed description. This follows the conventional commit format and makes git log readable. Bad commit messages like "fix stuff" or "update" are useless when you're debugging a production issue six months later.

Use git commit -m "message" for short commits. For longer messages, omit -m and Git will open your default editor. Pro tip: set your editor to something you're comfortable with using git config --global core.editor "code --wait" for VS Code.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

git init commit-demo
cd commit-demo

# Create and stage a file
echo "initial" > app.py
git add app.py

# Bad commit message
git commit -m "update"

# Good commit message — use conventional format
git commit --allow-empty -m "feat: add user authentication

Implement JWT-based authentication for the login endpoint.
Includes token generation and validation middleware.
Closes #42"

# View the log
git log --oneline

Undoing Mistakes: Reset and Restore

You will make mistakes. You'll stage the wrong file, commit too early, or commit to the wrong branch. Git gives you tools to undo without panic.

To unstage a file (keep changes but remove from staging): git reset HEAD <file>. To discard changes in a file entirely (irreversible!): git restore <file>. To undo the last commit but keep changes staged: git reset --soft HEAD~1. To undo the last commit and unstage changes: git reset HEAD~1. To undo the last commit and discard changes: git reset --hard HEAD~1 — but be careful, this deletes changes permanently.

I use git reset --soft all the time when I accidentally commit to the wrong branch. I undo the commit, stash the changes, switch branches, and pop the stash. It's a five-second fix that saves a lot of pain.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

git init undo-demo
cd undo-demo

# Setup: create a commit
echo "important" > file.txt
git add file.txt
git commit -m "Initial commit"

# Accidentally stage a file you don't want
echo "secret" > secret.txt
git add secret.txt

# Unstage it
git reset HEAD secret.txt

# Now modify file.txt and stage it
echo "more" >> file.txt
git add file.txt

# Commit but realize you forgot something
git commit -m "Update file.txt"

# Undo the commit but keep changes staged
git reset --soft HEAD~1

# Now you can add the forgotten change and recommit
echo "even more" >> file.txt
git add file.txt
git commit -m "Update file.txt with all changes"

# Check log
git log --oneline

The Complete Workflow: A Production Example

Let's put it all together with a realistic scenario. You're working on a checkout service. You fix a bug in payment.js, add a new feature in discount.js, and accidentally create a log file debug.log. Here's how to handle it like a pro.

First, run git status to see the landscape. You'll see payment.js and discount.js as modified, and debug.log as untracked. Add debug.log to .gitignore so it never gets committed. Then stage only payment.js for the bug fix commit. Commit with a message like "fix: correct tax calculation for international orders". Then stage discount.js for the feature commit. Commit with "feat: add bulk discount logic".

This creates two clean, focused commits. If something goes wrong, you can revert one without affecting the other. That's the power of the staging area.

#!/bin/bash
# io.thecodeforge — DevOps tutorial

git init checkout-service
cd checkout-service

# Simulate existing code
echo "// payment logic" > payment.js
echo "// discount logic" > discount.js
git add .
git commit -m "Initial commit"

# Make changes
echo "// fixed tax" >> payment.js
echo "// added bulk discount" >> discount.js
echo "[DEBUG] log" > debug.log

# Step 1: Check status
git status

# Step 2: Add debug.log to .gitignore
echo "debug.log" >> .gitignore

# Step 3: Stage only payment.js
git add payment.js

# Step 4: Commit bug fix
git commit -m "fix: correct tax calculation for international orders"

# Step 5: Stage discount.js
git add discount.js

# Step 6: Commit feature
git commit -m "feat: add bulk discount logic"

# Step 7: Verify history
git log --oneline