It’s not a case of rebase vs. merge. They’re both powerful commands and you’ll probably use them both. That said, there are use cases where rebase doesn’t really work that well. Unpicking mistakes caused by mistakes using merge are unpleasant, but unpicking errors caused by rebase is hellish.

If you’re the only developer using a repository, there’s less chance of you doing something with rebase that is disastrous. You could still rebase in the wrong direction for example, and rebase your master branch onto your new-feature branch. To get your master branch back, you’d need to rebase again, this time from your new-feature branch to your master branch. That would restore your master branch, albeit with an odd-looking history.

Don’t use rebase on shared branches where others are likely to work. Your changes to your repository are going to cause problems to a lot of people when you push your rebased code to your remote repository.

If your project has multiple contributors, the safe thing to do is only use rebase on your local repository, and not on public branches. Likewise, if pull requests form part of your code reviews, don’t use rebase. Or at least, don’t use rebase after creating the pull request. Other developers are likely to be looking at your commits, which means that those changes are on a public branch, even if they’re not on the master branch.

The danger is that you are going to rebase commits that have already been pushed to a remote repository, and other developers might have already based work on those commits. Your local rebase will make those existing commits vanish. If you push those changes to the repository you’re not going to be popular.