How to reverse git push --force?

Question

I made a git push --force, but I wish I had git push --force-with-lease it is possible to reverse this?

Answer 1

If you haven’t ruined anyone’s work by pushing git --force - you don’t have to go back and do the other. If damaged, doing "force-with-Lease" doesn’t help either: he would only refuse to push.

All that the git push --force-with-lease makes sure to overwrite some work that your local repository didn’t know about yet.

For example: if you make a git fetch the push --force and push --force-with-lease are indistinguishable: the second is as destructive as the first.

• if you have over-written third party work: this is bad! And that’s part of the reason why you shouldn’t use git push --force (with or without "with-Lease") in the team’s workflow.
  1. Stop the team work now and call for an online meeting. There is a risk that lost work cannot be recovered if everyone does not do so
  2. The written information by git push --force on the remote server (github/gitlab/bitbucket), they are no longer recoverable from there. Kaput! End! Dead! (except if the remote server is under your control and not a git hosting in the cloud). (I’ve already said it’s not good to use "git push --force"?)
  3. The good news is that they can be recovered on the machine of those who had the work that was over-written. So, using your online meeting, identify who had the work over-written, and calmly so as not to make things worse:
     1. If you haven’t done a "git pull" or "git fetch" yet, it simply does a git push --force back, and her work that was lost on the server is restored on the server. Agree that starting tomorrow you will use separate branches to work, and you can go to happy hour now;
     2. if the person did a "pull" and ignored git’s security warnings that the remote branch and its location diverged, and over-wrote its local branch with the remote branch, which was damaged by the "push --force" given incorrectly - the team is in the swidden, but has exit:
     3. The person who had the over-written work has to use the command git reflog. With this command you should be able to find the commit that was previously on the cloud server. She can now create a new branch with this commit by going back over-writing work - just copy the hash from the lost commit and do: git branch branch_restauracao <id-do-commit-perdido> - ready, she will have a local branch, on her machine, with the work that had been over-written on the server
     4. Now one can simply upload that "white_restore" branch to the server, and open a normal pull request there to retrieve the work that has been overwritten. You go to a happy hour; tomorrow it goes around everyone and combines to work with branches and pull requests to the main branch; everyone is happy!

In short, you probably don’t have to do anything. But it’s best to review your team’s practices to avoid "git push --force" - whether it’s "-with-Lease" or not.

git provides a lot of flexibility and different ways of working to really, the only point where it might be interesting to "push --force" is when you’re "rebasing" a branch - that is, updating a separate development branch from the master branch, but so that the master commits that occurred after the current development branch split are all in the "base", not as a separate commit within the current branch.

In practice, I have not yet worked with any real project that has a level of maturity and/or complexity of the branchs such that the "rebase" really if they were necessary - the use of "merge", avoiding rebase may well be enough, and avoid the "push force".

Otherwise, with the proper use of branchs and merge policies back into the main branch, I don’t see why to use "push --force"