4

What are the pros and cons of reset + force push vs revert. When each of those Technics appropriate?

This question is different from What's the difference between Git Revert, Checkout and Reset? because I want to know in more details about force push.

Community
  • 1
  • 1
Ilya Gazman
  • 31,250
  • 24
  • 137
  • 216

1 Answers1

7

Reset + force push

Pros: changes commit history which can be of help to clean up if you accidentally pushed a commit that should not have been pushed.

Cons: changes commit history which can screw up other developer's clone of the repo. If you force push something you will have to notify all other developers of what you did so they can take appropriate action to fix their local repo if needed. It is commonly advised to not do force pushes in teams with multiple developers. If you work alone however, this is of no concern and you can use it freely. Reset also erases the work from the history, meaning you probably will not be able to restore it later.

Revert

Pros: does not change commit history. Pros here are basically the opposite of the cons of reset + force push. Keeps the commit in history, should it ever need to be restored (you can revert a revert). Does not mess with other developer's clone of the repo.

Cons: any sensitive data commited will reside in your git history.

mrpandey
  • 627
  • 2
  • 9
  • 17
Tim
  • 41,901
  • 18
  • 127
  • 145
  • 3
    Cons for revert might be that if you commited some sensitive data it will forever be in your git history. – crea1 Oct 20 '15 at 08:07
  • @crea1 true, but sensitive data shouldn't have been committed in the first place – Tim Oct 20 '15 at 08:08
  • quick question, say I have commits A,B,C, where C is an Accidental commit. All other developers have A,B . Can i do a reset and not affect everyone else's clone? – javip Feb 14 '19 at 21:51
  • @javip yes you can – Tim Feb 14 '19 at 21:54
  • Are all cons averted in my case? – javip Feb 14 '19 at 21:57
  • Rather late to the party but: A reset + force push MAY NOT REMOVE sensitive data from a distribution point of view. There may be other locations where a ref to the sensitive data is still hold (eg. forks, MRs, caches, not yet gc'ed). Always regenerate sensitive data! – Martin B. Feb 01 '22 at 17:14