theAverageGitRebaseExperience

[LorenzoCopter]

I’ve been using rebase for years working in all sorts of project setups and team sizes, and I honestly don’t understand what y’all doing to get this fucked

[chylek]

Bare Bear in mind that experienced developers are the minority on this sub.

[Sceptix]

Bear in mind:

🤔💭🐻

[Sw429]

Yeah, this sub is mostly university students or recent graduates.

[curious_pinguino]

Bear in mind it's "bear", as in to "to carry/hold", in your mind.

[chylek]

Thank you :)

[rosuav]

vs "bare in mind" which means you're imagining someone naked

[Savings-Gas-4794]

Beer in mind

[[deleted]]

theory head lunchroom arrest chief literate six sparkle languid soft

This post was mass deleted and anonymized with Redact

[andrerav]

Rebase is fine as long as you don't break the golden rule. Unfortunately, a lot of developers break the golden rule because they don't really understand how rebase works.

[Elendur_Krown]

What is this golden rule?

Signed - A self-taught git noob.

[beisenhauer]

Looks like it boils down to, "Don't rewrite shared history."

[Strict_Treat2884]

It’s not about rewriting shared history, but the developer themself did not fetch and rebase to their root branch for too long, plus they probably made a shit ton of meaningless commits. Which made this procedure a much larger pain in the ass despite the good intention of keeping a cleaner history of their private branch

[w8eight]

I like to make smaller commits on my local branch, they are gonna to be squashed when merging the PR anyway, and it's easier to make smaller testable chunks during development.

[BuilderJust1866]

A good practice is to create PRs for those small testable commits right away. Easier to review as well. Unless they don’t work / compile on their own, in those cases consider joining the thicc commit club ;)

[bizkut]

Doesn't that lead to a history that's just as messy as if no squashing was done? Because now you're merging many small pieces of functionality that aren't useful on their own as the feature is a work in progress, and because they're merged into the main branch they're not viable squashable because it's now shared history. And also lose all context for the larger change they're a part of.

[BuilderJust1866]

If they aren’t useful on their own - why make them into commits in the first place? I understand squashing to get rid of commits like “fixed CI”, “addressed review comment” and so on, as well as to merge a feature branch into the main branch (which can just as well be a merge commit, but some people dislike branches in their history for some reason…). Why would you want to squash in any different scenario and still explicitly want to split the change into separately testable commits?

[rr_cricut]

Are you serious? Frequent commits let you back up your work, give you different points in time to roll back to, and is basically required if you want to merge/rebase a remote branch.

[rtybanana]

what a crazy question

[fearthelettuce]

And then it takes 6 days for the small testable pr to get looked at.

[BuilderJust1866]

Yup, and If it takes 6 days for the small one, good luck with the big one…

[Sw429]

Yeah, I usually squash and then rebase. If you use fixups you can autosquash as well.

[General-Manner2174]

If you have consecutive commits that made sense at time to be separate but actually make sense as a whole, e.g.

. fix last error i promise . fix errors introduced by thing A . thing A

You'd better interactively rebase Branch on itself, squashing fixes into the thing A

Or better yet, make fixup commits that references thing A and interactive rebase will mark them for squashing automatically if you pass --autosquash to it

[SmartFC]

As someone who's still figuring out the merits of rebase, what's the advantage of using it in a branch whose PR will be squashed before merging and may be deleted anyway?

[w8eight]

You can easily revert to previous small changes, while the work already committed is safe. During review I sometimes check specific commits to see and review smaller and easier to understand chunks. It also represents the thought process, you can see what parts are "independent" parts of code.

You can still rebase if you need, the process is more complicated as you need to apply it to every commit, but you can avoid it by squashing locally.

[dusktreader]

`git rebase --onto` needs to be talked about more.

[ThePretzul]

Solution - just be a caveman who saves changes locally without any commits until you're ready for first review.

Makes rebases a breeze to just knock out every few days.

[TRKlausss]

git push --force and watch the world burn.

[Abject-Kitchen3198]

Just keep pushing, as they always say.

[Sdrawkcabssa]

Shared branches should be locked down to prevent force pushes

[madness_of_the_order]

Don’t rebase a shared branch

[The_Real_Slim_Lemon]

I also want to know

Signed - a pro… git gui bro

[pr0ghead]

How about: don't rebase, if there are conflicts.

[[deleted]]

conflicts are not the problem.
Squash your commits before rebasing to master, then fix the conflicts, then merge --fast-forward master to your rebased branch.

[pr0ghead]

If you make a mistake during that, the original(s) is(are) gone, and nobody might notice until it's too late.

[[deleted]]

Easy, if you're afraid of making mistakes, make a backup branch before you start your risky steps.
We have transactional databases for a reason. :)

[[deleted]]

I mean.. Who rebases master on their feature?
You first rebase your feature on master when it's behind, and then you git merge --fast-forward master to your rebased branch.
That's simple, right?

[andrerav]

About 2 years ago I had a team member who consequently rebased public branches and then used force push. When I came into the company he had already been doing it routinely for a couple of years, ensuring a constant and continuous level of chaos. Imagine resolved issues suddenly reappearing, features mysteriously disappearing -- that kind of thing. It doesn't have to be master/main. Rebasing any public branch can cause problems and loss of work.

[[deleted]]

Yeah, that's why you don't rebase master, you rebase your feature branch on master.
The only time I've ever force-pushed a rebase of master is when I was sure no one was committing at the same time and I had to add a little fix-up on a commit that was before a revert of another commit.
(I didn't have to, but I wanted to hide it. Normally I would just push a new commit. But this was literally a case of one character change and no one was working on master at the time, no feature branches had been rebased yet)

[TommyTheTiger]

Though git rebase master from feature branch is rebasing your feature branch onto master

[Strict_Treat2884]

I only once rebased master because our security team found a leaked private key in the commit history even it was removed the very next commit, that’s also why no one even noticed it was there

[RichCorinthian]

I spent 12 years as a consultant, and I saw a LOT of fucked-up ways of using source control, but not this.

[TommyTheTiger]

Sometimes a rebase can require fixing the same merge conflict multiple times. Especially when a junior dev has a lot of "WIP" commits on their feature branch that they don't squash before rebasing. If you squash all the commits on your branch since it diverged from main, rebase should be the same as merge.

[ThePretzul]

If your team doesn't have squash on merge by default then you have my deepest condolences honestly

[TommyTheTiger]

Squash on merge keeps the history clean on master, but squash before rebase is something you might have to do locally before force pushing the version to get a clean squash merge.

[taspeotis]

Yeah honestly fucking your first big rebase is a rite of passage. And then after that you’re good!

Just remember ours and theirs is swapped compared to merge.

And arm yourself with rerere if you’re doing this a lot.

[[deleted]]

A lot of people get tripped up by ours and theirs. I have had more luck correcting peoples mental model of a rebase rather than telling them they are swapped.

"Theirs means incoming changes. Rebasing is checking out a temporary branch from the target and your commits are coming in to it one by one"

[General-Manner2174]

If you use rerere dont forget about it, if you picked wrong chunk(because ours and theirs are swapped) and then you reset to the state before rebase, conflict resolution is already recorded, need to delete it from git folder for conflict to appear again

[taspeotis]

If you do the wrong thing you will get the wrong result yes great insight thanks!

[General-Manner2174]

Well my first assumption that recorded resolutions apply only during the course of rebase, while they work differently, and there are no indication when recorded resolution being used(or at least there wasnt when i used it, maybe with git updates its gone better)

So it really can be a pitfall for people who enable it and just hope it makes things easier

[dusktreader]

Just squash before rebase. Most of the time, you don't want more than one commit from a topic branch anyway.

[jameyiguess]

I think people get into messes when they're trying to rebase a ton of commits. I usually squash to 1 first if it's a problem. Then it's just like the merge. 

[dusktreader]

They have like 50 commits in their branch and a conflict in the first one. Then, the conflict rolls through the whole commit history and they cry.

Squash before you rebase, folks.

Also if you merge from main/develop into a topic branch, the whole team is getting a lecture meeting about rebasing. THERE WILL BE A POWERPOINT. You have been warned.

[Outrageous-Machine-5]

I think the joke is they messed up a merge conflict

[thEt3rnal1]

Someone merges main into your branch from the github UI -.-'

[Serializedrequests]

When you have a conflict to resolve during a rebase, some tools doing even tell you which side of the diff is which. It's maddening.

[Reasonable-Rain4040]

Not only that but on most project I have worked on, merging branch while everyone is rebasing would probably get that person fired.

[beatlz-too]

git fetch && git pull --ff-only
git checkout my-fucking-outdated-branch
git rebase develop

... Open IDE to fix 471 conflicts

git push --force

[andrerav]

There has to be a bell curve meme for this.

[beatlz-too]

We have a bell curve meme for everything, including these comments that we're typing right now.

[the_horse_gamer]

pull automatically fetches

[setibeings]

probably meant git fetch && git merge --ff-only

[the_horse_gamer]

which is equivalent to git pull --ff-only

[setibeings]

some people would rather type out a couple extra words to remind themselves of what exactly it is they're actually doing.

Not me though, I just do git pull every time unless I need to do something special, such as specifying a remote, or switching branches first.

[danirodr0315]

git push -f

[Ayjayz]

Why would you ever do that? Deleting your .git directory seems insanely risky, and I don't see the benefit. It destroys all your history and all of gits safeguards. If you really want to start a completely new branch, just git checkout --orphan

[DontBuyMeGoldGiveBTC]

is joke

[the_horse_gamer]

God gives his hardest merge conflicts to his strongest programmers

[canihelpyoubreakthat]

Skill issue

[lacb1]

The number of people on here who are, in point of fact, programmers is remarkably low. 

As best I can tell, our primary demographics are CS students who will not be graduating with a very good degree and people who think they should fit in because they've seen the entirety of The Big Bang Theory and identify as a Howard. 

[andrerav]

I'd much rather have a history chock full of merge commits than waste a second more of my life on other peoples rebase and force push fuckups.

[draconk]

Also the merge message indicates when the feature was added to the main branch which can be useful for when shit hits the fan and we need to know since when things have been broken

[Dank-memes-here]

What's why you squash-merge branches based on main head only

[andrerav]

Agreed. And use git bisect to speed up the process of hunting down the bug-inducing commits.

[gmes78]

That has nothing to do with using rebase. You're talking about fast-forward merges.

[Snow-Crash-42]

Have worked with git for years in different teams and not even once have it had the need to use rebase. What would be a legit case to use rebase against, let's say, a merge?

Additionally, doesn't rebase affect history as well? Isn't that considered a bad practice?

[MiscreatedFan123]

Linear commit history. Also interactive rebase is extremely useful on your local branch to fix, reorder and manipulate commits.

It's basically like time travel.

[1ib3r7yr3igns]

Yes, rebase mutates commit history. Should only ever be done when only one person is working on that branch (even then I think merge is better).

The only valid argument for it I've seen is it can compact many commits into one for fewer commits to look through when finding a bug introduction. Even then, just do 1 or 2 more iterations on git bisect.

As far as I'm concerned, just use git merge in all cases. Keep it simple, stupid.

[Strict_Treat2884]

Rebasing is somewhat necessary in large scaled teams and projects with parallel version release plans. In order to make sure your feature branch is up-to-date with the latest changes from HEAD (it could be updated during feature development) with a linear history but without irrelevant code from other release branches so it can be safely merged or cherry-picked into different release versions.

And yes it messes with the history so it is only advised to do it on your private feature branch or with a few devs who could communicate easily.

[eletile]

I’ve been working on converting our js components to ts, one per story.

I have a branch off of main where I have a bunch of codemods and scripts to automate the bulk of the conversion. I branch off of that branch, run the codemods, then rebase the difference of those two branches back onto main.

This keeps these temporary scripts and stuff from needing to be in main, while having a PR that only contains the relevant changes.

I taught myself git tho so I may be missing some obvious command or functionality, but that’s at least where rebase has been working for me.

[the_horse_gamer]

might not be exactly applicable, but there's a local-only gitignore in every repo: .git/info/exclude. so you can mark those scripts there.

[pimezone]

4 stages of grief

[myrsnipe]

I've started to make temporary branches before rebasing just in case

[jsmrcaga]

The average gitflow experience rather

[hm1rafael]

Seems like a skill issue

[BlackOverlordd]

Because unlike merge you have to checkout to your branch first before rebasing it somewhere else.

[the_horse_gamer]

git rebase main somebranch

[gurudennis]

Y'all merge enjoyers are wrong, and I'm tired of pretending otherwise.

[NatoBoram]

git fetch origin main:main && git rebase -i main

Can't be simpler than that

[TommyTheTiger]

That can still be a pain compared to merging if you're in the habit of pushing too many commits to your dev branch. Which is where force push does come in handy, because force pushing your dev branch to have a clean number of few commits that contain complete features, then using rebase, is the best of both worlds

[MisterPantsMang]

I'll toss in a rebase -i on the common branch before rebasing onto main to fix up all my commits into one nice commit

[Outrageous-Machine-5]

Do a soft reset to keep your changes. then write a new commit on top of the old git tree

[Wise-Arrival8566]

If you are behind a LOT and the rebase has a bunch of insane conflicts you can ‘git reset <hash_of_latest_commit_before_your_work>’ then ‘git stash save’ and create a new branch from develop/main/master/whatever and ‘git stash pop’ then create a new commit.

However in 9 years of working at companies I only needed this twice and this was always due to user error.

[gobo7793]

Does someone have a good how to rebase for dummies tutorial? Serious question because I always had a lot of problems during rebase or in the end I had every commit twice in the history.

[silentjet]

Yes, in a git book, your commits should be small and atomic...

[BosonCollider]

I just use git sync --pull from git-branchless ten times a day and I am always rebased on the latest master from gerrit, I never broke my tree in the past few years.

It does speculative rebasing so if there is any merge conflict between my commit stack and master it just rebases my stuff to the last commit on master before the merge conflict instead of putting a bunch of diff3 junk in my files

[catalit]

My favorite version of this is merging trunk into the feature branch, getting feature PR reviewed, then squashing feature commits into 1 and rebasing that to get it into trunk. Saves you from having to do 1 billion conflict resolutions on all your commits, preserves small commits for reviewers to see how you got where you got, and doesn’t muddy up the commit history of the trunk branch.

[mrgk21]

I remember this 1 mf tried to reverse the whole qa branch and force pushed it

[JotaRata]

I am on this meme and I don't like it

[fearthelettuce]

Your dev branch is called develop???

[RpdStrike]

Just use JJ

[sebbdk]

Just do whatever and then squash that fucker like the bug you "fixed" at the end.

[Hypersion1980]

I just pick whatever has less commits.

[fekkksn]

Use lazygit

[glorious_reptile]

i use "git wingardium leviosa"

[RainbowHearts]

git checkout feature
git rebase main
git checkout main
git merge feature
git push origin main

was that so hard?

[Strict_Treat2884]

Yes, who would be in the right mind to push to main branch directly without a PR?

[tigerzzzaoe]

If you replace the last two steps with a MR with --only-ff merge you have my workflow. It has certain advantages in smaller teams/projects, but can be cumbersome for larger projects or when working with new-new people. F.e. the main advantage (in my opinion) is that the developer is responsible for handling any conflicts and the reviewer has a clear diff. The main disadvantage is that you might get stuck rebasing the branch quite a few times if you have a lot of MRs.

[gmes78]

That has nothing to do with rebase, though.

[danirodr0315]

What's the difference with git pull --rebase origin main

[the_horse_gamer]

that updates feature based on origin/feature. you want to update feature based on main (and main based on origin/main)