-1

I'm git newbie, that's what I've done: I've got working ngnix server with git hook, to which I'm pushing my project by: git push production master command.

Now I pushed my set1 commit to the server, and later on I revert it hard on my computer, so I try to push again previous version: set0

My server respond me with:

To ssh://website/var/repo/site.git ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'ssh://root@website/var/repo/site.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

What should I do now? I want to revert hard my set1 changes on server.

My configuration on server is in post-receive file: #!/bin/sh git --work-tree=/var/www/laravel --git-dir=/var/repo/site.git checkout -f

but no active repository is there. Thank you for help!

gileneusz
  • 1,435
  • 8
  • 30
  • 51
  • 1
    'git push -f' should do the trick, but you have to be careful when rewriting history which exists on a remote repository, it is considered in most of the cases bad practice. – Christos Batzilis Jun 14 '18 at 11:33
  • `git reset --hard` overwrite `git history` so that it will not allow you to push. you have to force push to git. use `git push origin master -f` – dr. strange Jun 14 '18 at 11:52

1 Answers1

1

The error is shown because your local branch is now out of sync from the server due to last commit mismatch.

Hence, as you want to push after reverting the last commit, use the following command:

git push production master -f

-f means force push irrespective of commit hash mismatch.

Edit: Also, you could use --force-with-lease to be on safer side before pushing i.e.

--force-with-lease effectively only allows you to force-push if no-one else has pushed changes up to the remote in the interim. It's --force with the seatbelt on.

If you are interested to understand it further, read this beautiful explanation of same

Vinay Prajapati
  • 7,199
  • 9
  • 45
  • 86
  • this is a good solution, and it works! Thank you – gileneusz Jun 14 '18 at 11:34
  • Also good to know that we **must** prefer (and take the habit) to use `--force-with-lease` instead of `-f` or `--force` that add a security that should prevent to unintentionally loose commits pushed by other developer. – Philippe Jun 14 '18 at 12:11
  • If you want to be on safer side and think `git history` matters for your use --force-with-lease. Updating my answer. – Vinay Prajapati Jun 14 '18 at 13:19