The point is not to get comfortable with the destructive commands. You have one WIP branch that is essentially just cloud backup. Then when you're ready to open

The point is not to get comfortable with the destructive commands. You have one WIP branch that is essentially just cloud backup. Then when you're ready to open your branch up to the world you create a new branch that you've squashed and pruned to your liking-- on Gitlab, this would be the branch for which you submit a merge request. That new branch is the one that receives comments and revisions from all developers-- ideally none of that gets squashed or rebased. The danger is that you silently drop data when trying to make the new branch pretty. But even in that case you still have the old WIP branch as backup, at least until you do a release. And hopefully by that time you've tested the code and had other people look at it and use it.