Staging and Commits — The Magic Middle of Git (CS50)

You already learned how to git init and git clone. Now let’s make your changes meaningful.

If Git were a kitchen, cloning a repo is bringing home groceries. Staging is the clean countertop where you arrange ingredients. Committing is cooking the dish and putting it in the fridge with a label. Skip staging and you end up throwing everything in the fridge and wondering why your soup tastes like 17 different ideas.

---

What this is and why it matters

Staging (the index) is a temporary area where you prepare a snapshot of changes you want in the next commit. A commit is a recorded snapshot in the project history (a permanent save point). The staging step gives you fine-grained control — you choose exactly what becomes part of the commit.

Why care?

• Makes commits atomic: one purpose, one commit. Easier to review and revert. (Hello, code reviews.)
• Lets you craft clean histories that make estimating, debugging, and planning way easier.
• Avoids accidental check-ins of experimental or secret stuff you meant to keep local.

This builds on what you learned in Git Init and Clone: now that you have the repo locally, staging + commits let you shape the history that others will pull and review.

---

The three-state model (quick refresher)

1. Working Directory — files you edit.
2. Staging Area (Index) — files you mark for the next commit.
3. Repository (HEAD) — committed snapshots.

Micro explanation: when you run git add, you move changes from the working directory to the staging area. git commit moves staged changes from the index into the repository history.

---

Common commands and small examples

Basic flow

# see what's changed
git status

# stage a file
git add README.md

# stage multiple
git add src/*.py

# commit staged changes with message
git commit -m "Implement login validation"

# quick log
git log --oneline --graph --decorate

Partial staging (the superhero move)

Sometimes you edit a file and want to commit only part of the changes. Use:

git add -p file.py   # interactively choose hunks

This is how you keep commits atomic — fix a typo and add a new feature in separate commits even if they touch the same file.

Unstage without losing edits

git reset HEAD file.py   # moves file from staged back to working (keeps edits)

Amend a commit (be careful!)

git commit --amend -m "Fix commit message or add missed changes"

Use this only for local commits that haven’t been pushed/shared. Rewriting history after pushing makes life harder for collaborators.

---

Good commit message style (the social contract)

A commit message is not a diary entry. It’s a communication tool for your future self and teammates.

• First line: ~50 characters summary.
• Blank line.
• Body: explain the why, not just the what. Wrap at ~72 characters.

Example:

Short: implement rate limiting for login attempts

Longer: Add middleware that tracks failed login attempts per IP
and enforces a 5-minute cooldown after 5 failures. This reduces
brute force risk and matches the security plan from sprint planning.

Good commit messages make code reviews faster and estimating more accurate — you can tell how big a change is from the history without opening every file.

---

Best practices (battle-tested)

• Commit early, commit often — when a logical step is done.
• Make commits atomic: one logical change per commit.
• Use git add -p to avoid mixing unrelated changes.
• Run tests/lint before committing. Consider pre-commit hooks for automation.
• Don’t commit secrets or large generated files; add them to .gitignore.
• Keep local amend/rebases for clean history, but once pushed, prefer new commits.

Why this matters for teams: small, clear commits make code reviews faster and more effective. They also let you revert a single behavior without undoing unrelated fixes — hugely helpful during production incidents and when following the processes you set during estimating and planning.

---

A short workflow example (feature branch)

1. Create branch: git checkout -b feature/login-rate-limit
2. Implement small piece A. git add -p -> git commit -m "Add rate limiter middleware (core)"
3. Implement small piece B. git add config/*.yml -> git commit -m "Add config values for rate limit"
4. Run tests and linters.
5. Push branch: git push -u origin feature/login-rate-limit
6. Open PR for code review.

When reviewers ask for a change, make a focused commit addressing it. This keeps the review thread legible and traceable.

---

Pitfalls people fall into (and how to stop)

• Committing everything at once: hard to review, hard to revert. Use staging to split changes.
• Messy messages: write a clear summary and why it matters.
• Amending pushed commits: breaks teammates’ clones. If pushed, add a fix commit instead.

Why do people keep misunderstanding this? Because modern editors make it easy to edit many files at once. Staging forces discipline: you must choose what to commit.

---

When to rewrite history vs when not to

• Rewriting (amend, rebase -i): great for local cleanup before pushing.
• Don’t rewrite commits that have been pushed and shared — that makes others’ history diverge.

If you ever must rewrite public history, coordinate with teammates and prefer revert for changes already merged into shared branches.

---

Quick checklist before opening a PR

• Commits are small and focused
• Messages explain why, not just what
• Tests pass locally
• No sensitive data committed
• Branch name matches ticket/plan

This checklist ties staging/commits into your code review and planning practices.

---

Key takeaways

• The staging area is your prep station; use it to create meaningful commits.
• Commit messages are team communication — be concise and explain the why.
• Use partial staging when you need to split changes in one file into multiple commits.
• Rewrite local history if needed, but avoid rewriting shared history.
• Good staging and commit habits make code reviews faster, planning more accurate, and debugging far less painful.

"A well-crafted commit history is like good documentation — it saves time, grief, and occasional existential dread."

If you want a quick exercise: make three unrelated edits in one file, then practice using git add -p to split them into three commits. Open a PR and watch how reviewers bless your tidy history.

---

Happy committing. Treat your commits like little promises to the future — keep them honest.