Why I Almost Never Use `git pull`

I actively avoid plain git pull in my daily workflow. Instead, I use git pull --rebase almost every time.

The reason becomes clear once you understand what git pull actually does — and why it often pollutes your commit history.

The Problem with Regular git pull

Imagine this common scenario:

• You start working on a new feature from the current state of main.
• While you're developing, a colleague fixes a critical bug on the same branch, commits, and pushes.
• When you're ready to push your feature, Git complains:
  ! [rejected] ... Updates were rejected because the remote contains work that you do not have locally.

You now need to pull the bug fix before pushing. A plain `git pull` performs a merge — which creates an extra merge commit (often empty or meaningless, just saying "Merge branch 'main' of origin/main").

Over time, especially in busy teams, your history fills up with these useless merge commits:

This makes git log, git blame, bisecting bugs, and cherry-picking much harder — you have to wade through noise to find real work.

The Clean Solution: git pull --rebase

Instead of merging, use: git pull --rebase

What this does (in one command):

1. Fetches the latest changes from the remote.
2. Temporarily sets your local commits aside.
3. Applies the remote commits.
4. Replays your local commits on top of them.

Result: a linear history — no extra merge commits.

• Add new payment feature
• Improve checkout styling
• Fix critical bug in login < remote commit
• Initial commit

Even if you (or your teammate) made multiple commits, rebase handles the chain cleanly.

What About Merge Conflicts?

Conflicts can still happen — rebase doesn't prevent them.

When a conflict occurs during git pull --rebase:

• Git pauses and shows the conflicting files.
• You fix them as usual, git add the resolved files, then run git rebase --continue
• Or, if it's too messy or you change your mind git rebase --abort
  This safely undoes everything and returns your branch to its exact state before the pull started.

After aborting, you can fall back to a regular git pull (merge) if you prefer, or try resolving the rebase again.

Make It Your Default (Recommended)

To never think about it again: git config --global pull.rebase true

Now plain git pull always does --rebase automatically. (You can still override with git pull --no-rebase if needed.)

Important safety note: Never rebase commits that others have already based their work on (public/shared branches). For personal feature branches or tracking main, --rebase is safe and keeps history beautiful.

Summary – My Workflow

• Always try git pull --rebase (or just git pull with global config).
• Clean linear history → easier debugging, reading logs, bisecting.
• Conflict? Fix during rebase or git rebase --abort to bail out safely.
• No more useless merge commits cluttering your beautiful history.

Do you use --rebase by default, or do you prefer merge commits for visibility? Let me know in the comments — curious to hear your experience!