GitHub更新被拒绝，因为当前分支的提示位于其远程对应的后面

Question

I suppose I get the basics of GitHub - I understand initializing a repository on my local machine, committing, pushing, pulling, cloning, etc. But when it comes to branches and such, I am completely lost.

Right now I'm trying to push my most recent version of a project, and I can't. The following things are true:

1. the repository on the website is mine and I am the only collaborator on this project;

2. this site is my portfolio. I've only ever created the master branch, but there is a "developing" branch that I did not create, but I assume that is default when you create a portfolio on GitHub Pages.

3. I've pushed to this project several times before, and it is always a problem.

As I said, I'm trying to push my most recent version. Here is what happens:

I check the branch that I'm in, and it says I'm in "master". I add, commit, and try to push through my terminal. It asks me for my username and password, I put them in, and it returns:

! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/...(my portfolio      address)...io.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.

So then I tried to pull, and received this:

There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

   git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

  git branch --set-upstream-to=origin/<branch> master

I don't understand this. What exactly does it mean to be behind a branch? I thought I understood that but clearly I don't. And even if I got it, how can my own branch be behind itself? I've never pushed to any other branch!

Answer 1

Based on the comments, it sounds like you have made a mess here that you will have to clean up one way or another. However, the immediate solution to the immediate problem:

 There is no tracking information for the current branch. 

is the one Git is telling you to do:

 git branch --set-upstream-to=origin/<branch> master 

In particular, you obviously want origin/master set as the upstream for master :

git branch --set-upstream-to=origin/master master

Now all three commands— git pull , ¹ git merge , and git rebase —will know that you want to keep your master in sync with your Git's memory of some other Git's master .

Your Git, at certain points (when you tell it to), connects to origin , finds out what they have in their master, brings over anything required, and sets your origin/master to remember this. The main point of contact is you running git fetch or git fetch origin (if you leave out the origin , Git figures out which remote you mean to use, or guesses origin if all else fails).

Once you have the updated memory, you can compare what you have (your master ) to what your Git remembers that they have (your origin/master ). If it's time to do so, you can git merge or git rebase your master, to merge or rebase using (your memory of) theirs.

You may get merge conflicts! These are normal: they just mean that you changed something in some file, and they (whoever they are) changed something in the same file, and both of you touched the same lines of that file, but you and they did different things to the lines. Git doesn't know whether you're smarter than they are, or they are smarter than you are, or what. It just puts both changes into your file and makes you clean up the mess. You must now edit the conflicting file(s), put the right lines into them, and save them back to the work-tree; then git add and git commit the final results of all the merging.

(If you use git rebase instead of git merge , you will still get merge conflicts, but once you have resolved them and git add -ed the files, you should run git rebase --continue instead of git commit . See many other SO questions and answers on merge and rebase.)

---

I recommend avoiding git pull because it does too much: it first runs git fetch for you, then runs git merge for you. (Or it runs git rebase for you instead of git merge , if you tell it so.) Now, it's true that after git fetch , you very often want to run one of these other two commands ... but you don't necessarily want to run it right away . And, you have two commands to try: how do you know which one you want? And if things go wrong—which they do—how do you know which command's help to look for? If you run the merge or rebase yourself, you have the answers to all of these. This is why I say: forget about git pull , just stick with git fetch and whichever other second command you prefer.