Semi-related: my favorite dev tool is diff2html
I aliased `diff` to open up my browser showing me the full diff of what I'm working on - super useful!
How to Squash and Rebase in Git
11–20 of 59 posts
Re: How to Squash and Rebase in Git
#1210+ years and I still don’t understand why developers and orgs think it’s necessary to squash and rebase.
Re: How to Squash and Rebase in Git
#13> 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 y…
Bear in mind we’re teaching folks how to rebase - reflog can be an intimidating dive for a first blush discussion
Re: How to Squash and Rebase in Git
#14About 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 the actual repos/situations I find myself in rarely line up with the examples to any useful degree.
Re: How to Squash and Rebase in Git
#15About 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…
'git reflog' is your friend as it keeps a history of local operations, then you can do a 'git reset --hard HEAD@{X}' where X is the point in your reflog before the rebase started.
Re: How to Squash and Rebase in Git
#16About 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…
Before I rebase, I always create a "backup" branch (`git branch backup`). Then if I mess up, I can always reset back to it (`git reset --hard backup`). Maybe better than trashing and re-cloning :-)
Re: How to Squash and Rebase in Git
#1710+ 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.
Re: How to Squash and Rebase in Git
#18Is 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 branch (for PR) off the one you'll eventually PR to, and `merge --squash` your temporary branch into the branch for PR with an awesome commit message. Submit the PR.
Kill your temporary branch when no longer useful.
Modify the strategy a bit if you want to break up the PR into multiple coarse commits ... 100 temporary-branch commits, 3 new-material commits in for-PR branch, and 4 back-merges of PR target branch to for-PR branch into temporary branch. This keeps a full context of your changes vs upstream changes.
Re: How to Squash and Rebase in Git
#19Fixing 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 feature'
Re: How to Squash and Rebase in Git
#20Earlier quoted context omitted.
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 y…
Bear in mind we’re teaching folks how to rebase - reflog can be an intimidating dive for a first blush discussion
`git reset --hard ORIG_HEAD` is often enough to "undo" a rebase that went haywire.
`git rebase --abort` can be helpful too, if you run into some unexpected merge conflicts along the way.