How to Use Git: The Commands You Actually Need

The four places

1. 1Working directory — the real files on disk, the ones your editor has open. You change things here; Git notices but does nothing on its own.
2. 2Staging area (also called the index) — a holding pen for the exact changes you want in your next commit. Nothing arrives here by accident.
3. 3Local repository — the permanent history on your machine, in the hidden .git folder. Once a change is committed here, it is genuinely hard to lose.
4. 4Remote — a copy of the repository on another machine, usually GitHub, nicknamed origin. Nothing you commit exists there until you push.

The loop

1. 1git status — see which files changed and which are staged. Run it before and after everything else; it prevents most mistakes.
2. 2git add src/login.js — stage one specific file. Or git add . for everything below the current directory, which is convenient and occasionally regrettable.
3. 3git commit -m "Fix redirect loop on expired session" — snapshot what is staged. Leave off -m and Git opens your editor.
4. 4git pull — bring down anything teammates pushed since you last looked. Doing this first avoids most rejected-push errors.
5. 5git push — send new commits to the remote. On a new branch, run git push -u origin branch-name once; plain git push works after that.

Cache the user's timezone on the session object

We looked the timezone up on every render, adding ~40ms per
request. It never changes mid-session, so resolve it at login.

Fixes #412.

A commit message that earns its keep

# Secrets — never commit these
.env
.env.local
*.pem

# Dependencies (reinstallable from a lockfile)
node_modules/
venv/
__pycache__/

# Build output
dist/
build/

# Editor and OS noise
.DS_Store
.idea/

.gitignore — a reasonable starting point

Situation, then command

1. 1You edited a file and want the last committed version back: git restore src/login.js. Your edits are gone for good — Git never had a copy.
2. 2You staged something you did not mean to: git restore --staged src/login.js. That leaves your edits alone.
3. 3Your last commit has a typo, or you forgot a file: stage the file, then git commit --amend. This rewrites the commit, so only do it before pushing.
4. 4You pushed a commit that was wrong: git revert a1b2c3d. That makes a NEW commit undoing the old one, safe on a shared branch because it rewrites nothing.
5. 5You want to move the branch pointer backwards: git reset, in one of the three flavors below.

function getTimeout() {
<<<<<<< HEAD
  return 30;
=======
  return 60;
>>>>>>> fix-login-redirect
}

What Git writes into a conflicted file

Finishing the merge

1. 1Run git status. It lists every conflicted file under "Unmerged paths" so you never guess which need attention.
2. 2Edit each one into the correct final state — sometimes one side, sometimes a combination neither branch had.
3. 3Delete all three marker lines. A surviving marker means code that will not run, and it is the most common way this goes wrong.
4. 4Stage the resolved file with git add — that is how you tell Git the conflict is settled.
5. 5Run git commit. Git has already written a merge message, so you can usually accept it as-is.
6. 6If you would rather not merge at all, git merge --abort puts everything back as it was.

Symptom, cause, fix

1. 1"Updates were rejected because the remote contains work that you do not have locally." Someone pushed before you. Run git pull, resolve conflicts, push again.
2. 2"Please tell me who you are." No identity configured. Run git config --global user.name and git config --global user.email once per machine.
3. 3You committed to main when you meant to be on a branch, and have not pushed. Run git switch -c my-branch to bring the commit with you, then reset main back to origin/main.
4. 4node_modules is in every commit. It was tracked before .gitignore existed. Add the pattern, run git rm -r --cached node_modules, then commit.
5. 5You cannot find a commit you know you made. Run git reflog — it records every position HEAD has held, then branch off that hash.
6. 6git push asks for a username and password every time. Your remote uses HTTPS; switching to SSH removes the prompt.

• You can name all four places a change can live, and which command moves work between any two.
• git status output makes sense without reading it twice.
• You have made a commit whose message would still be useful in six months.
• You created a branch with git switch -c, committed on it, merged it into main, and deleted it.
• Your repository has a .gitignore, and git status shows no editor or dependency folders.
• You have used git restore, git restore --staged, and git commit --amend at least once each.
• You can explain why git revert is safe on a shared branch and git reset --hard is not.
• You have resolved one merge conflict end to end, markers deleted, merge committed.