Git Rebase vs Merge

The cluster centers on debates about using git rebase versus merging in version control workflows, highlighting benefits like cleaner commit history and drawbacks such as rewriting shared history and conflict resolution challenges.

➡️ Stable 0.5x DevOps & Infrastructure
4,351
Comments
19
Years Active
5
Top Authors
#191
Topic ID

Activity Over Time

2008
5
2009
17
2010
108
2011
96
2012
99
2013
305
2014
158
2015
198
2016
280
2017
217
2018
135
2019
295
2020
271
2021
340
2022
472
2023
428
2024
441
2025
390
2026
96

Keywords

A2 A1 B3 e.g B2 UX IMO A5 BS YubiKey rebase commits merge commit branch git branches history master conflicts

Sample Comments

surfer7837 Mar 17, 2022 View on HN

GitHub/Gitlab allow you to rebase your commits when merging. We do that, but has the disadvantage of mucking up things for people who are using that commit. I personally think it’s worth it

wolfi1 Dec 27, 2025 View on HN

why do people rebase so often? shouldn't it be excluded from the usual workflows as you are losing commit history as well?

zrail Dec 12, 2010 View on HN

There's More Than One Way To Do It. Some people find rebase more convenient, some people cherry-pick commits onto another branch, or squash merge them into another branch and merge that into master. Or whatever. Git is fast and powerful in part because it's really stupid. Building another layer of "meta-history" into git would complicate things immensely.

jondwillis Jul 21, 2018 View on HN

It’s exactly like merging but you have to resolve any conflicts commit-by-commit instead of all at once in a merge commit. Useful for if you’ve been working on a feature and want to pull in changes your colleagues have made on the develop or master branch without muddying up your history with merge commits. Having clean history makes diffing easier for code reviews. I’ll admit even after years of rebasing, I still screw it up from time to time.

rhaway84773 Jan 8, 2023 View on HN

Rebase is a lot more than a merge strategy. Merging is only one of the things it can do. Rebase -i allows you to rewrite history, and if you rewrite history of shared code, it leads to all sorts of issues with git.

jarin May 11, 2011 View on HN

Well, that's what we have git rebase for.

rendang Feb 23, 2024 View on HN

As a git newbie I just do git pull. Is the problem that the merge makes the commit history harder to reason through in the future vs if you rebase?

dimes Feb 19, 2020 View on HN

Using a rebase to update from master will cause conflicts for anyone else working on the PR branch. To understand why, imagine a developer branches from master at commit A, and then creates two commits on the branch B and C. In the meantime, master gets updated with commits D and E. Rebasing in this situation, results in a branch that looks like A, D, E, F, G, where F and G contain the same content as B and C, but are now tracked under different hashes. If a collaborator has this branch, git wil

golergka Sep 18, 2015 View on HN

Also, use git rebase instead of merge.

drewcoo Mar 31, 2013 View on HN

Rebase is polite, imho. You probably want a pull request that is "clean" for the code reviewers. And future bug chasers. A bunch of interleaved commits makes it harder for anyone to reason about the code history.