Lesson: Status, Add, Commit, Log

What you'll learn

The everyday loop every developer repeats dozens of times a day: edit → status → add → commit.
How to read git status and git diff to see exactly what changed.
How to write commit messages that your future self and teammates will thank you for.
How to keep junk out of your repo with a .gitignore file.
How to safely undo mistakes with git restore and the basics of git reset.

By the end you will be able to record clean, well-described history in your own repo without fear.

The lesson

This lesson assumes you have a repo from the previous lesson (git init done, identity set). All commands below run inside that repo on your lab VM.

1. The everyday loop

Almost all daily Git work is one short cycle:

  edit a file  ─>  git status  ─>  git add  ─>  git commit  ─>  (repeat)
                       │
                       └─ git diff  (see exactly what changed before staging)

Let's walk through it with a real example. Create a script:

echo '#!/bin/bash' > hello.sh
echo 'echo "hello lab"' >> hello.sh

2. `git status` — your constant companion

git status tells you the state of your three areas. Run it now:

git status

You will see hello.sh listed under Untracked files — Git sees it but is not yet recording it. Get into the habit of running git status before and after every action. It is impossible to use too often.

3. `git add` — stage what you want to save

Staging marks a change for the next commit. Stage the file:

git add hello.sh
git status        # hello.sh now shows under "Changes to be committed"

Useful forms:

git add file1 file2     # stage specific files
git add .                # stage everything new/changed in the current folder

Prefer naming files over git add . until you are comfortable, so you never stage something by accident.

4. `git diff` — see the actual changes

git diff shows changes you have not staged yet. git diff --staged shows what you have staged (i.e., what your next commit will contain). Try editing the file, then:

echo 'echo "goodbye"' >> hello.sh
git diff             # shows the new line you just added (unstaged)
git diff --staged    # shows what is already staged

Lines starting with + are additions; - are removals. Always diff before you commit so you know exactly what you are saving.

5. `git commit` — save a snapshot

Commit everything currently staged:

git commit -m "Add hello.sh script"

The -m flag supplies the message inline. Without it, Git opens your editor so you can write a longer message. After committing, git status shows a clean working tree — nothing left to save.

A common shortcut once files are already tracked is git commit -am "msg", which stages all modified tracked files and commits in one step. Note: it does not pick up brand-new (untracked) files, so you still need git add for those.

6. Writing good commit messages

A commit message explains why a change exists. The widely used convention:

First line: a short summary, ~50 characters, in the imperative mood ("Add", "Fix", "Remove" — as if completing "This commit will…").
Then a blank line, then optional detail explaining the reasoning.

Fix backup script failing on empty directories

The find command returned a non-zero exit when no files matched,
which aborted the script. Added a guard for the empty case.

Good: Add log-rotation to backup script. Bad: stuff, fix, asdf, final changes. Your history is documentation — write it for the next person.

7. `.gitignore` — keep junk out

Some files should never be committed: logs, temporary files, secrets, editor backups, build output. List patterns in a file named .gitignore at the repo root:

cat > .gitignore <<'EOF'
*.log
*.tmp
.env
EOF
git add .gitignore
git commit -m "Add .gitignore for logs, temp files, and secrets"

Now Git stops nagging you about those files and you cannot stage them by accident. Never commit passwords or tokens — that is exactly what .env and similar patterns protect against.

8. `git log` — read your history

View the chain of commits:

git log                  # full history, newest first
git log --oneline        # one compact line per commit
git log --oneline --graph --all   # a visual tree (great once you have branches)

--oneline is the one you will use most:

a1b2c3d Add .gitignore for logs, temp files, and secrets
e4f5g6h Add hello.sh script

Each line shows the short hash and the summary. Press q to quit the log viewer.

9. Undoing mistakes safely

Things go wrong; Git makes most of it reversible.

Discard unstaged edits to a file (throw away changes since the last commit):

git restore hello.sh

Unstage a file (keep your edits, just remove it from the staging area):

git restore --staged hello.sh

Undo the last commit but keep the changes (commit too early? wrong message?):

git reset --soft HEAD~1     # moves HEAD back one commit; your changes stay staged

HEAD~1 means "one commit before HEAD." Be careful with git reset --hard, which discards changes permanently — only use it when you are certain you want the edits gone. Until you have pushed work to a remote, your safest habit is: commit often, and prefer restore and --soft reset.

That is the complete everyday workflow. Edit, status, diff, add, commit, log — over and over. Master this loop and the rest of Git is variations on a theme.

Dig deeper

Search terms

git add commit workflow tutorial
how to write good git commit messages
git diff staged vs unstaged
git restore vs git reset explained
gitignore file examples

Check yourself

What is the difference between git diff and git diff --staged?
Why run git status so frequently? What does it tell you?
Write a good commit message for a change that fixes a typo in a script's help text.
What belongs in .gitignore, and why must secrets never be committed?
You committed too early. Which command moves the commit back but keeps your changes? Which command would instead destroy them?