I basically only use git merge
like Theo from T3 stack. git rebase
rewrites your commit history, so I feel there’s too much risk to rewriting something you didn’t intend to. With merge
, every commit is a real state the code was in.
It’s not rebase vs merge, it’s rebase AND merge.
Commit your changes into logical commits as you go.
Then just before submitting a pull request, review your own code. That includes reviewing your own commits too, not just the code diff.
Use rebase to:
- Swap commits so that related changes are together
- Edit your commit messages if you find a mistake or now have a better idea of what to put in your messages
- Drop any useless commits that you just end up reverting later
- Squash any two commits together where the first was the meat of desired change and the second was the one thing that you forgot to add to that commit so you immediately followed it up with another commit for that one missing thing.
Then, and only then, after you have reviewed your own code and used rebase to make the git history easier to read (and thus make it easier to review), then you can submit a pull request.
It’s correct that
rebase
rewrites history, but it’s important to identify when it’s not acceptable. If you are working on a branch that is shared by others (typicallymain
), you should never userebase
. But it’s an acceptable practice when used properly. I userebase
on my feature branches whenever necessary. If it fell behind themain
branch I dogit fetch
followed bygit rebase origin/main
, resolve the merge conflicts and keep coding. I also use interactiverebase
when I need to tidy things up before merging the feature branch tomain
.Rebasing is fine for any unpushed commits including ones on shared branches.