How to make a git commit (for total noobs)

You wrote some code.

Nice.

Now let’s turn that into a tidy little snapshot of history with a Git commit. This is your “save game” button for projects.

Saving your work is always good (since you're about to code some nonsense and IMMEDIATELY wish you had a save point to go back to)...

What a commit actually is

• A record of changes at a point in time.

• A message explaining why you changed things.

• A unique ID so you can find it later and look brilliant.

How to commit: the simplest version

"Saving" is actually broken up into 2 phases:

1. "add" the changes to the commit

2. "commit" the commit

Here are the 3 commands for when you’ve made changes and want to save:

• git status shows what changed (has nothing to do with the commit--but I always run this first to see what's changed).

• git add . stages everything you changed. (the "." means "all")

• git commit -m "message" seals the deal with a note.

Baby steps: set up once

If you haven't done it already, you MIGHT have to tell Git who you are.

git config --global user.name "Your Name" git config --global user.email "you@example.com"

And this entire blog post also assumes you have run git init inside of your project folder. This creates a fresh git repo 👍

Stage only what matters

Real pros don’t always add everything. They stage with intent.

• Stage a single file:

git add path/to/file.js

• Stage parts of a file (surgical precision):

git add -p

Write messages you won’t hate later

• Use the imperative mood: “add X”, “fix Y”, “refactor Z”.

• Keep subject under ~50 chars if you can.

• Add details after a blank line if needed.

You WILL thank yourself later for being clear & descriptive!

git commit -m "add new Header component to layout file"

Conventional Commits (optional but tidy)

Helpful for automated changelogs and clear intent.

• feat: new feature

• fix: bug fix

• docs: documentation only

• refactor: code change that isn’t a fix or feature

• chore: build tools or housekeeping

git commit -m "fix: handle null userId in auth middleware"

Amending when you forgot something

Oops. You can tack on a file or improve the message.

• Amend files and keep the same message:

git add missing-file.ts git commit --amend --no-edit

• Amend and change the message:

git commit --amend -m "feat: add checkout totals (with tax rounding)"

Commits vs pushes (don’t mix them up)

• Commit = save locally.

• Push = send commits to the remote repo (like GitHub, etc)

git push origin main

Granularity: how big should a commit be?

• Small enough to understand quickly.

• Focused on one purpose: fix a bug, add a feature, refactor a thing.

• Big refactors? Split by area or step.

Viewing your commits

Once you’ve committed, you’ll probably want to peek at your history. Git has simple tools for that:

• See full details of recent commits:

git log

• See a short, scannable list of commits:

git log --oneline

Use these to review what you did, track down bugs, or brag to your teammates about how much you’ve shipped.

Checking your work before committing

• See what changed:

git diff

• See what’s staged:

git diff --staged

Undoing without tears

• Unstage but keep changes:

git restore --staged path/to/file

• Revert a commit (make a new commit that undoes it):

git revert <commit-sha>

• Soft reset to keep changes but move HEAD back:

git reset --soft HEAD~1

Use reset carefully. Revert is safer on shared branches.

Batching common flows

For quick cycles, these are handy aliases or muscle-memory routines. (I have mine bound to a text expansion)!

• Stage file → commit:

git add . && git commit -m "message here"

• Stage interactively → commit with editor:

git add -p git commit

When you’re collaborating

• Pull before you push:

git pull --rebase origin main git push origin main

• Co-authors for pair sessions:

git commit -m "feat: add CSV export

Co-authored-by: Dev One 
Co-authored-by: Dev Two "

Speedrun: first commit in a brand-new repo

mkdir demo && cd demo git init echo "Hello, world!" > readme.md git add readme.md git commit -m "feat: initial commit" git branch -M main git remote add origin https://example.com/your/repo.git git push -u origin main

Frequently oops’d questions

• “I committed to the wrong branch.” Create a new branch from that commit and reset the old one.

• “My commit has secrets.” Rotate the secret, then rewrite history if necessary. Do not just delete the line.

• “The message is bad.” Use git commit --amend if not pushed. If pushed, use a follow-up commit with a clearer message.

Handy checklist before you commit

• Tests pass locally.

• No debug logs or stray prints.

• Message says what changed and why.

• Only related changes in this commit.

Mental model to keep forever

• Working tree: your current files.

• Index/staging: the stuff you’re proposing to commit.

• Repository: the history you’ve already committed.

Move changes from working tree → staging → repository with intent.

One-liners you’ll actually use

• Stage everything and commit fast:

git add . && git commit -m "message"

• Amend last commit message:

git commit --amend -m "docs: update README examples"

• See recent commits, short and sweet:

git log --oneline --graph --decorate -n 10

Wrap-up

A commit is a tiny story about your code. Make it focused. Make it clear. Make it often.

Future-you will send you a thank-you note. Probably in the form of fewer headaches.