Why does git say "Pull is not possible because you have unmerged files"?

Question

When I try to pull in my project directory in the terminal, I see the following error:

harsukh@harsukh-desktop:~/Sites/branch1$ git pull origin master
U app/config/app.php
U app/config/database.php
U app/routes.php
Pull is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>'
as appropriate to mark resolution, or use 'git commit -a'.

Why does git say "Pull is not possible because you have unmerged files", and how can I resolve it?

Solution 1

What is currently happening is, that you have a certain set of files, which you have tried merging earlier, but they threw up merge conflicts. Ideally, if one gets a merge conflict, he should resolve them manually, and commit the changes using git add file.name && git commit -m "removed merge conflicts". Now, another user has updated the files in question on his repository, and has pushed his changes to the common upstream repo.

It so happens, that your merge conflicts from (probably) the last commit were not not resolved, so your files are not merged all right, and hence the U(unmerged) flag for the files. So now, when you do a git pull, git is throwing up the error, because you have some version of the file, which is not correctly resolved.

To resolve this, you will have to resolve the merge conflicts in question, and add and commit the changes, before you can do a git pull.

Sample reproduction and resolution of the issue:

# Note: commands below in format `CUURENT_WORKING_DIRECTORY $ command params`
Desktop $ cd test

First, let us create the repository structure

test $ mkdir repo && cd repo && git init && touch file && git add file && git commit -m "msg"
repo $ cd .. && git clone repo repo_clone && cd repo_clone
repo_clone $ echo "text2" >> file && git add file && git commit -m "msg" && cd ../repo
repo $ echo "text1" >> file && git add file && git commit -m "msg" && cd ../repo_clone

Now we are in repo_clone, and if you do a git pull, it will throw up conflicts

repo_clone $ git pull origin master
remote: Counting objects: 5, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /home/anshulgoyal/Desktop/test/test/repo
 * branch            master     -> FETCH_HEAD
   24d5b2e..1a1aa70  master     -> origin/master
Auto-merging file
CONFLICT (content): Merge conflict in file
Automatic merge failed; fix conflicts and then commit the result.

If we ignore the conflicts in the clone, and make more commits in the original repo now,

repo_clone $ cd ../repo
repo $ echo "text1" >> file && git add file && git commit -m "msg" && cd ../repo_clone

And then we do a git pull, we get

repo_clone $ git pull
U   file
Pull is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>'
as appropriate to mark resolution, or use 'git commit -a'.

Note that the file now is in an unmerged state and if we do a git status, we can clearly see the same:

repo_clone $ git status
On branch master
Your branch and 'origin/master' have diverged,
and have 1 and 1 different commit each, respectively.
  (use "git pull" to merge the remote branch into yours)

You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both modified:      file

So, to resolve this, we first need to resolve the merge conflict we ignored earlier

repo_clone $ vi file

and set its contents to

text2
text1
text1

and then add it and commit the changes

repo_clone $ git add file && git commit -m "resolved merge conflicts"
[master 39c3ba1] resolved merge conflicts

Solution 2

If you dont want to merge the changes and still want to update your local then run:

git reset --hard HEAD  

This will reset your local with HEAD and then pull your remote using git pull.

If you've already committed your merge locally (but haven't pushed to remote yet), and want to revert it as well:

git reset --hard HEAD~1 

Solution 3

You are attempting to add one more new commits into your local branch while your working directory is not clean. As a result, Git is refusing to do the pull. Consider the following diagrams to better visualize the scenario:

remote: A <- B <- C <- D
local: A <- B*
(*indicates that you have several files which have been modified but not committed.)

There are two options for dealing with this situation. You can either discard the changes in your files, or retain them.

Option one: Throw away the changes
You can either use git checkout for each unmerged file, or you can use git reset --hard HEAD to reset all files in your branch to HEAD. By the way, HEAD in your local branch is B, without an asterisk. If you choose this option, the diagram becomes:

remote: A <- B <- C <- D
local: A <- B

Now when you pull, you can fast-forward your branch with the changes from master. After pulling, you branch would look like master:

local: A <- B <- C <- D

Option two: Retain the changes
If you want to keep the changes, you will first want to resolve any merge conflicts in each of the files. You can open each file in your IDE and look for the following symbols:

<<<<<<< HEAD
// your version of the code
=======
// the remote's version of the code
>>>>>>>

Git is presenting you with two versions of code. The code contained within the HEAD markers is the version from your current local branch. The other version is what is coming from the remote. Once you have chosen a version of the code (and removed the other code along with the markers), you can add each file to your staging area by typing git add. The final step is to commit your result by typing git commit -m with an appropriate message. At this point, our diagram looks like this:

remote: A <- B <- C <- D
local: A <- B <- C'

Here I have labelled the commit we just made as C' because it is different from the commit C on the remote. Now, if you try to pull you will get a non-fast forward error. Git cannot play the changes in remote on your branch, because both your branch and the remote have diverged from the common ancestor commit B. At this point, if you want to pull you can either do another git merge, or git rebase your branch on the remote.

Getting a mastery of Git requires being able to understand and manipulate uni-directional linked lists. I hope this explanation will get you thinking in the right direction about using Git.

Solution 4

Theres a simple solution to it. But for that you will first need to learn the following

vimdiff

To remove conficts, you can use

git mergetool

The above command basically opens local file, mixed file, remote file (3 files in total), for each conflicted file. The local & remote files are just for your reference, and using them you can choose what to include (or not) in the mixed file. And just save and quit the file.

Solution 5

If you want to pull down a remote branch to run locally (say for reviewing or testing purposes), and when you $ git pull you get local merge conflicts:

$ git checkout REMOTE-BRANCH
$ git pull  (you get local merge conflicts)
$ git reset --hard HEAD (discards local conflicts, and resets to remote branch HEAD)
$ git pull (now get remote branch updates without local conflicts)

View more solutions

Comments

[Akhzar Nazir]

In My case i have just use these commands "git add ." then "git commit -m "Test" and in the end "git push". Error removed

[find_X]

You simply needed to add "$ git add <file>"...to update what will be committed or restore (to discard changes in working directory) then commit "$ git commit ", then "$git push" to conclude merge.

[ouonomos]

In case it helps: I have noticed that just doing "git add ." then committing did not work. I had to add the individual file by name, then commit and pull/push.

[Nick]

Merging combines the contents of two files. Currently your local files differ from the ones on the remote server. Merging must be done on the remote server. So if you stage your edited files and push them, your changes will be added to the files on the repository. Then your files will be in sync and you can pull the entire project with other changes. I found the git help book very helpfull when I started using git. You can find it here: git-scm.com/book/en/Getting-Started

[jub0bs]

Note that I'm not the OP. "Merging files" is improper terminology. Strictly speaking, you merge commits, not files.

[Nick]

Ah yes that is true, my apoligies. I was trying to give a simple answer

[Edward Thomson]

Well, if you have conflicts when merging a commit, then yes, you will have conflicting, unmerged files and you will need to merge them.

[undeniablyrob]

I would say that vimdiff is not required (you can use any merge/diff tool of your choice, such as WinMerge, or OSX's built-in FileMerge, etc.). Having said that, this is a great addition to @mu's answer.

[undeniablyrob]

To be complete, I would add @Pawan's answer to use 'git mergetool' to resolve conflicts. The second-to-last step may not be very practical ("resolve the merge...[by setting]...its contents to: [some text]").

[undeniablyrob]

Alternatively, you can merge using @user261's advice. Either way, I think adding a step on how to merge in a practical sense would complete this answer.

[Vaughn D. Taylor]

This answer works really well when you have simple conflicts to fix on single files. For example, one or two lines of code that are different. If you have multiple files that have been modified heavily, this is a difficult fix. But it drives home the idea that with Git you should commit often to avoid difficult conflicts.

[Joseph Budin]

You should explain what the command does, because some people will be very disappointed if they try and find out that it deleted all of their current local changes :/

[cwiggo]

This works if you just copy your changes to an external temporary source.. if you've only got a couple of files for example config files for a project it's perfect. Carry out the command and then revert your changes. Works for me!

[sandeepnegi]

what if i want to go back to the repo stage before the conflict.