GitLab understood that there's no value in a merge commit that only says "I got the latest code." The history should show what actually happened to the code, not your personal workflow habits.
```text theme={null}
Your branch with rebase (what you want):
Before rebase:
main: A───B───C───D───E───F
\
X───Y (your commits)
After git pull --rebase:
main: A───B───C───D───E───F
\
X'──Y' (your commits, rebased)
```
No merge commits. Your commits sit on top of the latest main. The history tells a clean story.
## When merge commits actually matter
Merge commits aren't evil. They're valuable when you're merging a branch into main. That's the moment when you want to show: "All of these commits were developed together, and they're landing in main as a unit."
The merge commit groups related work. When you're debugging six months from now and you find a problematic line, you can trace it back to its merge commit and see the full context. That refactoring commit? It was part of a larger feature. That feature? Here's every commit that went into it, all grouped together.
```text theme={null}
A meaningful merge commit:
main: A───B───C───────────────M───
\ /
feature: D───E───F───G
│ │
└───────────┘
"Add user authentication"
M = "Merge 'Add user authentication' into main"
Looking at M, you can see: commits D, E, F, G all belong together.
They implemented one feature. That's useful context.
```
This is useful information. "I pulled at 2:47 PM" is not.
## The fast-forward trap
When you merge without the `--no-ff` flag, git will fast-forward if it can. Your branch commits get added directly on top of main, and it looks like they were developed there all along.
This erases context. You lose the information about which commits belonged together. The history looks linear, but it's a lie. Those commits were developed on a branch, tested together, and merged as a unit. That information matters when you're trying to understand why code exists.
```text theme={null}
Fast-forward merge (git merge feature):
Before:
main: A───B───C
\
feature: D───E───F
After:
main: A───B───C───D───E───F
│ │
└───────┘
Where did these come from?
Were they developed together?
Who knows! The context is gone.
```
```text theme={null}
No-fast-forward merge (git merge --no-ff feature):
Before:
main: A───B───C
\
feature: D───E───F
After:
main: A───B───C───────────M
\ /
D───E───F
M = merge commit that preserves the branch structure.
You can always see: D, E, F were developed together.
```
Use `--no-ff` when merging to main. Always.
## The squash merge problem
Squash merging takes all the commits from your feature branch and combines them into a single commit on main. It sounds tidy. It's actually throwing away information.
```text theme={null}
Squash merge (git merge --squash feature):
Before:
main: A───B───C
\
feature: D───E───F───G
│ │ │ │
│ │ │ └── "Fix edge case in auth"
│ │ └────── "Add login form"
│ └────────── "Set up auth service"
└────────────── "Add user model"
After:
main: A───B───C───S
S = "Add user authentication"
Where did commits D, E, F, G go? Gone.
Why was there an edge case fix? Who knows.
How did this feature evolve? Mystery.
```
When you squash, you lose the story of how the feature was built. That refactoring commit that seemed unrelated? It was preparing for the next step. That bug fix at the end? It reveals an edge case you might hit again. The individual commits show the developer's reasoning, the problems they encountered, the decisions they made.
Six months from now, when you're debugging and you find that the auth service is doing something unexpected, you won't be able to trace back through the thought process. You'll just see one big commit that says "Add user authentication" and wonder why things are the way they are.
## The configuration you actually want
Here's how to fix your git defaults:
```bash theme={null}
git config --global pull.rebase true
```
Now `git pull` rebases by default instead of creating pointless merge commits. Your history stays clean. Your teammates will thank you. Or at least they won't curse your name when reviewing the commit log.
For merges, get in the habit:
```bash theme={null}
git merge --no-ff feature-branch
```
Or configure your merge strategy in your repository settings if your git hosting provider supports it.
## The summary
1. **Configure git to rebase on pull**: `git config --global pull.rebase true`
2. **Use `--no-ff` when merging branches**: Preserve the context of grouped work
3. **Avoid squash merges**: Keep the development history intact
## A note on opinions
This is an opinionated piece, and reasonable people disagree on these things. Some teams love squash merges because they keep the main branch looking clean. Some developers prefer merge commits on pull because they mark a clear point in time. There are arguments for all of these approaches, and your team might have good reasons for doing things differently.
What matters most is that your team agrees on a workflow and sticks to it consistently. A consistent approach beats the "right" approach applied inconsistently.
That said, if you're starting fresh or reconsidering your workflow, the approach outlined here optimizes for one thing: making your git history useful when you need to understand why code exists. Your future self, debugging at 11 PM, will appreciate a history that tells a story rather than a logbook of sync operations or a series of opaque squashed commits.