I use interactive rebases to clean up the history of messy branches so they can be reviewed commit by commit, with each commit representing one logical unit or type of change.
Mind you, getting those wrong is a quick way to making commits disappear into nothingness. Still useful if you’re careful. (Or you can just create a second temporary branch you can fall back onto of you need up your first once.)
If you’re using “trunk-based development” (everything is a PR branch or in main), this works great.
If you’re using GitFlow, it can make PRs between the major prod/dev/staging branches super messy. It would be nice if GitHub would let you define which merge strategies are allowed per-branch, but that’s not a thing (AFAIK). So you’re probably better off not squashing in this situation.
@Jesus_666@JoYo Yeah, this. I actually use rebase as a way to restructure my commits more than I actually use it as a replacement for merge - I don’t think it’s an either-or proposition.
One excellent use of this is using --fixup while working on a personal branch. If I’m working on a change and need to tweak something I wrote in a previous commit, I can use git commit--fixup <commit-hash> to earmark it for a later rebase. Then when I’m ready, I can git rebase -i--autosquash to do an interactive rebase, automatically squash the fixups with their corresponding commit and make any other changes as needed.
This has some advantages over amend, namely that I can amend any commit in my branch rather than just the most recent one, and if I’m frequently pushing to trigger CI runs I can do that without constantly force pushing. (It still requires a force push at end, of course.)
I use interactive rebases to clean up the history of messy branches so they can be reviewed commit by commit, with each commit representing one logical unit or type of change.
Mind you, getting those wrong is a quick way to making commits disappear into nothingness. Still useful if you’re careful. (Or you can just create a second temporary branch you can fall back onto of you need up your first once.)
This 100%. I hate getting added to a PR for review with testing commits in the history, and I’m expected to clean those up before merging into main.
I feel like squash and merge on GitHub/GitLab is nicer for that anyway though, it makes the main branch so much cleaner automatically
If you’re using “trunk-based development” (everything is a PR branch or in main), this works great.
If you’re using GitFlow, it can make PRs between the major prod/dev/staging branches super messy. It would be nice if GitHub would let you define which merge strategies are allowed per-branch, but that’s not a thing (AFAIK). So you’re probably better off not squashing in this situation.
@Jesus_666 @JoYo Yeah, this. I actually use rebase as a way to restructure my commits more than I actually use it as a replacement for merge - I don’t think it’s an either-or proposition.
One excellent use of this is using
--fixupwhile working on a personal branch. If I’m working on a change and need to tweak something I wrote in a previous commit, I can usegit commit --fixup <commit-hash>to earmark it for a later rebase. Then when I’m ready, I cangit rebase -i --autosquashto do an interactive rebase, automatically squash the fixups with their corresponding commit and make any other changes as needed.This has some advantages over
amend, namely that I can amend any commit in my branch rather than just the most recent one, and if I’m frequently pushing to trigger CI runs I can do that without constantly force pushing. (It still requires a force push at end, of course.)