How to Squash and Rebase in Git
jenweber.dev
How to Squash and Rebase in Git
1–10 of 59 posts
Re: How to Squash and Rebase in Git
#2git(1): there is more than one way to do it
Re: How to Squash and Rebase in Git
#3> Create a backup branch and push it up to GitHub/Gitlab/etc. This backup branch will have all your work nice and safe in case you need to start over.
The way I teach programmers to do this is to make use of cheap branches and to instead work on a temporary branch, and eventually use ‘git reset --hard branchName’ to turn your original branch into a mirror of the temporary one when ready.
This is a helpful mindset to get into; you can just throw it away in a worst case.
Re: How to Squash and Rebase in Git
#4Is 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.
Re: How to Squash and Rebase in Git
#5I recently started using `git commit --fixup` which I really like. It lets you take the current changes and apply them to a commit which is not the most recent (in a fairly roundabout way). It's good for when I have a stack of diffs and want to make changes to multiple commits at once. (Note this is a pretty advanced technique, if you're not super comfortable with `git rebase -i` I wouldn't bother even trying to understand `--fixup`)
https://fle.github.io/git-tip-keep-your-branch-clean-with-fi...
Re: How to Squash and Rebase in Git
#6Fixing 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, which avoids breaking my build cache and confusing my IDE.
If I instead want to do a squash-rebase onto the _latest_ of the upstream branch, I do the same as the above, except I `git merge` first (to resolve any merge conflicts in one shot.) Then the merge-base is just the upstream head. This is way easier than doing `rebase -i` and squashing, because you don't have to fix the merge conflicts over and over again for every commit you're trying to squash... just fix the merge conflicts once during the merge, and the "reset and commit" trick is going to create one clean commit in the end anyway.
Re: How to Squash and Rebase in Git
#7Fixing 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,…
Man, this is way too complex for me.
Re: How to Squash and Rebase in Git
#8Fixing 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,…
If the interim commits are not interesting (which they often aren’t) then it is definitely a lot easier to wrangle a single commit than multiple. This is good for cherry picks as well. Much easier to pick a single commit than a bunch.
I also like the “reset and recommit” approach to squashing in place. It greatly benefits from being easier to explain to coworkers who are less experienced with Git. Reset and especially commit are common operations. Interactive rebase and the text editor that pops up and requires manual editing can be overwhelming for less experienced team members.
Re: How to Squash and Rebase in Git
#9> Create a backup branch and push it up to GitHub/Gitlab/etc. This backup branch will have all your work nice and safe in case you need to start over. The way I teach programmers to do this is to make use of cheap branches and to instead work on a temporary branch, and eventually use ‘git reset --hard branchName’ to turn your original branch into a mirror of the temporary one when ready. This is a helpful mindset to…
For rebasing specifically I often don’t make a temporary branch. I’ll use the reflog and reset to the commit hash if something gets messed up.
Those “backup” branches really aren’t that for me. They’re just named commits which makes it easier to figure out where I was. But they are sometimes necessary since the reflog isn’t always nice and easy to read.
And pushing that branch to a remote? That’s unnecessary unless you want to delete the whole repo and clone it again in case you “mess it up”. Well, I guess that could be useful in a tutorial.
Re: How to Squash and Rebase in Git
#10Fixing 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've tried rerere in the past. I just never remember exactly how to enable/disable it as needed, so it seemed like it was either off when I need it or auto-fixing something when I don't want it to.