Terminal.Drill Get the app
ch08/l02

Branch and remote sync

Sync without surprising history changes.

git pull --ff-only 20 min read, 25 min lab operator

Branches name lines of work. Remotes are copies elsewhere. `pull --ff-only` refuses to create a merge commit during a simple update, which keeps sync behavior explicit.

In the field

You need to update a local branch before pushing a small site fix.

Worked command

$ git branch --show-current$ git fetch origin$ git log --oneline --graph --decorate --all -n 12$ git pull --ff-only
Anti-pattern

Do not pull blindly when local work is dirty or history shape is unclear.

Safer pattern

Check branch, fetch, inspect graph, then fast-forward if possible.

Knowledge check

Compared with a default `git pull`, why is `git pull --ff-only` the safer way to update a branch before pushing a small fix?

  • A It refuses to update and aborts if a fast-forward is not possible, so no surprise merge happens
  • B It silently rebases your local commits onto upstream to keep history linear
  • C It discards local commits that conflict with upstream
  • D It always creates a merge commit so both histories are preserved
Show the answer

Correct: A. It refuses to update and aborts if a fast-forward is not possible, so no surprise merge happens

Why

`--ff-only` only moves the branch pointer forward and otherwise stops, so history shape stays explicit and you decide what to do next. A default pull may create a merge commit (or rebase, depending on config) without asking, which is the surprise you are avoiding.

Practice checklist

  1. In a disposable repo, create two branches.
  2. Inspect branch and graph.
  3. Explain what fast-forward means.

Deliverable evidence

  • Branch name and graph output.
  • A short sync plan.
Teaching diagramch08 · mental model
Where your work lives working tree edited files index staged commit / branch local history remote origin add -p commit push pull --ff-only git reflog local log of every HEAD move, even after reset save point before repair: backup branch / stash reset --hard discards work never a reflex

shows: The states work passes through (working tree, index, commit/branch, remote), the commands that move it between them, and reflog as the local-only save-point net that reset --hard can otherwise destroy.

does not prove: It does not prove your repository is recoverable: reflog only protects commits Git has actually recorded, so unstaged or untracked working-tree changes wiped by reset --hard are not in scope and stay gone.

Memorize this

Commit these to memory, then drill them until recall is automatic.

git fetchgit pull --ff-onlygit branchupstream

Reference

git log --oneline --graph
Recall practice · Meaning -> command

cue Update the current branch from upstream, but refuse to create a merge commit if it cannot fast-forward.

show recall target

git pull --ff-only

See this drill type Practice recall in the app