GtGit · Lesson 2 of 8

The Core Loop: add & commit

Edit, stage, commit. You'll run these commands thousands of times. Understand the staging area and everything else in git makes sense.

Bash

echo "# My Project" > README.md

git status
# Untracked files: README.md   (git sees it, isn't tracking it)

git add README.md        # stage it
git status
# Changes to be committed: new file: README.md

git commit -m "Add README"
# [main (root-commit) a1b2c3d] Add README

git log --oneline        # view history
# a1b2c3d Add README

Why the staging area? It lets you commit some changes but not others. Fixed a bug and also tweaked some styling? Stage and commit the bug fix by itself, then commit the styling separately. Small, focused commits make history readable and problems easy to trace.

Bash

git add file1.js file2.js   # stage specific files
git add .                   # stage everything in current dir

git diff                    # what changed but is NOT staged
git diff --staged           # what IS staged for next commit

git restore file1.js        # discard unstaged edits (careful!)
git restore --staged file1.js  # unstage, keep the edits

✦ Tip
Write commit messages that finish the sentence 'This commit will…' — 'Add login form validation', 'Fix crash when cart is empty'. Six months from now, 'stuff' and 'wip' will tell you nothing.

Bash

# .gitignore — files git should never track:
# (create this file in the repo root)

node_modules/
*.log
.env
dist/

# Commit .gitignore itself so teammates share the rules.

⚠ Warning
Never commit secrets — API keys, passwords, .env files. Committed history is forever, and on a public repo bots scrape for leaked keys within minutes. Add secret files to .gitignore before the first commit.