When I'm working on a feature branch, I tend to want to cleanup the commits in the branch using an interactive rebase before my work is reviewed and integrated in the main branch.
During development of the feature, I want to push my intermediate work to the remote repository as a backup measure. I.e. when my hard-drive crashes, I don't want my entire feature branch to be lost.
However, this leads to the fact that I often have to do a git push --force to the remote repository after a rebase, an action which is generally frowned upon. Or as the linked github page says:
Because changing your commit history can make things
difficult for everyone else using the repository, it's considered bad
practice to rebase commits when you've already pushed to a repository.
Is there a (generally accepted) policy that solves this conflict?
Why this is not a duplicate of Is the git "Golden Rule of Rebasing" so essential?
My question here asks for a policy to solve the conflict between wanting to backup your work in the remote repository and rebasing your work, while the other question tries to deny that there is a conflict and asks why some people think the conflict exists at all, and thus asks why "it is essential" not to push force rebases?
Best Answer
The key question to ask yourself:
If you delete your remote feature branch after merging into master, you already are losing the history. Assuming you squash/rebase the branch prior to making your merge/PR you lose this history. All your force push is doing in this case is allowing you to use github as a backup.
The situation where you would want to keep the history and not force push is if your remote branch is persisting after being merged and not only existing for a temporary period of time.
It sounds like you have multiple people pushing to that branch simultaneously. This means you do care about the history on the branch.
What you could do instead for your intermediate work is create a fork of that branch. You can push to this and then rebase all your commits into a single commit prior to merging, so when you merge them into your feature-branch, you only have 1 commit (with the rebased history of your entire branch).