1114
Rebase Supremacy
(programming.dev)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 04 Apr 2024
1114 points (98.1% liked)
Programmer Humor
19397 readers
153 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
I wouldn't recommend it. The Git documentation itself doesn't recommend rebase for more than moving a few unpushed commits to the front of a branch you are updating. Using it by default instead of merge requires you to use --force-push as part of your workflow which can lead to confusing situations when multiple developers end up commiting to the same branch, and at worst can lead to catastrophic data loss. The only benefit is a cleaner history graph, which is rarely used anyway, and you can always make the history graph easier to read with a gui without incuring any of the problems of rebase.
Bad take IMO,
At 10+ YOE, I use rebase almost exclusively. Branch from main, rebase to clean up commit history before putting up a PR. If commits are curated properly you don't run into conflicts very often. Branches really shouldn't be shared too often anyway, and the ones that are should be write protected.
Catastrophic data loss isn't really possible either with git since it's all preserved and you can
git reflogeven if you mess up.The meme is right. Git good
When rebasing, it applies the changes without the commit history?
Does that mean that when you fast forward your main/dev branch and commit, you then add a single commit that encompasses every changes that were rebase?
No, there are no fast-forwards with rebasing. A rebase will take take the diff of each commit on your feature branch that has diverged from master and apply those each in turn, creating new commits for each one. The end result is that you have a linear history as though you had branched from master and made your commits just now.
If you had branched like this:
It would like this after merging master into your feature branch:
And it would like this if you instead rebased your feature branch onto master:
This is why it's called a "rebase": the current state of master becomes the starting point or "base" for all of your subsequent commits. Assuming no conflicts, the diff between
AandDis the same as the diff betweenAandD'.