Why/When should one ever force push?

I often read about how to force push, and that all commits in the remote repository that are not pulled get lost. If one doesn't need specific commits, he could also create a new branch, which is very more common in my opinion, because you don't lose data, even if you don't need the specific code or whatever now, maybe you will need it later, and I don't see any reason to destroy this.

So my question is what reason could I have to do a force push?

Jon Skeet
people
quotationmark

The common reason I experience is this scenario:

  • Master repo on github
  • Fork also on github
  • Clone locally

Work happens locally, then is pushed up to the fork. A pull request is then created, and offered for code review. The code review finds nits (typos etc) which aren't useful as separate commits in the long run. The code review process consists of comments, then small fix-up commits, until the reviewer is happy.

In order to provide a more sensible set of long-term commits in the master repo, the developer then uses rebase to reduce the set of commits in the pull request (often to 1), force push that up to the fork, then when the tests go green, merge that into the master repo.

Basically, this relies on the forks only being used for code review. It would play havoc with anyone who had forked the fork, but the expectation is that that doesn't happen.

people

See more on this question at Stackoverflow