Introduction

By default, git pull performs fetch plus merge. If your workflow prefers a linear history, you can change that global behavior so git pull rebases instead. This is a reasonable default for personal feature-branch work, but it should be set with a clear understanding of when rebasing is helpful and when merge-based pulls are still safer.

Set Rebase as the Global Pull Default

To make git pull rebase by default across your repositories:

git config --global pull.rebase true

Verify the setting:

git config --global --get pull.rebase

After this, a plain git pull behaves like git pull --rebase unless some repository or command overrides it.

Add Auto-Stash for Dirty Working Trees

Rebasing can stop immediately if you have local uncommitted changes. Auto-stash makes the workflow smoother.

git config --global rebase.autoStash true

With this enabled, Git temporarily stashes local modifications, performs the rebase, then reapplies the stash. That does not remove all risk, but it avoids many needless interruptions.

Understand What Changes in Practice

Without rebase default:

git pull

This fetches and then merges, which can create merge commits in day-to-day feature branch work.

With pull.rebase=true, the same command:

• fetches upstream changes
• temporarily moves your local commits aside
• reapplies them on top of the updated upstream branch

The result is usually a cleaner history for short-lived branches.

Override the Default Per Repository

Not every repository should use the same pull strategy. If one repo should keep merge-based pulls:

git config pull.rebase false

That writes a local repository setting, which overrides the global default.

To see where the active value comes from:

git config --show-origin --get pull.rebase

This is useful when behavior looks inconsistent and you suspect a local override.

Override Per Command When Needed

Even with a global default, command-line flags still take precedence.

Force merge for one pull:

git pull --no-rebase

Force rebase in a repo with merge default:

git pull --rebase

This makes the global setting a default rather than a permanent lock.

Learn the Conflict Flow

Global rebase defaults are only safe if you are comfortable resolving rebase conflicts.

Typical flow:

1git pull
2# resolve conflicts
3git add path/to/file
4git rebase --continue

To cancel the entire rebase:

git rebase --abort

Teams that adopt global rebase should be comfortable with this sequence before making it standard practice.

When Rebase Is a Bad Default

Rebasing is great for personal local commits. It is more dangerous on shared public branches where commit hashes are already visible to others. For example:

• shared integration branches
• branches used directly by CI pipelines with fixed references
• workflows that intentionally preserve merge commits as part of review context

In those cases, merge-based pulls may still be the right local repository default.

Complementary Settings

A practical global baseline often includes:

git config --global pull.rebase true
git config --global rebase.autoStash true
git config --global fetch.prune true

fetch.prune is not required for rebasing, but it helps keep remote-tracking references tidy.

Common Pitfalls

The biggest mistake is enabling global rebase and then rebasing published shared branches without understanding the history rewrite implications.

Another issue is forgetting auto-stash and then getting blocked by local modifications every time a pull needs rebase.

Developers also sometimes assume the global config is broken when a local repository override is actually taking precedence.

Summary

• Set pull.rebase=true globally if you want git pull to rebase by default.
• Add rebase.autoStash=true to reduce interruptions from local edits.
• Use local overrides for repositories that should keep merge-based pulls.
• Learn the rebase --continue and rebase --abort flow before relying on this default.
• Rebase is a strong default for personal feature branches, not for every shared branch workflow.