Why Use Git Rebase and How to Enable Automatic Rebase

Git's official documentation mentions two ways to integrate changes from different branches: merge and rebase. While merge simply combines changes, rebase rewrites the base of your commits onto the latest upstream code, resulting in a linear history.

The term "base" refers to the starting point of a branch. When you rebase, you replace that base with the updated upstream version and replay your commits on top of it, effectively "changing the base".

One major benefit of rebase is a clean, straight-line timeline. Unlike merge, which records each pull point, rebase makes every commit appear as if it were built directly on the newest code, simplifying history inspection.

Two visual examples illustrate the difference: the first shows a tangled history before automatic rebase, and the second displays a tidy, linear history after enabling automatic rebase.

Although many tutorials cover rebase, beginners often hesitate because the commands differ from the familiar pull/add/commit/push workflow and many GUI tools (e.g., VS Code) do not expose a direct rebase button. To simplify, you can set two global Git configurations that make every pull automatically rebase and automatically stash changes during rebase:

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

After applying these settings once on any machine, all future pull and push operations will automatically rebase, eliminating the need to remember the --rebase flag.

The rebase process begins at pull time, not push time, because the repository may already contain new commits that you need to base your work on. Normally you would run git pull --rebase, but the global setting makes this automatic.

Automatic rebase can cause issues when you have uncommitted changes, as Git requires a clean working directory. Git suggests either committing all changes or stashing them. Committing half‑finished work is undesirable, and repeatedly committing after each pull would clutter the branch graph. Therefore, the second configuration ( rebase.autoStash true) automatically stashes your changes before rebase and restores them afterward.

If conflicts arise during rebase, resolve them and then run git rebase --continue; the rest of the workflow remains unchanged.