How to Fix the Git 'Divergent Branches' Warning on Pull

The Problem

If you've updated Git recently—specifically to version 2.27.0 or newer—you've likely seen a 10-line wall of text every time you run git pull. This happens because Git noticed your local branch and the remote server have both moved forward independently. In the past, Git simply merged these changes by default. Now, the developers want you to be explicit about how you handle these situations to prevent messy commit histories.

The full warning looks like this:

hint: Pulling without specifying how to reconcile divergent branches is discouraged.
hint: You can replace this hint by running one of the following commands periodically:
hint: 
hint:   git config pull.rebase false  # merge (the default strategy)
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only

Quick Fix: Choosing Your Strategy

To silence this warning, you need to pick a favorite workflow. You can set these preferences globally for every project on your machine or locally for just one repository.

Option 1: The Standard Merge (Best for beginners)

This is the classic Git behavior. When you pull, Git creates a new "merge commit" to tie your local work and the remote changes together. It preserves the history exactly as it happened. You'll clearly see where branches joined in your history graph.

# Set globally for all projects
git config --global pull.rebase false

# Or set for the current project only
git config pull.rebase false

Option 2: Rebase (Best for clean histories)

Rebasing is the "clean freak" option. Instead of a merge commit, Git lifts your local commits and slides the remote changes underneath them. The result is a perfectly straight line in your git log. Many professional teams prefer this because it makes code reviews much easier to follow.

# Set globally for all projects
git config --global pull.rebase true

# Or set for the current project only
git config pull.rebase true

Option 3: Fast-Forward Only (The safest approach)

Think of this as the "safety first" setting. Git will only complete the pull if it can move your branch pointer forward without creating a merge. If you have local commits that aren't on the server yet, Git will simply stop and ask you to resolve the situation manually. This prevents accidental, messy automated merges.

# Set globally for all projects
git config --global pull.ff only

# Or set for the current project only
git config pull.ff only

Which one should you choose?

Most developers fall into two camps. If you're working on a small team or a solo project, Option 1 (Merge) is the path of least resistance. However, if you work at a company where the commit history must be pristine, Option 2 (Rebase) is likely the mandated standard.

Need to use a specific strategy just once? You don't have to change your whole config. Just add a flag to your command:

git pull --rebase
# OR
git pull --no-rebase

Verification

Don't just take our word for it—verify the change yourself. Run the following command to check your active settings:

git config --global -l | grep pull

If you see pull.rebase=false or pull.rebase=true, the annoying "hint" text will never clutter your terminal again. The next time you pull, Git will immediately perform the action you chose.

Key Takeaways

• Explicit is better: Git is moving away from "hidden" defaults. It wants you to choose a workflow that fits your team's style.
• Scope matters: Using --global changes the behavior for every repository on your computer. Omitting it only affects the .git/config file in your current folder.
• No more surprises: This warning only triggers when both you and the remote have unique progress. If only the server has new commits, Git performs a simple fast-forward without complaining.