Q21 of 40 · Git

Why do many teams configure `git pull --rebase` as the default, and how do you set this globally?

GitMidgitpullrebaseconfigworkflowlinear-history

Short answer

Short answer: `git pull --rebase` replays your local commits on top of the updated remote tip instead of creating a merge commit, keeping history linear. Set globally with `git config --global pull.rebase true`.

Detail

The default git pull behaviour is to fetch and then merge. When your local branch has commits not yet on the remote, this creates a merge commit — even if the divergence was trivial (you wrote one commit, a colleague pushed one commit). Over time these merge commits add noise to git log and make --graph views harder to read.

git pull --rebase fetches the remote changes, then replays your local commits on top of the new remote tip. The result is a linear history: your commits appear as if you wrote them after your colleague's, with no merge commit. This makes git log --oneline readable and git bisect more reliable.

When NOT to use it: if your local commits have already been pushed and others have based work on them, rebasing rewrites SHAs and diverges. Use git pull --rebase only for commits that are still local (the normal case before pushing).

Configuration options:

  • pull.rebase true — always rebase.
  • pull.rebase merges — rebase but preserve merge commits in your local history (for complex feature branches).
  • pull.ff only — only allow fast-forward pulls; fail loudly if a rebase or merge is needed (strict teams use this to enforce discipline).

// EXAMPLE

# Set rebase-by-default for all repos (recommended)
git config --global pull.rebase true

# Alternatively, only fast-forward (fails if local commits exist)
git config --global pull.ff only

# Per-repo override (useful for legacy repos)
git config pull.rebase false

# One-off pull with rebase (without changing config)
git pull --rebase

# If a conflict occurs during rebase-pull:
# resolve conflict in editor, then:
git add src/test/java/ConflictedTest.java
git rebase --continue

# Abort and fall back to merge-pull if needed
git rebase --abort
git pull --no-rebase

// WHAT INTERVIEWERS LOOK FOR

Understanding WHY rebase keeps history linear (no noise merge commits). The global config command. Awareness that pull.ff only is an even stricter option. Knowing when rebase-pull can fail (pre-pushed commits).

// COMMON PITFALL

Setting pull.rebase true globally and then pulling a branch that others have rebased, resulting in duplicate commits. The safest rule: rebase pulls are for integrating remote changes into local-only commits.