Introduction

Almost every Git session follows the same three-step rhythm: edit files in your working tree, stage the changes you want to record, and commit them to history. Mastering this loop is the foundation of everything else.

The three areas

• Working tree: files on disk you edit with your editor.
• Index (also called the staging area): a snapshot of what will go into the next commit.
• Repository: the committed history stored in .git.

A complete cycle

1. Edit a file in your editor.
2. Run git status to see what changed.
3. Run git diff to inspect the changes.
4. Stage with git add.
5. Commit with git commit.

echo "hello" >> notes.txt
git status
git diff
git add notes.txt
git diff --staged
git commit -m "Add greeting to notes"

Staging selectively

You can stage individual files, glob patterns, or even parts of a file using interactive mode:

git add notes.txt readme.md
git add "src/*.py"
git add -p notes.txt    # patch mode: yes/no per hunk

Patch mode is invaluable when you have mixed changes you want to split into separate commits.

Skipping the index

The shortcut git commit -a stages and commits all tracked files in one step. It does not add new (untracked) files:

git commit -am "Quick fix"

Writing good commits

A commit message has a short subject line (50 characters or so) and an optional body explaining the why. Run git commit without -m to open your editor:

git commit
# editor opens
# Subject line
#
# Longer explanation...

Atomic commits

A good commit captures one logical change. Build it deliberately: stage exactly the hunks that belong together with git add -p, then commit. If you find yourself describing a commit with "and" in the subject ("Fix login and refactor logger"), it should probably be two commits.

git add -p src/auth.py        # stage just the login fix
git commit -m "Fix login redirect on expired session"
git add -p src/logger.py
git commit -m "Refactor logger to use structured fields"

Atomic commits make git bisect, git revert, and code review dramatically easier later.

Common mistakes

Forgetting to git add new files and being surprised by an "empty" commit. git status always tells you the truth; read it before committing. Another trap: using git commit -am when you have new untracked files, which silently leaves them behind. Finally, committing generated files (build output, node_modules, IDE settings) clutters history and slows clones; add them to .gitignore before staging. When in doubt, run git diff --staged to see exactly what your next commit will contain.