02 · Foundations

Git Basics

Git is a content-addressable filesystem with a version control interface on top. Understand the three areas (working tree, index, HEAD) and most "weird" Git questions stop being weird.

The mental model

Every commit is a snapshot of the entire working tree, identified by a SHA-1 hash of its content plus its parent. A branch is just a movable pointer to a commit. HEAD is a pointer to the current branch.

Files live in three areas:

• Working tree — files on disk you edit.
• Index / staging — what will go into the next commit.
• Repository — committed history (the .git directory).

Every command moves data between these three areas. git add moves working tree → index. git commit moves index → repo. git checkout moves repo → working tree.

The day-to-day commands

git init                       # start a repo
git clone <url>                # copy a remote repo
git status                     # what's modified / staged
git diff                       # what changed in the working tree
git diff --staged              # what's about to be committed
git add <file>                 # stage a change
git commit -m "feat: …"        # snapshot the index
git log --oneline --graph      # browse history
git push / git pull / git fetch
git branch / git checkout -b <name>
git merge <branch> / git rebase <branch>

Branching strategies

Trunk-based development. Everyone works on short-lived branches (<48h) off main. PRs are small, reviewed fast, merged frequently. This is what high-performing teams in Accelerate measure.

GitFlow. Long-lived develop and main branches with feature/*, release/*, hotfix/*. Heavy. Only justified when you genuinely ship multiple versions in parallel.

GitHub Flow. One long-lived main; every change goes through a PR. The pragmatic middle ground; what most SaaS teams use.

Merge vs rebase

merge creates a merge commit that joins two histories — the original branch lines are preserved. rebase replays your commits on top of the target branch as if you had branched from its current tip — history is linear but commits are rewritten.

Rule of thumb: rebase locally, merge when published. Never rebase a branch other people have pulled.

Commit conventions

Conventional Commits. Format: type(scope): message. Types: feat, fix, refactor, test, docs, chore, ci, perf. This is enough structure to generate changelogs automatically and to spot at-a-glance what a commit does.

A commit message that explains why the change exists is worth ten that say what changed — the diff already shows the what.

What to remember at exam time

• Working tree / index / repo — name the three, name the commands that move between them.
• A branch is a pointer; HEAD is a pointer to a pointer.
• Merge preserves history; rebase rewrites it. Which one you use depends on whether the branch is shared.
• Trunk-based + short PRs is the cited best practice in Accelerate.