I’ve found that people are either die hard rebase fans or die hard merge fans. Neither side can understand the other and I’ve never had it properly explained to me what the difference is or why I should care.
I am fine rewriting my own history on local because I know what I did, but not when its on GitHub because other people don't neccecarily know what I did.
https://docs.kernel.org/maintainer/rebasing-and-merging.html
Rebase = Takes all the commits from one branch and sticks them on top of another branch, like stacking them in front. It rewrites the commit history to make everything look like one straight line.
I'm a rebase stan, but that's just my opinion.
Of course, having a merge based workflow doesn't guarantee that people only commit source that runs, so bisect might be broken anyway, and you get a messy history on top of that, unlike the beautiful clean line of a rebase based workflow, that makes it look like the system was developed by people of superhuman mental clarity.
There are situations that make one or the other clearly preferred within a repo, besides per-repo/org-consistency for more widely shared work. After a few years excavating in a merge-only-salt-mine as well as working orgs where merge commits are banned you get a feeling for what's helpful when (esp considering auditability and history legibility).
Always rebase incoming feature branch on the base branch before merging into a shared repo regardless of approach, though - "merged from main" inside a merge commit on main makes anything an inscrutable tangly mess very quickly.
`git rebase` is for academics and startups where no one gives a fuck about anything and no one bats an eye if you waste a day or two on a rebase gone wrong.
It's easy to undo a merge and a bit nasty if you already pushed the merge commit. But undoing a rebase? Oh god you're in for a lot of pain.
It's actually pretty easy. You either make a checkpoint tag before you start the rebase, and reset to it if you notice something went wrong; or, if you forgot to make the checkpoint, check the reflog and find the commit you started from, and reset to that.
Reflog has a flag which adds timestamps to every entry, which I find is helpful for this:
git reflog --date=isoMy good faith addition here: a major influence in this debate seems to me to be how a team views their repo. Merge heavy stuff makes great sense for a repo whose job is just to hold everything; essentially a big and powerful shared clipboard that has all the myriad work-in-progress. Almost like a "dumb" tool (and trust me when I say dumb with lots of love and respect - it isn't criticism it is about which direction coupling points). On the other hand, the rebase heavy approach makes more sense if you view the repo as a contextual knowledge store, holding an almost idealized version of the point in time, uncluttered by the reality of the path actually taken. To broadly generalize my experience, I've found the merge version is generally faster, has low overhead in the moment, and scales pretty well since it is nearly the lowest common denominator approach. Conversely, I've found the rebase version makes debugging and context switching faster and enables a leaner team to cover more ground because the repo has some context and documentation built in via its organization.
Of course, doing either approach poorly will have negative consequences and being inconsistent in either approach is worse than consistently doing one or the other.
I'm not trying to make an argument for which to choose but I am pushing back hard on rebase only being used by teams who are unprofessional and don't care about wasting their time.
Anecdotally, a lot of my coworkers who use merge are conceptually trying to stack their commits on top of previous ones. My lukewarm take: most of the time, rebase is actually the intended operation and merge is used as a hammer.