Application Name: on project Open Concept Lab
Question: every time I try to push my code to my git repo it gives this error
my local repo is also up to date I don’t know, from when I started using “git stash” the problem started to occure
Application Name: on project Open Concept Lab
Question: every time I try to push my code to my git repo it gives this error
my local repo is also up to date I don’t know, from when I started using “git stash” the problem started to occure
I want to believe when you do git status
it says you are a head of origin
by 1 commit (which makes sense) and if you follow the hint and run git pull
, it says everything is up to date. I think this is because you are pushing to a different branch than your upstream branch. you can fix this issue by running:
git push --f origin master
Whenever you do a rebase you would need to do a force push because the remote branch cannot be fast-forwarded to your commit.
Thanks @herbert24 yes my opinion is: please don’t do that.
@nkumar The problem you are seeing is not caused by your “pushing to a different branch than your upstream branch.” The problem is exactly that origin/OCLOMRS-890
has a different history from your local OCLOMRS-890
. If you do git log OCLOMRS-890
and git log origin/OCLOMRS-890
, you will see some difference in the commits that come before the ones you are trying to push.
There are two reasons this is likely to happen.
If someone else has pushed something to the branch, you need to pull in their changes before you can push your changes. This can be accomplished with
# update origin/OCLOMRS-890 on your computer to exactly what's
# in that branch on GitHub
git fetch
# updates your local OCLOMRS-890 to have the history of commits
# from origin/OCLOMRS-890 (which includes your collaborator's
# work), and puts your new commits on top
git rebase origin/OCLOMRS-890
among other ways. None of those ways involve force
and none of them involve master
.
In my personal git workflow, when on a feature branch my-feature
, I use git fetch; git rebase origin/master
to update my feature branch with respect to the remote master
. This causes my local my-feature
branch to have a different history than the remote feature branch (it has the history based on a new version of master
, while the remote has a history based on an old version of master
). Since I am the only person who works on this branch, it is acceptable for me to do
git push --force origin my-feature
in order to update the branch remotely. It is never acceptable to do this with master
.
EDIT: Unless! Unless it is master
on your own fork. Then the correct command might be git push --force fork master
if your fork’s remote is named fork
. This would be if you’re treating the master
branch of your forked repo as a feature branch, which is a little odd, and which prohibits working on multiple features at the same time. Just use feature branches.
git push --force origin master
EDIT: This is all assuming that your remote origin
is the source repository, not your own fork. You can see what remotes have what names using git remote -v
.
Here is what happens when you do git push --force origin master
. You overwrite the global common history of that repository. When your collaborators do git pull
(or equivalently git fetch && git merge origin/master
), they will be surprised to find that their master
branch history and origin/master
have diverged. They will have to force-pull this new master
branch over their own. All their feature branches will therefore also have diverged in history from this new, strange version of master
that you have imposed on everyone else. Most importantly, you will probably have wiped out someone else’s work that they merged in before you, and your colleagues will have to try and figure out which commits from where you have wiped out, and may have to dig into the toolbox of arcane git commands that you only have to use when someone has done something very wrong.
Please, please, do not use git push --force origin master
. If you have already done so, please notify a colleague so that lost work can be recovered. Though probably your colleagues will all notice that something has gone terribly wrong in short order. Thanks.
CC @jwnasambu , @ruhanga , @gracebish
PS: Here’s my git workflow, maybe it can help. It covers 99% of what I do with git.