Date-stamped: March 2026. git itself is very stable, but workflows around it change. GitHub, GitLab, and other hosts add features regularly. The core commands here will not change — the workflows around them might.
Cross-platform: git works identically on macOS (zsh), Windows (Git Bash), and Linux (bash). It is pre-installed on most macOS and Linux systems. On Windows, installing Git for Windows gives you both git and Git Bash.
The Basics
These are the commands I use every single day. They form a cycle: check status, stage changes, commit, push, review history.
git status
What changed? What is staged? What is not tracked? I run this before every other git command. Prof. Teeters calls it "looking before you leap."
git statusgit add
Stage files for the next commit. I prefer adding specific files by name rather than git add . — that way I know exactly what is going in.
git add index.html # stage one file
git add src/styles/main.css # stage another
git add . # stage everything (use carefully)git commit -m
Save a snapshot with a message describing what changed and why.
git commit -m "Add navigation component to header"Prof. Teeters told me: "Write the message for the person who reads it six months from now — that person might be you."
git push
Send your commits to the remote repository.
git push # push to tracked branch
git push -u origin main # first push, set upstreamgit log --oneline
See recent history — one line per commit. Quick way to confirm your commit landed.
git log --oneline# Example output:
# a1b2c3d Add navigation component to header
# e4f5g6h Initial project setup
# h7i8j9k Initialize repositoryBranching
Branches let you work on features without touching the main code. I think of them as parallel timelines — you can always switch back.
git branch
List branches or create a new one.
git branch # list all local branches
git branch feature-nav # create a new branchgit checkout -b
Create a new branch and switch to it in one step. This is the one I use most.
git checkout -b feature-nav # create + switchgit merge
Bring changes from one branch into another. Switch to the target branch first.
git checkout main # switch to main
git merge feature-nav # merge feature into mainDangerous Flags
Grace was very clear about these. These flags bypass safety mechanisms. They do not ask for confirmation. They do not warn you. They execute immediately and the damage can be permanent. Know them. Respect them. Read the command before you approve it.
--force
Rewrites remote history. If a teammate pushed commits after your last pull, --force destroys their work. No confirmation dialog. No undo button on the remote.
# DANGEROUS — rewrites remote history
git push --force
# Safer alternative — fails if remote has new commits
git push --force-with-leaseGrace said: "Force-push is not collaboration. It is overwriting." If you must force-push, use --force-with-lease — it checks that the remote has not changed since your last fetch.
-D
Force-delete a branch even if it has unmerged changes. Lowercase -d is safe — it refuses to delete unmerged branches. Uppercase -D does not care.
git branch -d feature-nav # safe — refuses if unmerged
git branch -D feature-nav # DANGEROUS — deletes regardless--hard
Discards all uncommitted changes permanently. Staged work, unstaged edits — all gone. No recovery from the working directory.
# DANGEROUS — destroys uncommitted work
git reset --hard
# Safer — unstages but keeps your changes
git reset --soft HEAD~1The Read-Before-Approve Rule
This is from Station 6, and it changed how I work. When an AI agent suggests a terminal command, or when a script runs a destructive operation — read the full command before you approve it.
The terminal does not ask twice
There is no "Are you sure?" for most destructive commands. --force does not pause. --hard does not confirm. rm -rf does not warn. The command runs the moment you press Enter or click Approve.
Read every flag
A command might look familiar, but one extra flag changes everything. git push is safe. git push --force is not. The difference is one flag. Read it. Understand it. Then decide.
Informed approval
When an AI agent proposes a command, it is not enough to trust the agent. You need to understand the command yourself. Prof. Teeters taught me: "Approval without understanding is not approval — it is abdication."
Recovery Basics
Things go wrong. These two commands have saved me more than once.
git reflog
Your safety net. Even after a bad reset or a deleted branch, git keeps a log of where HEAD has been. You can find lost commits here.
git reflog# Example output:
# a1b2c3d HEAD@{0}: reset: moving to HEAD~3
# e4f5g6h HEAD@{1}: commit: Add navigation component
# h7i8j9k HEAD@{2}: commit: Initial setupFound the commit you lost? Restore it:
git checkout e4f5g6h # jump to that commit
git checkout -b recovery # save it on a new branchgit stash
Save your uncommitted work temporarily. Useful when you need to switch branches but are not ready to commit.
git stash # save current changes
git stash list # see all stashes
git stash pop # restore most recent stash
git stash drop # discard most recent stashGrace's Rules
Grace does not repeat herself. She gave me three rules. I wrote them down.
Always git status before destructive commands
Before any reset, force-push, or branch deletion — check what state you are in. Know what you are about to affect.
Always check pwd
Running git commands in the wrong directory is a common mistake. Confirm you are in the right repository before you commit, push, or reset.
Read the diff before you push
Review what you are sending to the remote. git diff shows unstaged changes. git diff --staged shows what is about to be committed. No surprises.
git diff # unstaged changes
git diff --staged # staged changes (about to commit)