git config is the command used to read and write Git settings—preferences that control how Git behaves for everyday operations like pull, push, fetch, diff, merges, and rebases.

Using git config turns repeated “remember to pass this flag” habits into defaults, so your workflow becomes faster, more consistent, and less error-prone.

What git config does

git config stores key/value settings in Git’s configuration files. You typically set them at one of these levels:

• Global (--global): applies to all repositories for your user
• Local (repository-only): applies just to the current repo

Inspect what you have:

// check all the available options
git config --global --list

//or check a single option
git config --global pull.rebase

With git config, you make Git do the sensible thing by default, every time.

Few high-impact git config settings (what they do + what happens without them)

1) Rebase on pull (instead of merge)

git config --global pull.rebase true

What it does

When we run git pull, Git integrates upstream changes using rebase, replaying our local commits on top of the updated base, rather than creating a merge commit.

Advantage

• a cleaner, more linear history
• fewer “Merge branch …” commits that add little value
• git log reads like a timeline

What happens without it

A normal git pull can create merge commits when your branch and the remote have diverged—leading to a cluttered history.

Without (typical outcome):

git checkout feature/login
git pull
# Often results in a merge commit on your feature branch

With rebase enabled:

git checkout feature/login
git pull
# Your commits are replayed on top of the latest upstream commits

PS: rebasing rewrites commit IDs. It’s usually great for local feature branches, but be careful rebasing shared branches others are already using.

2) Automatically set upstream on first push

git config --global push.autoSetupRemote true

What it does

When we push a new branch for the first time, Git automatically sets the upstream tracking branch (e.g., origin/my-branch).

Advantage

• first push is just git push
• future git push/git pull work without extra arguments

What happens without it

You often see this error on first push:

fatal: The current branch my-branch has no upstream branch.

//Then we must run:
// git push --set-upstream origin my-branch

With the setting:

git checkout -b feature/search
git push
# Upstream is configured automatically

3) Auto-prune deleted remote branches on fetch

git config --global fetch.prune true

What it does

When remote branches are deleted (after merge, cleanup, etc.), Git removes the stale remote-tracking references automatically during fetch.

Advantage

• git branch -r reflects what actually exists on the remote
• less confusion and fewer “ghost branches”

What happens without it

Old remote-tracking references linger locally:

git fetch
git branch -r
# Still shows origin/feature/old-branch even if it was deleted remotely


//You then need to manually prune:
//git remote prune origin

With fetch.prune=true, pruning happens automatically.

4) Use a better diff algorithm (histogram)

git config --global diff.algorithm histogram

What it does

Switches Git’s diff algorithm to histogram, which often produces cleaner, more readable diffs for code with many similar lines (repeated braces, returns, similar blocks).

Advantage

• easier code reviews
• diffs better reflect “what really changed” (less noisy add/remove churn)

What happens without it

The default algorithm can “match” similar lines in a way that makes diffs look messy—especially in refactors—so reviewers may struggle to see the true intent.

5) Reuse recorded conflict resolutions (rerere)

git config --global rerere.enabled true

What it does

rerere (“reuse recorded resolution”) records how you resolved a conflict. If the same conflict appears again (common during repeated rebases/merges of a long-lived branch), Git can apply your previous resolution automatically—still leaving you able to review the result.

Advantage

• huge time saver for long-running branches
• fewer repeated manual conflict fixes
• less fatigue and fewer mistakes during rebases

What happens without it

You may fix the same conflict repeatedly:

1. Rebase ? conflict in file X
2. You resolve it manually
3. Rebase again next week ? same conflict
4. You resolve it manually again

With rerere, step 4 often becomes “verify” rather than “redo”.