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 don’t know how to use rebase, so I use merge
Please never rebase after you open a pull request. It breaks the iterative workflow of code reviews – it makes it hard to see if issues brought up in comments were addressed or not.
I’ll often commit half finished or outright broken code to a private branch for my own purposes. Then I’ll rebase before pushing to make the history make more sense to the team and get rid of fluff commits.
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.
This sounds like a really good work flow. I’ve only started working professionally with git only few months ago when I switched jobs to gamedev (for some reason, even though I worked for three years as a pentester in cybesecurity company they literally didnt use VCS for anything), so I still don’t have proper git workflow of my own, and this sounds way better. Thanks!
Before I had to start making PRs, my whole git experience on personal projects was
git add . ; git commit; git push;
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.
