ProgrammerHumor
rebaseIsNotThatBad
Discussion
Jujutsu users: That's my secret, I'm always rebasing.
Welcome to the “rebased brotherhood”
I believe in rebase supremacy
No rebase, no squash. I'm a simpleton and I like to keep it that way. No commit left behind.
This already saved me from hours of debugging. And if the merge history is hard to track down, then the issue is not merge but probably the Git workflow, unless you work on a very large repo.
To each their preference though, squash and rebase are useful too and I already used them locally.
Can confirm, after wrestling rebase for 2 hours yesterday… it’s not that bad after all. It just needs a better interface.
Better interface than? There's a GUI in just about every IDE and different plugins for other editors and even the odd standalone project
That's a huge part of the problem. Every GUI invents their own terms, making it difficult to have confidence in that's about to happen when you click the button...
Better interface is called git merge
I will reserve rebase for automatic operations (fast forwards) and niche situations. I will just do normal merges otherwise. What's the advantage of the rebase? The amount of people who barely understand Git in the first place makes every non-automatic rebase a risky and painful process, whereas merge commits are pretty straightforward.
Yeah rebasing a feature branch when there's non-conflicting upstream changes in main is nice, because it's a mildly cleaner history.
But the PR is gonna get squashed when it goes into main, so it really doesn't make a huge difference for me. And it doesn't matter to me at all what my coworkers do on their own branches. Win-win.
don't you have the option to prevent the squash?
Depends on the repo settings. If I'm setting it up, branch protection and PR merge settings are the first things I touch.
I see, because I've always been able to not squash my commits in PRs at job repos. And that's the reason I tend to use fetch, rebase + my commits!
Thanks for the clarification.
Truth. Jr.dev: Yeah so this PR I sent you is basically a rebase of feature branch with the latest changes from master and my own personal fixes to make it compile again. Me: All in one neat little 5k line commit for me to review - so efficient, thanks jr. dev!
interactive rebase for simultaneous fast-forward-only merges AND squashing minor revision commits (ex: bugfixing my own change on this same feature branch) :D
but not something I'd recommend for those newer to git
It's all fun and games until a cherry pick the size of your mom comes in.
I used to fear it. Now I evangelize it
Rebased and pulled.
Now add -i and the real magic starts to happen
Just try not to rebase a published branch. You're rewriting git history, and if someone has started working off that branch for some reason, it gets messy fast.
rebase feature branches onto main, squash merge commits into main. this is the way.
Yea, or do whatever you want on the feature branch, because nobody cares anyway when it is squash merged onto main.
as opposed to? merge develop into branch?
rebase is so much more logical imho. But I work in teams of size 5-10 on a non-monolithic application so the change of needing to rebase AND it conflicting AND it being a GIANT hassle is slim to none.
Merge is more honest. Rebase rewrites history and pretends you made all changes on the current main, which is simply not true.
The only people I know that use rebase are people that care more about optics than actual results.
well, I still dont understand the benefit? I like it to see what happend on some branches befor they got merged?
If I rebase a feature to main, don't we lose that Info? isnt it just 1 long straigt main after the rebase?
Well you retain the info of the commits (to the extent that you want it) you only lose the info that it happened on a different branch
yeha, but why would I want that? just because it looks nicer? Do ppl find it easier to read and that kinda is the only reason? is "this commit has 2 parents" that kind of a problem?
git blame will tell you where something was added nontheless.
You're talking about linear history vs merge commits? This isn't really directly related to rebasing, it's another feature called fast forwarding, you can choose this behaviour during the merge with --no-ff or --ff-only. Fast forwarding is the default behaviour so you might associate it with rebasing because you can only fast forward if the commit preceding your first is the branch head.
As for why I guess this is preference. I prefer linear history because I don't see any value in having the branch noise. But also I enforce very good git hygiene within my team so the branch name is not really relevant in the history anyway, the commits carry all the weight.
Those who do not use rebase do not understand how it works
Controversial opinion:
Developers subject to mandatory PR code review should not be allowed to rebase except when the PR is approved.
We squash merge into main anyway (to make sure that every commit on main passed the tests), so it really doesn't matter if you rebase your feature branch or not.
Merge is faster so I use that. Nobody cares if the commit history of your feature branch looks pretty.
It creates a nice commit history but the downside is compared to merging if you make errors in rebase it's gone forever which is actually a crazy thing.
I believe in merge superiority.
Don't fuck with the timeline isn't just good advice for SciFi-movies.
rebase sucks ass I will die on this hill
Just the other day I had to go through a legacy app that uses rebass. It's so monstrously bad you really don't wanna know. For a moment there, I read rebase as rebass. My eye starting twitching for a moment, but it's alright now.
Rebase is amazing, wdym?
Still no rebase, I would rather die on this hill.
nah, hard pass.
It’s all fun and games until you rebase the wrong branch
Just reflog and hard reset, unless you do
git gc, most operations can be reversed.git rebase --abort
Pretty much all operations on commits.
But
git clean -fdis a one way trip to punish land.Reminds of the guy at my workplace, who rebases master instead of merging.
Why? Just merge and squash. If you pull master to your dev branch it should merge to master without issue.
This is common practice in my company...
Of 14,000...
Rebases master onto feature or rebases his branch onto master?
the first is the standard way of doing it,
the second is WHAT ARE YOU DOING STEPDEV ?!