Staging, Diffs, History and .gitignore

Looking before you commit

Professionals never commit blindly. Before every commit they check what exactly is about to be saved. Git gives you two views, and the difference between them is the staging area.

Try it. This project already has a history and an unstaged change. Run git status and then git diff, then stage the file with git add menu.txt and run git diff again. It prints nothing now, because everything is staged. Run git diff --staged and the change appears there.

Reading a diff takes a minute to learn: a line starting with + was added, a line starting with - was removed, and an unchanged line starts with a space. A changed line shows as a removal followed by an addition.

One commit, one idea

The staging area exists so you can commit in logical pieces. Say you spend an hour and end up with three changes: you fixed a typo in the menu, added a contact page, and updated the opening hours. Those are three ideas, so make three commits, each with its own message.

git add menu.txt
git commit -m "Fix typo in the jollof rice price"

git add contact.txt
git commit -m "Add contact page"

git add hours.txt
git commit -m "Update opening hours for December"

Why this matters:

• Easy to understand. A reviewer reads one small change at a time.
• Easy to undo. If the contact page causes a bug, you undo that one commit and keep the others (lesson 4).
• A useful history. In six months, git log actually tells you what happened.

A commit that says "lots of changes" and touches twenty files is a warning sign.

Writing messages a team will thank you for

A commit message is a note to your future self and your teammates. A good one is short and says what the commit does.

1. Start with a verb, in the imperative: "Add login page", not "Added login page" or "Adding". Read it as "This commit will... add login page."
2. Keep the first line under about 60 characters.
3. Say what changed and, when it is not obvious, why.
4. Do not end with a full stop. It is a title, not a sentence.

Many teams also use Conventional Commits, which add a short type at the start so that history is easy to scan and tools can read it: feat: add dark mode, fix: correct VAT rounding, docs: update README, chore: tidy file names. You do not have to use it, but you will see it everywhere.

Exploring history

Your history is a story. These commands let you read it.

git log --oneline         # one line per commit
git log -3                # only the last three
git show                  # the last commit, with its changes
git show HEAD~1           # the commit before the last one
git show a3f9c21          # any commit, by its ID

HEAD means "the commit you are on now". HEAD~1 is its parent, HEAD~2 its grandparent. You will use these to compare, undo and restore.

Try them on this project.

Run git log --oneline, then git show (the newest commit), then git show HEAD~2. Notice how git show prints the message and the exact change.

.gitignore: files Git should leave alone

Not every file belongs in a repository. These should never be committed:

• Secrets: passwords, API keys, .env files. Anyone who can see the repository can see them, forever.
• Generated files: __pycache__/, node_modules/, build outputs. They can be recreated.
• Junk: log files, temporary files, .DS_Store, your editor's settings.
• Huge files: big datasets and videos slow everything down.

You tell Git to ignore them with a file called .gitignore, one pattern per line:

# Secrets
.env

# Python
__pycache__/
*.pyc

# Logs and temporary files
*.log
*.tmp

# Operating system
.DS_Store

Once a file is ignored, git status stops listing it, and git add . skips it. Commit the .gitignore file itself, so everyone on the team ignores the same things.

Try it

Set up .gitignore for a project that has a secret file and a log file in it.

Now practise one idea per commit. Two files have changed, and they are unrelated. Commit them separately.