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?
I often read about how to force push, and that all commits in the remote repository that are not pulled get lost
Not exactly: the old commits are still referenced in the git reflog.
Even if you force push to GitHub, you can still see (as repo owner) the previous branch HEAD SHA1 which was overwritten by the new history. See "Does GitHub remember commit IDs?".
That or you have to contact GitHub support.
So my question is what reason could I have to do a force push?
Whenever you are the only one working on a branch (or on a repo, in the case of a fork), you can force push.
This is common in case of a Pull Request, where the web GUI is smart enough to update itself to take into account the new history: you can force push your own branch (again assuming you are the only one working on it) after rebasing it on top of upstream/master (upstream being the original repo that was forked)
This is part of a triangular workflow.
The OP bpoiss adds in the comments:
VonC mentioned in his answer that the data is still present also after force push, so you can not remove sensitive information, or did I miss something?
For removing sensible information on the remote repo, you need to perform some commands on the remote server side:
$ git reflog expire --expire=now --all
$ git gc --prune=now
(source: Remove sensitive data)
That means, when pushing sensitive data to GitHub, you have to contact GitHub support.
The common reason I experience is this scenario:
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.
Git does a lot to ensure that you're not overwriting [everyone else's] history in a way that you're not entirely conscious about. That is to say, if you've got a remote tracking branch and you change the history through git filter-branch or git rebase, Git by default won't let you push it since the histories don't line up.
By force pushing, you are telling Git that you know what you are doing, and it will trust your judgment. That is to say, Git will no longer hold your hand and it will permit you to overwrite references that it was originally safeguarding.
The only valid scenarios to do this in that I've encountered are:
git rebase <branch> or git rebase -i HEAD~12); you won't be able to save the work of the rebase without itgit filter-branch, or potentially through a tool like BFG Repo CleanerForce pushing in any other context can be very dangerous. Since Git assumes you know what you're doing when you force an operation with it, you stand the chance of losing history
The most common reason is when you pushed sensitive data to the remote repository. But if someone else pulled before you force pushed, he will still have access to your private data.
