It's fairly common to do `git push --force` (or hopefully `--force-with-lease`) after operations like rebasing. This overwrites the remote history, so can easily lose work. Many people set some branches as protected, so they can't be force-pushed over accidentally.

Isn't it a pretty bad idea to have a workflow which involves --force? If it's to keep history tidy, why not just develop on a separate branch and do squash merges?

I'll admit I haven't used git in extremely complex circumstances, but I've always viewed --force as something you do only if you really mess up, such as pushing secrets (and that should obviously be in addition to invalidating those keys and generating new ones).

Working on a separate branch may still require periodically bringing in changes from master (eg. to resolve conflicts). The options are either a) a merge commit or b) a rebase. A rebase will require a `--force` push. Some people prefer merges, but personally I prefer rebasing - I like to keep my full history even when merging back to master, since it's not a lot of extra effort and it can be useful when tracking down issues in old code :)

the rebase strategy involves force-pushing to your topic branch and then ff-merging to master (or develop, or whatever). some people love it, some hate it, but force pushing is a necessary part of the strategy if the master branch has had new commits since you created your branch.

yes, force pushing can be dangerous, which is why (when you use the rebase strategy) you usually protect certain branches. force-pushing should only happen on your short-lived topic branches.

Its not and it shouldn't.

I do often rebase on my local branch but i will communicate a force push on master to the whole team and will disable protection temporarily.

If thats the only reason, he should overthink his workflow.

People aren't talking about force pushing to master, they're talking about force pushing to another branch, but with master unprotected, and therefore, by accident, force pushing to master as well.

Isn't that situation only possible if config.push is set to matching? As far as I know, it's been set to simple by default since Git 2.0 [0].

[0] https://git-scm.com/docs/git-config#Documentation/git-config...

> Its not

It's not common to rebase?

> i will communicate a force push on master to the whole team and will disable protection temporarily

Isn't that exactly what this point was about? You have branch protection enabled for master because you think it's a good idea to avoid accidental force-pushes. These comments were exactly about not having the ability to protect branches.

I'm not really sure what you're arguing for/against.

git push --force

It doesn't actually delete the commits, but you can't find them anymore if you don't remember the hash of the former head commit of the branch

`git reflog` is your friend; provided not too many operations have since passed.

As ComputerGuru and Schnouki explain, one can use the reflog. For anyone who's intimidated by the reflog, perhaps my recipe under "All the things your branch has ever been" will help.

http://h2.jaguarpaw.co.uk/posts/git-survival-guide/

Unless you use git reflog.

But you can't run it on GitHub's side.