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