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 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.