2

Let's say I make a branch off master and make some commits to my branch, commit1, commit2. In the meantime, two other people merge two pull requests to master, hence my branch would be 2 commits behind. If I make some change and do git push -f on my branch, will this delete the last two pull requests from master?

Also, is it possible to see how did two commits get deleted from master using Github? Is there any logging/history kept for this purpose? Thank you for any answers.

love
  • 1,000
  • 2
  • 16
  • 35
Tad
  • 838
  • 2
  • 11
  • 22

3 Answers3

2

git push -f takes your local copy, and forces it to the remote, NO MATTER WHAT. The remote becomes an exact copy of your local branch. What this means is that everything on the remote branch and not on your local branch, will be erased; there is no undoing this. The -f flag should never be used unless you are purposefully re-writing history.

It is not possible to "delete" commits. You can only write over them using a '-f' which re-writes history. Therefore, if something is gone due to a -f it will never come back. It is lost forever. In other words, there is no way to see the history in github because your history has been re-written.

From the spec

-f

--force

Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. Also, when --force-with-lease option is used, the command refuses to update a remote ref whose current value does not match what is expected.

This flag disables these checks, and can cause the remote repository to lose commits; use it with care.

Note that --force applies to all the refs that are pushed, hence using it with push.default set to matching or with multiple push destinations configured with remote.*.push may overwrite refs other than the current branch (including local refs that are strictly behind their remote counterpart). To force a push to only one branch, use a + in front of the refspec to push (e.g git push origin +master to force a push to the master branch). See the <refspec>... section for details.

Nick Humrich
  • 14,905
  • 8
  • 62
  • 85
  • I see, and by local copy you mean everything, not just the branch it is executed over? Thanks! – Tad Aug 27 '14 at 15:47
  • @Tad No, only the branch. (unless the branch is master) – Nick Humrich Aug 27 '14 at 15:48
  • Somehow for me, even when I did git push -f on a branch which was 2 commits behind, the 2 commits from master disappeared. If it was not this, do you know what else might have caused it? – Tad Aug 27 '14 at 16:55
  • @Tad It was still probably the `-f` tag because force can also change references. Force can cause some seriously strange behaviour. I added a note in my answer from the spec. Note the last paragraph – Nick Humrich Aug 27 '14 at 17:04
  • As mentioned, `-f` overwrites refs. If you were two commits behind, it means you overwrote those commits. You should have either rebased your branch before overwriting the remote with a force push... – Charles D Pantoga May 30 '18 at 20:58
2

I beg to differ with @Humdinger from personal experience. As mentioned on What is the difference between git push.default=current and push.default=upstream?, push.default setting can change the behaviour of git push. For instance, if push.default=matching, git push causes all branches to be pushed, i.e., all branches having the same name in both ends are considered to be matching.

In your case, if you have push.default=matching and if your clone is two commits behind the master, you will be overwriting the master branch AS WELL AS the remote branch (assuming branch != master) even though you just wanted to push the changes on your branch. Having push.default=upstream should avoid this issue.

Community
  • 1
  • 1
laylaylom
  • 1,754
  • 16
  • 15
0

No, pushing your branch will not affect master, even if you use -f.

rjmunro
  • 27,203
  • 20
  • 110
  • 132