I personally am a proponent of rebase, but not all the time and not for every workflow. It has it's place though, IMO. I like/value clean history and good commit messages (although I admit I don't always succeeding providing that all of the time). I prefer to stage my commit pieces at the hunk level at the largest. I like to rebase my branches before merging them into release or main (depending on git strategy as a whole), but it isn't always necessary. I use interactive rebase from time to time to clean up my feature branches (especially longer running ones). This is all stuff I prefer in my own workflow.
That said, every time I try to really teach someone rebase, particularly a new dev, I understand why people shy away from it. I did for a very long time. So I totally understand and get why the above style workflow may terrify folks (or just seem unnecessary). It is easy to mess up and there are a lot of little gotchas if someone isn't careful. And worst of all, it can result in lost work (although even that is "usually" recoverable, but not always). I do think there are some benefits to it, and I think it is something that can be integrated into a dev's workflow a bit at a time. And it really doesn't take significantly more time, in my experience.
I'm not gonna argue here for adopting that. Except for "no commit messages", I'd be pretty ok with a workflow as outlined by this post. I do think folks should understand how rebase works, what commits will be moved/changed when they run a rebase (this is vital), and how to recover when a rebase goes bad (no, not reclone, not generally even delete branch and check it out again).
.
Couple random thoughts I try to communicate to folks who decide to utilize rebase more in their workflow:
- rebase often (if main updates often)
- if worried the rebase may be messy, create a temporary branch prior to starting the rebase at the feature branch HEAD - allows for an easy way back (and prevents lost code)
- don't rebase shared branches - this is a tool to use PRIOR to "sharing" (i.e. pushing) code
- squash/clean up unneeded commits before rebasing on another branch (this may bring it all the way down to a single commit, but for larger features, I think there is value in seeing the main decision points along the way)
- fix conflicts with the code at the specific commit you are on only, don't fix it with the eventual end result X commits down the line - this will generally avoid the dreaded "fix the same conflict over and over for each commit" problem some people encounter with rebasing
- remember rebase creates new history - it doesn't rewrite history (however, old commits will eventually be garbage collected)
- pro tip: understand how `rebase --onto` works, sometimes you shouldn't, or at least don't want to, take all of the commits
That said, every time I try to really teach someone rebase, particularly a new dev, I understand why people shy away from it. I did for a very long time. So I totally understand and get why the above style workflow may terrify folks (or just seem unnecessary). It is easy to mess up and there are a lot of little gotchas if someone isn't careful. And worst of all, it can result in lost work (although even that is "usually" recoverable, but not always). I do think there are some benefits to it, and I think it is something that can be integrated into a dev's workflow a bit at a time. And it really doesn't take significantly more time, in my experience.
I'm not gonna argue here for adopting that. Except for "no commit messages", I'd be pretty ok with a workflow as outlined by this post. I do think folks should understand how rebase works, what commits will be moved/changed when they run a rebase (this is vital), and how to recover when a rebase goes bad (no, not reclone, not generally even delete branch and check it out again).
.
Couple random thoughts I try to communicate to folks who decide to utilize rebase more in their workflow:
- rebase often (if main updates often)
- if worried the rebase may be messy, create a temporary branch prior to starting the rebase at the feature branch HEAD - allows for an easy way back (and prevents lost code)
- don't rebase shared branches - this is a tool to use PRIOR to "sharing" (i.e. pushing) code
- squash/clean up unneeded commits before rebasing on another branch (this may bring it all the way down to a single commit, but for larger features, I think there is value in seeing the main decision points along the way)
- fix conflicts with the code at the specific commit you are on only, don't fix it with the eventual end result X commits down the line - this will generally avoid the dreaded "fix the same conflict over and over for each commit" problem some people encounter with rebasing
- remember rebase creates new history - it doesn't rewrite history (however, old commits will eventually be garbage collected)
- pro tip: understand how `rebase --onto` works, sometimes you shouldn't, or at least don't want to, take all of the commits