Git Basics | HALRAD Research

A plain-English working overview of Git: where your changes live, how the everyday loop runs, what branches really are, how to undo things by intent, the difference between merge and rebase, and a few habits that keep day-to-day work calm.

The three areas

Every file you change lives in one of three places at a time:

[ working dir ] → git add → [ staging area ] → git commit → [ local repo ] ↓ git push [ remote repo ]

Working directory — what you actually see in your editor. Edits live here until staged.
Staging area (the "index") — the next commit's draft. You hand-pick which changes belong in the next commit by adding them here.
Local repo — your .git/ directory. History, branches, all committed snapshots. Lives entirely on your disk; doesn't need internet.
Remote repo — origin (GitHub, Azure DevOps, etc.). Where your team's shared copy lives.

The everyday loop

git status # what's changed, what's staged, what branch git diff # see unstaged changes line by line git diff --staged # see what you've already added git add <file> # stage one file (or `git add -A` for everything) git commit -m "message" # snapshot the staged changes git push # send commits to remote git pull # get others' commits from remote

That's 80% of git usage right there.

Branches — what they actually are

A branch is just a named pointer to a commit. Creating one is cheap and instant. There's no copying of files. main is the convention for the trunk; everything else branches off it.

git branch # list local branches; * marks current git branch feature-x # create a branch from current commit git switch feature-x # move to it (older syntax: git checkout) git switch -c feature-x # create + switch in one step git branch -d feature-x # delete (must be merged; -D forces)

Typical feature flow

git switch main
git pull — start from latest
git switch -c add-volume-rocker — new branch
… edit, test, edit, test …
git add -A && git commit -m "fix: rocker" — commit often
… more work, more commits …
git switch main && git pull — main may have moved
git switch add-volume-rocker
git rebase main — replay your work on top of new main
git push -u origin add-volume-rocker — publish branch
open PR / merge request on the host
PR gets merged → branch deleted → return to step 1

Step 3 keeps work isolated. Step 5 saves your state — commit often, you're saving snapshots, not publishing them. Step 9 keeps history linear and avoids ugly merge commits in your PR.

Reading history

git log # full history, newest first git log --oneline # one line per commit (sha + message) git log --oneline -10 # last 10 git log --all --graph --oneline # ASCII tree of all branches git show <sha> # what changed in that commit git blame <file> # who-touched-each-line

Undoing things — by intent

"I edited the file but want it back to last commit"

git restore <file> # discard unstaged changes

"I staged something I didn't mean to"

git restore --staged <file> # unstage; edits stay in working dir

"I committed too early, want to amend the last commit"

git add <missed-file> git commit --amend # only for commits NOT YET PUSHED

"I committed something broken, want to undo but keep the work"

git reset --soft HEAD~1 # uncommit; keep changes staged git reset HEAD~1 # uncommit; keep changes unstaged

"I want to wipe a commit completely"

git reset --hard HEAD~1 # destructive — loses uncommitted work

"It's already pushed; I need to undo it without rewriting history"

git revert <sha> # creates a new commit that undoes it

Rule of thumb: revert for shared history, reset for local-only.

Merge vs rebase

git merge feature on main → preserves the fork visually; creates a merge commit.
git rebase main on feature → replays your commits on top of latest main; linear history.

Both end with the same files; they differ in what the history graph shows.

Pictured:

Before: main A — B — C \ feature D — E After `git rebase main` (run on feature): main A — B — C \ feature D' — E'

D' and E' are new commits with the same patch content as D/E but new SHAs, because their parent changed. The originals get garbage-collected eventually.

When to use which:

Merge — preserves true history, shows when work diverged and rejoined. Required when others have based work on your commits.
Rebase — produces clean linear history. Good for keeping a personal feature branch up to date with main before opening a PR, or for squashing a messy commit series into one tidy patch.

Interactive rebase (git rebase -i) lets you edit the replay list — squash multiple commits into one, reorder them, reword messages, drop a bad commit entirely. Powerful for tidying a branch before sharing.

Golden rule: never rebase commits that exist on a remote branch others might be using. Rewriting shared history breaks their clones. Your own private branch — rebase freely. Pushed and shared — merge instead.

Remote operations

git remote -v # list configured remotes git fetch # download remote state, don't merge git pull # fetch + merge (or rebase) into current branch git push # send current branch git push -u origin <branch> # first push of a new branch (sets upstream) git push --force-with-lease # safely rewrite remote history (rarely)

fetch is read-only — it never changes your files. pull = fetch + integrate. Run fetch first when you want to inspect what's incoming without committing to merging it.

Working with others — the rhythm

Pull before you push. Always. If you push and someone else pushed first, your push gets rejected. Pull, resolve, push.
Commit small, commit often. Each commit should do one thing. "Add foo, fix bar, rename baz" is three commits, not one.
Write the commit message for future you. Explain why, not what — the diff already shows what. "fix(player): clear queue resets currentIndex" is fine; "stuff" is not.
Branch for anything risky. Free safety net.
Don't rewrite shared history. Once a commit is on the remote and someone else has pulled it, leave it alone. Use revert, not reset/rebase.

Conflict resolution

When pull/merge/rebase says "conflict":

git status # shows files with conflicts

Open each conflicted file. You'll see:

<<<<<<< HEAD your changes ======= their changes >>>>>>> other-branch

Edit the file to the version you actually want (delete the markers, pick lines, combine, whatever). Then:

git add <file> git commit # if merging git rebase --continue # if rebasing

If you panic: git merge --abort or git rebase --abort puts everything back where it was.

Things that look scary but aren't

Detached HEAD — you checked out a commit by SHA instead of a branch name. Just git switch <branch> to get back.
Tracking branch out of date — somebody pushed; you didn't pull. git pull.
Push rejected — same thing. git pull --rebase then git push.

A vocabulary cheat sheet

Term	Plain meaning
HEAD	"Where I am right now" — the current commit / branch tip
origin	Default name for your main remote (GitHub / Azure DevOps)
upstream	The remote branch your local branch tracks
fast-forward	Merge where one branch is a strict ancestor — no merge commit needed
ancestor	A commit further back in history
detached HEAD	Not on any branch (checked out a raw commit)
stash	Hidden shelf for uncommitted changes — `git stash`, `git stash pop`
tag	A named pointer to a specific commit, immutable, used for releases

Three good habits

git status before any operation. Five seconds of clarity prevents an hour of confusion.
git diff --staged before every commit. Catch the "oh I didn't mean to include that" before it's in history.
git pull --rebase not plain git pull. Keeps your local history linear instead of littering it with auto-merge commits.

That's the foundation. Add git stash, git cherry-pick, and git bisect to your vocabulary as you hit the need for them — they're powerful but situational.

Git Basics — Dev & Code Flow