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.)
Only before you collaborate with anyone else. After that, don’t ever use rebase, or they’ll get an error, and will have to overwrite their local history with the one you’ve rewritten.
The way I structure my commits, it is usually (but not always) easier and more reliable for me to replay my commits one at a time on top of the main branch and see how each relatively small change needs to be adapted in isolation–running the full test suite at each step to verify that my changes were correct–than to be presented with a slew of changes all at once that result from marrying all of my changes with all of the changes made to the main branch at once. So I generally start by attempting a rebase and fall back to a merge if that ends up creating more problems than it solves.
Anyone mind explaining to me how
git rebaseis worth the effort?git mergehas it’s own issues but I just don’t see any benefit to rebase over it.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.)Only before you collaborate with anyone else. After that, don’t ever use rebase, or they’ll get an error, and will have to overwrite their local history with the one you’ve rewritten.
The way I structure my commits, it is usually (but not always) easier and more reliable for me to replay my commits one at a time on top of the main branch and see how each relatively small change needs to be adapted in isolation–running the full test suite at each step to verify that my changes were correct–than to be presented with a slew of changes all at once that result from marrying all of my changes with all of the changes made to the main branch at once. So I generally start by attempting a rebase and fall back to a merge if that ends up creating more problems than it solves.