Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Squash and Rebase in Git

jenweber.dev

Post reply on HN
Print view View original

21–30 of 59 posts

Re: How to Squash and Rebase in Git

#21

Post by mhitza »

unicornmama wrote: post #12

10+ years and I still don’t understand why developers and orgs think it’s necessary to squash and rebase.

I've seen two main arguments to that workflow.

One argument, and which I hear often, is that they want to keep the git history clean.

The other argument is that keeping things rebased & squashed allows you to do reverts easily.

I personally don't mind the merge commits cluttering the history, and especially when working on a longer lived branch I will always prefer merging-in changes rather than constantly rebasing and fixing same conflicts ad nauseam.

Re: How to Squash and Rebase in Git

#22

Post by mportela »

unicornmama wrote: post #12

10+ years and I still don’t understand why developers and orgs think it’s necessary to squash and rebase.

AFAIK it's usually to keep the git history clean but doing it manually is so painful. In my company, we enabled GitHub's "Squash and Merge" option (1) so we have the best of both worlds: a clean history and an 1-click squash process.

(1) https://github.blog/2016-04-01-squash-your-commits/

Re: How to Squash and Rebase in Git

#23

Post by notapenny »

AcerbicZero wrote: post #14

About half the time I get stuck during squashing and rebasing I end up trashing everything, re-cloning the repo and just doing one commit with all my changes from the other branch. Much easier than trying to figure out what series of errors or issues git is having. Fundamentally, this is my fault - I don’t have a good mental model of git, and even when I do have a solid understanding of what I’m attempting to achieve…

As long as your source and target branch are present on the remote (i.e. github/lab/whatever) you probably don't need to trash the entire repo. Just `git --rebase abort` and if you're halfway through a rebase just delete your local source branch and re-fetch it from the remote. That's my process anyway if I somehow lose track of what I'm doing. Or sometimes as a reference I just open the remote branch in github/lab/whatever directly so I have a little cheat sheet, since the "current/incoming" somehow always confuses me.

Re: How to Squash and Rebase in Git

#24

Post by whywhathow1990 »

nwatson wrote: post #18
tyleo wrote: post #4

Is this the same as `merge —squash`? I’m pretty sure it just creates a single commit on the target branch rather than a merge commit.

Yeah, this is easier ... and broken down ... Work on a temporary branch, get stuff all working there, keep merging changes elsewhere into the temporary branch to stay up to date with your PR target branch. Push the temporary branch early and often and don't worry too much about its commit messages (will never be part of official history) except as they pertain to your understanding of the evolution. Then create a new…

exactly what I have been doing

Re: How to Squash and Rebase in Git

#25

Post by fulafel »

AcerbicZero wrote: post #14

About half the time I get stuck during squashing and rebasing I end up trashing everything, re-cloning the repo and just doing one commit with all my changes from the other branch. Much easier than trying to figure out what series of errors or issues git is having. Fundamentally, this is my fault - I don’t have a good mental model of git, and even when I do have a solid understanding of what I’m attempting to achieve…

You could just preserve the history (= don't use rebase, just merge), it has benefits too in addition to making your immediate life easier and safer.

Re: How to Squash and Rebase in Git

#26

Post by stuff4ben »

AcerbicZero wrote: post #14

About half the time I get stuck during squashing and rebasing I end up trashing everything, re-cloning the repo and just doing one commit with all my changes from the other branch. Much easier than trying to figure out what series of errors or issues git is having. Fundamentally, this is my fault - I don’t have a good mental model of git, and even when I do have a solid understanding of what I’m attempting to achieve…

I do the same unfortunately. I have a cheat sheet text doc called Git Shit that I use to attempt to keep track of the myriad ways to do shit in git. What a lot of people don't understand is that one wrong move and you've LOST ALL YOUR WORK! Which I have done enough times that I take the safe way that you describe a lot of times.

Re: How to Squash and Rebase in Git

#27

Post by afidrya »

barbazoo wrote: post #17
unicornmama wrote: post #12

10+ years and I still don’t understand why developers and orgs think it’s necessary to squash and rebase.

For me it's a combination of commiting often and keeping the history readable. To achieve both I have to a) squash commits before merging otherwise I end up with dozens of intermediate commits and b) rebase, otherwise I end up with a history that looks like the Tokyo subway system.

Downside of squashing as opposed to making a merge commit (without fast forward) or merging by rebasing, however, is losing granularity. Later it'll be hard to roll back a small part of PR while keeping rest of the changes.

Also it'll be harder to go back and review changes when troubleshooting issues because formatting changes were squashed together with business logic changes. With merges at least there are still original commits available, and it'll be possible to either rollback everything or a single commit.

Re: How to Squash and Rebase in Git

#29

Post by PaulDavisThe1st »

andrewmackrodt wrote: post #19
ninkendo wrote: post #6

Fixing up merge conflicts multiple times when rebasing is indeed a huge pain (has anyone actually used git rerere? If I ever find myself in this situation I always just squash first instead.) However I typically squash by just doing a soft `git reset` to the merge-base (the last commit in common with my branch and the one I'm building my work from) and making a new commit. It avoids touching the working tree at all,…

I use rerere on all git installations, it's a massive time saver. On the very rare occasion I do want to squash a single commit onto the branch HEAD, I use the same workflow as yourself. Using rebase for that workflow as described in the article isn't necessary IMO. For anyone wondering what that command would look like: git fetch git merge origin/main git reset --soft origin/main git commit -m 'HN-1337 Awesome new f…

git rerere is the bees knees. it's the sunshine of my life. it's the silving lining to the clouds of rebasing. it's ... well, it's just the absolute shiznit and if you use git, you should have it enabled always.

Last year, I finally merged an 18 month "long" dev branch that I had kept up to date with rebasing many times during work on that branch. Why 18 months? Some things just take a long time. git rerere made this easy and almost painless.

Re: How to Squash and Rebase in Git

#30

Post by sodapopcan »

barbazoo wrote: post #17
unicornmama wrote: post #12

10+ years and I still don’t understand why developers and orgs think it’s necessary to squash and rebase.

For me it's a combination of commiting often and keeping the history readable. To achieve both I have to a) squash commits before merging otherwise I end up with dozens of intermediate commits and b) rebase, otherwise I end up with a history that looks like the Tokyo subway system.

I could be wrong, I feel like OP is talking about the workflow where the entire branch is squashed before it is integrated into the main branch, not squashing intermediary commits into more logical ones (which is what I think you are talking about).
Post reply on HN