Getting the error "Updates were rejected because the end of your current branch is behind"
My local system code was synced to the remote system in Bitbucket, but there was some problem, so I removed the last commit by running git reset --hard HEAD^
. After that I made some changes and committed those changes. Now when I try to push these changes on the remote I get the following message:
[vagrant@localhost horizon]$ git push
warning: push.default is unset; its implicit value is changing in
Git 2.0 from 'matching' to 'simple'. To squelch this message
and maintain the current behavior after the default changes, use:
git config --global push.default matching
To squelch this message and adopt the new behavior now, use:
git config --global push.default simple
See 'git help config' and search for 'push.default' for further information.
(the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
'current' instead of 'simple' if you sometimes use older versions of Git)
Password for 'https://user_name@bitbucket.org':
To https://user_name@bitbucket.org/user_name/repo_name.git
! [rejected] stable/kilo -> stable/kilo (non-fast-forward)
error: failed to push some refs to 'https://user_name@bitbucket.org/user_name/repo_name.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
My question is, how do I promote such a scenario? Explain, please.
source to share
You ran the following command:
git reset --hard HEAD^
As a result, history is being rewritten. Imagine the following story at the local and remote levels:
Local
A->B->C->D
Remote
A->B->C->D
Now
git reset --hard HEAD^
Some hashes will be overwritten, for example:
Local
A1->B1->C1->D1
Remote
A->B->C->D
So, your story is separate from the remote. What does git mean you need to merge. So, but your next questions will be: What to do to save yourself from this situation? Glad you asked:
1. Note: never reset history and try to push, especially if you press -force!
- The reseller story is great if you know what you are doing.
A possible solution is to undo the commit that you first dropped and push that uncommitted. But in order to do this, you need to revert the "screwed-on" that you reset with git reset
. You can do it with git reflog
and retrieve the SHA-1 commit from it and reset for that commit. Then you are in the state you were in before you committed. Then you do git reset HEAD^
and you are safe!
source to share
The problem with this push --force
is that you will force all other contributors to reset their local repo to the new master / master.
A better alternative might be to use git revert @
(done immediately after cloning and before any new commit) to create a new commit that reverses the current HEAD. Then you can push it without any problem.
source to share