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?