I have a problem when manipulating git pull. Consider I have 2 branches on my remote (origin) repository : A and B.

The remote B branch is ahead of the local B branch by 1 commit.

This additional commit (on the remote B branch) just add a new file, say "newfile".

In my local branch A, I have a file "newfile" and its content is different from the one of the remote B branch.

Then, I run this commands:

git checkout A
git pull origin B:B

I can see the following behavior: the branch B is updated as I expected. B has been fast-forwarded, and then contains "newfile". But I also have a conflict on "newfile". and in my current directory, the file "newfile" contains the conflicts markers.

Why is there a conflict while the merge has already been done ?

Thank you.

2 Answers 2


When you do a pull, (by default) it gets everything that it can without overwriting any changes you have made. Anything that it could not get because it would have had to modify your edit is considered a conflict. Conflicts need to be resolved manually, or you can undo your changes and do another pull. Once you complete your merge, you can do a push to commit your change.

This is the default behavior because think of how bad this could be if it didn't do this- your changes could be blown away by a pull without your permission.

  • when I run "git pull origin B:B" I expect that the remote branch B be merged into my local branch B. In this case, fast-forward merge is possible, and it is successfully done ! But why there is still a conflict ? The conflict is between the remote B version of "newfile" and the local A (my current branch) version of "newfile". But I don't expected that the current branch (A) will interfert in the pull operation. why is it the case ?
    – nuggets
    Jan 2, 2015 at 17:41

I think I misunderstood the semantics of git pull. I thought that :

git pull origin B:B

meant :

fetch the remote B 
merge the remote B into the local B

I realize that it means :

fetch the remote B and updates (if fast-forward is possible)  the local B
merge the remote B into the local branch

In fact git pull will always make its merge into the local branch, independently of the refspec.

In other words, pull = fetch + merge. The update of the local B branch is done by "fetch", and the conflict is generated by the following merge operation (into the local branch).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.