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.
It’s correct that
rebaserewrites 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 userebaseon my feature branches whenever necessary. If it fell behind themainbranch I dogit fetchfollowed bygit rebase origin/main, resolve the merge conflicts and keep coding. I also use interactiverebasewhen I need to tidy things up before merging the feature branch tomain.Rebasing is fine for any unpushed commits including ones on shared branches.