0

On my local repo I have commits 1 through 110. The remote repo starts out at 1 - 109. In the intervening time, another person on the team pushed a commit to remote. Now 1-110 also. Pushing my local branch to github gets:

failed to push some refs to 'https://github.com/theProject.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally.

So, I addressed the issue of commit 110 in an equivalent manner in my local commit (110) Therefore, I should want to push as if the remote 110 never was appended. Can I delete the commit on github to avoid collision? Or is there a way that git handles this more gracefully?

Alex Bollbach
  • 4,370
  • 9
  • 32
  • 80
  • Possible duplicate of [What does "Git push non-fast-forward updates were rejected" mean?](http://stackoverflow.com/questions/4684352/what-does-git-push-non-fast-forward-updates-were-rejected-mean) – sleske Feb 05 '16 at 07:54
  • That's a standard git feature - you can only push after fetching all updates from the repo. Read the linked duplicate, or http://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows , specifically the part about "non-fast-forward changes ". – sleske Feb 05 '16 at 07:56

2 Answers2

1

Just do git pull to fetch and merge the last commit from your remote to your local directly. If a merge conflict happens, resolve it manually, then git push origin.

If that another person don't mind you stealing credit, you might be able to just force push with git push -f origin.

Roy Wang
  • 11,112
  • 2
  • 21
  • 42
  • what is the point of pulling? did i make it clear that i wish to delete commit 110 on the remote repo and replace it with commit 110 from my local? essentially, i will pull it in and do nothing with it. – Alex Bollbach Feb 05 '16 at 09:08
  • If you pull it then the commit will be credited to the original user and you can still push your own changes to the remote after you pull. I offered the alternative solution `git push -f origin`, which will replace your remote commit history with your local one, essentially deleting commit 110 on the remote. – Roy Wang Feb 05 '16 at 09:11
0

When this situation happens (and it happens all the time), the correct thing to do is not to try to make your 110 match his 110. Instead, do a git pull, which will create a commit that has both your 110 and his 110 as parents, then push that commit. Once his 110 was pushed onto the remote repo, you may consider it as "set in stone". Don't mess with forced pushing, that will only get you into more trouble.

David Deutsch
  • 17,443
  • 4
  • 47
  • 54