Git basics: git init, git add, git commit — CS50 Web Programming

"First rule of Git: if it’s not committed, it didn’t happen."

You already know how the web works from Orientation, and you've set up virtual environments and used pip to manage packages. Great. Now we put those files under version control so your project history doesn't end up like a mystery novel where modules vanish and nobody knows why.

Why this matters (briefly and dramatically)

• Reproducibility: Commit the code that creates your site so you (and your future self) can rebuild it later.
• Safety: If you break something, commits are your time machine.
• Collaboration: Others can see changes, review, and contribute.

You've already been told to create requirements.txt and a virtual environment. Do not commit the virtual environment directory. We'll show how to initialize a repository correctly while respecting that.

The three musketeers: init, add, commit

Think of Git like a camera. You edit your files (working directory), you choose which parts you want to photograph (the staging area / index), and then you take the photo (a commit). The snapshot gets stored in the repository (.git).

1) git init — start the repo

What it does: creates a .git folder that holds Git’s database and configuration.

Commands:

# In your project folder
git init

Micro explanation: This does not upload anything anywhere. It simply creates the local repository. Think: "I declare this folder worthy of version control." The folder becomes a Git repo but currently empty (no commits yet).

2) git add — stage your changes

What it does: moves file changes from working directory to the staging area. You choose what will be in the next snapshot.

Common usages:

# Stage a single file
git add app.py

# Stage all changed and new files (but not deleted files in older Git versions)
git add .

# Stage everything, including deletions
git add -A

Micro explanation: Staging is your chance to curate. Made a tiny fix in one file and a massive experiment in another? Stage only the tiny fix to keep the commit focused.

3) git commit — save the snapshot

What it does: creates a commit object from the staged changes, with metadata (author, date, message) and a pointer to parent commit(s).

Commands:

git commit -m "Add home page layout and base CSS"

# If you forget -m, Git opens an editor for a longer message
# To amend the last commit (e.g., fix a typo in the message or include a file you forgot):
git commit --amend

Micro explanation: Commits are atomic, descriptive units of change. Aim for short, meaningful commits that do one thing well.

Workflow example: from zero to first commit

1. Create project folder and virtual environment (you've done this in the Virtual Environments topic).
2. Create .gitignore to exclude venv/, __pycache__/, etc.
3. git init
4. git add .gitignore
5. git add requirements.txt app.py templates/
6. git commit -m "Initial project scaffold: venv ignored, requirements listed, base files"

Commands in sequence:

# Create repo
git init

# Create .gitignore (example below)
cat > .gitignore <<EOF
venv/
__pycache__/
*.pyc
.env
node_modules/
EOF

# Stage and commit
git add .gitignore requirements.txt app.py templates/
git commit -m "Initial scaffold: add requirements and base files"

Sample .gitignore (especially relevant after virtualenvs & pip)

# Python
venv/
__pycache__/
*.pyc

# Environment variables and secrets
.env

# Node dependencies (if you also use npm)
node_modules/

# OS files
.DS_Store

# Editor folders
.vscode/
.idea/

Why: Your virtual environment (venv) contains installed packages. Those are reproducible from requirements.txt and huge. Commit the requirements, not the binaries.

Good commit message practice (TL;DR + style)

• Use a short summary (50 characters-ish) then a blank line and an optional body.
• Start with a verb in present tense: "Add", "Fix", "Remove".
• Keep commits focused: one logical change per commit.

Example:

Add login form and validation

Add a simple login form with client-side validation and
server-side checks. This commit also adds tests for empty
username/password handling.

Why present tense? Git logs read like a changelog: "Add login form" sounds like an action performed.

Quick troubleshooting & tips

• Forgot to configure your name/email? Set once globally:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

• Want to see what's staged vs unstaged?

git status
git diff          # unstaged changes
git diff --staged # staged changes

• Made a mistake in staging? Unstage with:

git reset HEAD <file>

• Want to remove a file from the repo (and keep it locally)? Use:

git rm --cached filename

Closing: the tiny checklist before you commit

• Is the change small and focused?
• Is the virtual environment excluded from commits? (.gitignore)
• Did you add a helpful commit message with a verb?
• Did you run tests or a quick smoke test?

"This is the moment where the concept finally clicks: staged ≠ saved until you commit."

Git init/add/commit is the bread-and-butter of working safely. You already know how the web is requested and served, and you already isolate environments with venv and pip. Now make your code history as tidy and reversible as those good habits. Commit early, commit often, and when in doubt—commit with a clear message.

Key takeaways

• git init creates a local repository (.git).
• git add stages changes to be included in the next commit.
• git commit records the staged snapshot as a new revision with a message.
• Use .gitignore to avoid committing virtual environments and other big or sensitive files.

Happy committing. May your commit history be readable and your rollbacks painless.