Git & GitHub

Staging & Committing

3 min read
Focus: GIT
⚡

TL;DR — Quick Summary

  • Git uses a two-step save: stage (select changes) → commit (permanently record them).
  • Three areas: Working Directory → Staging Area → Repository.
  • Use git add <file> to stage and git commit -m "message" to commit.
  • Write commit messages in imperative mood: "Fix bug", not "Fixed bug" or "Fixing bug".

Lesson Overview

The Git Saving Process: Two Steps, Not One

In most applications, you save with Ctrl+S and everything is saved instantly. Git works differently — it uses a deliberate two-step process that gives you precise control over exactly what gets recorded in your history.

🗂️ The Three Areas of Git

To understand committing, you need to know about the three places your code can live:

  • Working Directory: Your actual project files on disk — where you make changes.
  • Staging Area (Index): A preparation zone where you select which changes will be included in the next commit. Think of it as a shopping basket before checkout.
  • Repository (.git): The permanent history of all committed snapshots.

📸 What is a Commit?

A commit is a permanent, immutable snapshot of your staged changes at a specific moment. Each commit contains:

  • A unique SHA-1 hash (e.g., a3f8c21) — its permanent ID
  • The author name and email
  • A timestamp
  • A commit message describing what changed
  • A reference to the parent commit (forming a chain of history)

Think of commits like entries in a captain's log — each one tells the story of what happened and when, forever.

✍️ Writing Good Commit Messages

A great commit message follows this format:

  • First line: Short summary, 50 characters max, written in imperative mood: "Add login form" not "Added login form"
  • Blank line
  • Optional body: Explain why the change was made, not what — the code shows what.

Conceptual Deep Dive

Here's a simple analogy: imagine you're packing a box to ship. Your working directory is your entire room — everything is just lying around. The staging area is the box you're packing — you carefully choose only what you want to ship. When you git commit, you tape the box shut, label it, and send it — it's now a permanent, trackable shipment in your history. This two-step process is powerful because you might edit 10 files while fixing two different bugs. Instead of committing all of them together in a messy lump, you can stage and commit the files related to Bug Fix #1 first, then stage and commit the files for Bug Fix #2 separately. Your history stays clean and logical.

Implementation Lab

The Complete Staging & Committing Workflow
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# See what's changed in your working directory
git status
# Output shows:
# - 'Changes not staged for commit'for commit' = modified but not staged
# - 'Untracked files' = new files Git doesn't know about yet
 
# Stage a specific file
git add index.html
 
# Stage multiple specific files
git add src/app.js src/styles.css
 
# Stage ALL changes in the entire project
git add .
 
# See exactly WHAT is staged (a line-by-line diff)
git diff --staged
 
# Commit everything that's staged with a message
git commit -m "Add homepage layout and base styles"
 
# Shortcut: stage all TRACKED files AND commit in one command
git commit -am "Fix typo in navigation link"
# Note: -a does NOT stage brand new (untracked) files
Staging Parts of a File (Patch Mode)
1
2
3
4
5
6
7
8
9
10
11
12
# You edited one file but made two unrelated changes.
# Stage only specific chunks (hunks) of a file:
git add -p src/app.js
 
# Git will show you each block of changes and ask:
# y = yes, stage this chunk
# n = no, skip this chunk
# s = split this chunk into smaller pieces
# e = manually edit which lines to stage
# q = quit without staging more
 
# This lets you make TWO clean commits from ONE messy file edit.
Fixing Your Last Commit
1
2
3
4
5
6
7
8
9
10
# Oops — you forgot to add a file to your last commit
git add forgotten-file.js
git commit --amend --no-edit
# '--no-edit' keeps the same commit message
 
# Or change the commit message of the last commit
git commit --amend -m "Better commit message"
 
# WARNING: Only amend commits that have NOT been pushed to a shared remote.
# Amending rewrites history — it gives the commit a new SHA hash.

Pro Tips — Senior Dev Insights

1

Use git log --oneline to see a compact view of recent commits — your messages will either make you proud or embarrassed.

2

Add a .gitignore file at the very start of every project to prevent accidental commits of node_modules, .DS_Store, .env, and build artifacts.

3

Use git stash to temporarily shelve work-in-progress changes when you need to quickly switch tasks without committing.

4

Conventional Commits (feat:, fix:, docs:, refactor:) is a popular commit message standard used by large open-source projects — worth adopting.

Common Developer Pitfalls

!
Using git add . without checking git status first — you might commit node_modules, .env secrets, or auto-generated files.
!
Writing useless commit messages like "fix", "update", or "wip" — future you (and teammates) will hate present you.
!

Treating commits like saves in a Word doc — committing too rarely with massive changes, making history impossible to review.

!
Using git commit --amend on commits that have already been pushed to a shared branch — this rewrites history and causes problems for teammates.

Interview Mastery

The working directory is where you actively edit files. The staging area (index) is an intermediate zone where you prepare specific changes for your next commit — like a draft. The repository is the permanent committed history stored in .git. Changes flow: working directory → (git add) → staging area → (git commit) → repository.

The staging area enables atomic, logical commits. In real development you often work on multiple things simultaneously. The staging area lets you select exactly which changes belong together in one commit, keeping history clean and meaningful. Without it, every commit would be a dump of everything you happened to have changed.

git commit -am stages all modifications to already-tracked files and commits them in one step. You should NOT use it when: (1) you have new untracked files you want to include — -a ignores those, (2) you want to commit only a subset of changes, or (3) you want to review what you're committing with git diff --staged first.

Real-World Blueprint

At a startup, you spend the day working on a new feature. By evening, you've edited 8 files — 5 for the feature itself, 2 for a related bug fix you noticed, and 1 where you fixed a typo. Instead of one giant messy commit, you use git add -p to stage the bug fix files, commit those, then stage the feature files and commit those separately, and finally commit the typo fix. Your git history is clean, reviewable, and tells a clear story.

Hands-on Lab Exercises

1
Create 3 new files in a repo. Stage only 2 of them and commit. Then check git status to see the unstaged file.
2
Edit an existing file in two different sections. Use git add -p to stage only one section and commit it separately.
3
Make a commit with a typo in the message. Use git commit --amend to fix it before pushing.
4
Use git diff vs git diff --staged on the same repo and explain the difference you see.

Real-World Practice Scenarios

You ran git add . but then realized you accidentally staged your .env file with real passwords. How do you unstage it without losing your changes?

You've been coding for 4 hours and have 12 modified files across 3 different features. How do you split this into clean, separate commits?

A colleague's pull request has one commit with the message 'stuff'. How do you explain why this is a problem and what better practice looks like?

You committed and then immediately realized you forgot to add one small file to that commit. What's the safest way to fix this?