While I think a rebase workflow where you rewrite the history of feature branches is a reasonable approach, rewriting public history is a big no for me. Maybe i

While I think a rebase workflow where you rewrite the history of feature branches is a reasonable approach, rewriting public history is a big no for me. Maybe it is fine with some version control systems, but certainly not git. Git is essentially a blockchain, rewriting history is like rolling back a bitcoin transaction, it is impossible without breaking cryptography. Instead, when you rewrite history in git, you actually create a new project to replace the old one. You then have to tell everyone to switch to your "new project", otherwise you will create a lot of confusion and painful merges, if they don't decide to say "fuck you" and keep working with the original history. Git is decentralized, and to work it needs some consensus, and the consensus is in the history, if you break that, you break the decentralized nature of git. Now, if your don't open your repository to the general public and use git like you would use svn or other centralized systems, it is fine, but don't do that for public repositories.