I use git rebase all of the time. We rebase all features onto develop. Develop is then merged --ff-only into stage/release, etc. Which is then merged --ff-only into main/master, and then tagged.

I use squash less, as it can be helpful for blame of course, so rebase with minimal squash (like, squash that typo fix).

The article makes it sound like a 'rebase' workflow is so complex, and time consuming. Poppycock. it's easy, and force pushing a branch cause practically zero issues for developers.

If I have to rebase develop, for example, and then force push it, then remote users only have to do this: git checkout develop git reset --hard origin/develop

Since a user would never have any local changes in develop, it would never be an issue.

The "fanaticism" about and against rebasing is overblown in my opinion. Oh, and the "time wasted" dealing with merge issues.. same, exactly the same in fact.

Granted, I don't go around rebasing everything all of the time, but a developer working on a feature just rebases to develop before they submit a PR. Sure, if there are multiple PR's then they also need a rebase merge, but since nobody would "continue" working on a feature once it is submitted, this isn't an issue.

Oh, and IF they did, well, again, they can just pull develop and rebase their feature.

Now, what I don't do is have multiple developers on a single feature branch. If my team was much larger, and that was a "normal process" then, it may well make rebasing more of an issue..