![]() Though probably your colleagues will all notice that something has gone terribly wrong in short order. If you have already done so, please notify a colleague so that lost work can be recovered. Please, please, do not use git push -force origin master. 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. 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. They will have to force-pull this new master branch over their own. 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. You overwrite the global common history of that repository. Here is what happens when you do git push -force origin master. You can see what remotes have what names using git remote -v. Do not use git push -force origin masterĮDIT: This is all assuming that your remote origin is the source repository, not your own 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. Then the correct command might be git push -force fork master if your fork’s remote is named fork. ![]() It is never acceptable to do this with master.ĮDIT: Unless! Unless it is master on your own fork. Since I am the only person who works on this branch, it is acceptable for me to do git push -force origin my-feature 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). 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. There is no one else working on your branch, but you have rebased your branch onto origin/master None of those ways involve force and none of them involve master. # work), and puts your new commits on topĪmong other ways. # from origin/OCLOMRS-890 (which includes your collaborator's # updates your local OCLOMRS-890 to have the history of commits This can be accomplished with # update origin/OCLOMRS-890 on your computer to exactly what's If someone else has pushed something to the branch, you need to pull in their changes before you can push your changes. There are other people working on the branch There are two reasons this is likely to happen. 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. Thanks yes my opinion is: please don’t do 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.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |