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.
I use rebase only to clean up some commit messages, squash commits, etc. - essentially to clean up feature branches I wrote. But never rebase to ‘move’ my branch as if it originated from a different commit, because I don’t know necessarily know what changes have been introduced on the other branch (typically main/master), so rebasing on that would leave my commits in a state that they were never tested in, possibly broken / with unintended sideeffects. If I need changes from the other (main) branch in my feature branch (because of feature dependencies, or to fix merge conflicts), I merge it into my branch and can be sure that the commits created before that merge still behave the way they did before that merge - because they were not changed; this can’t be said for rebasing.
Ideally I’m working on a short lived branch that only I’m working on in which case I do a rebase from origin/master where I also touch up the history in case there are any “forgot x in the previous commit” type of commits before doing a merge request. I won’t rebase code someone else might have pulled, and I’ll quit rebasing if I get any non-trivial conflicts .
Tbh, I hate both. I wish git recognized an attempt to sync with a parent branch without resulting in either altered history (rebase) or a difficult to view log graph (merge). I also hate that teams have to choose one or the other.
It would be nice if all git graph UIs could easily exclude parent branch merges (with a checkbox). I wrote a shell script that did that, but not everyone used it of course.
I rebase with parent branch until I create a PR. Hopefully, I’ll get reviews quickly and won’t have to sync with the parent branch before merging the PR into the parent. However, if the PR lives longer than I’d like and conflicts occur, I’ll merge from the parent branch into the local feature branch.
They’re both different commands and I use them for different things.
When “merging” in master/main before opening a pull request I always rebase any local commits I have, it does no harm but vastly reduces complexity of the commit tree - however, as soon as code from other branches enters the picture I merge
