34

I run into a Git merge conflict which I have seen before.

>git pull origin dev
From https://scm.starbucks.com/roastery-milan/choreographer
 * branch            dev        -> FETCH_HEAD
CONFLICT (modify/delete): <file name omitted> deleted in HEAD and modified in 01b734b9ae8594f03f5e481b123d80e41fb54d7c. Version 01b734b9ae8594f03f5e481b123d80e41fb54d7c of <file name omitted> left in tree.
...
Automatic merge failed; fix conflicts and then commit the result.

When I look at those conflicted files, I don't see any indication of conflicts. I guess that I need to change the Git HEAD. But, how to do so?

BTW, our GitHub has some changes recently and there are more branches for staging.

Update: Thanks everyone for your inputs. Now, I know how to deal this problem.

vic
  • 2,156
  • 5
  • 37
  • 66
  • Does it actually say file name omitted or did you do that? Let's say the file name is name.html. You can go and try to remove it. git rm name.html I can't tell based on this what is going on. Also, it says you have seen this before or did you mean that you haven't seen this before? – donlaur Jan 16 '18 at 19:44
  • `git reset --hard` – hellyale Jan 16 '18 at 19:50
  • Possible duplicate of [git - merge conflict when local is deleted but file exists in remote](https://stackoverflow.com/questions/4319486/git-merge-conflict-when-local-is-deleted-but-file-exists-in-remote) – IMSoP Jul 19 '19 at 09:30

5 Answers5

40

The message says that you deleted a file in your current branch and someone else modified it in the branch you are pulling. You need to decide what to do with the file.

If you want to keep the file

$ git checkout <filename>
$ git add <filename>
$ git commit

If you want to discard the file

$ git rm <filename>
$ git commit

If the file was moved, you need to copy the changes over to the new location.

Code-Apprentice
  • 76,639
  • 19
  • 130
  • 241
  • 5
    If I want to keep the file, `git checkout` not work, it shows this file is unmerged – Yitong Feng Jun 23 '21 at 07:08
  • @YitongFeng I had the same problem. I ignored the `checkout` error. I did `git add ` and then `git commit` twice. The second time worked. I don't know why since I did them back to back. – mikey Jan 04 '22 at 11:37
  • @YitongFeng This sounds like a new question. If you still need help, click the Ask a question button. You can add a link to this question in your new one to help give context. – Code-Apprentice Jan 04 '22 at 16:18
9

It looks like there was a file that you had deleted locally, but was modified remotely:

CONFLICT (modify/delete): deleted in HEAD and modified in 01b734b9ae8594f03f5e481b123d80e41fb54d7c.

This is because HEAD refers to your local environment, and 01b73 is the SHA of the tip of the branch you are merging in (via the pull).

So, Git doesn't know whether to delete the file or to keep it.

You should first verify if you want to keep the file or not. This will be either staging the file if you want to keep it (add) or removing the file (rm).

Finally, create a commit to resolve the conflict.

Jonathan.Brink
  • 21,521
  • 16
  • 66
  • 107
8

The fundamental definition of a conflict is that you touched some source line(s) that they also touched. For instance, given:

original line (in base): He said, "Hello world!"
your replacement:        He said, "Hello wonderful world!"
their replacement:       He said, "Goodbye cruel world!"

which line should Git keep, and which one should it discard, or should there be a third outcome entirely? Git does not know, so it leaves the task to you.

In this case, your ("HEAD") change was to remove every line by removing the entire file. Their change was to modify some line(s) of the file. Git doesn't know what to do: should it delete the entire file like you did? Should it keep their modified version? Or, perhaps there is some third way to deal with the problem.

It's generally easier to delete everything again than it is to reconstruct their version (although it's not really that hard either way), so Git leaves their version in the work-tree. If that's the correct answer, you can simply git add the file to tell Git: use that version. If deleting the file entirely is the correct answer, git rm the file to tell Git: delete the file entirely. If there's some third correct answer, edit the file as necessary to put in the correct contents, and git add the file to tell Git: use that version.

In any case, you have now resolved this particular file's conflict (once you have git add-ed or git rm-ed the appropriate final result). Resolve other conflicts if necessary, then finish the merge:

git commit

or (since Git version 2.12):

git merge --continue
torek
  • 389,216
  • 48
  • 524
  • 664
7

I believe this situation arises when one side of the merge tree has deleted the file, and the other has modified it.

The solution is to either:

1) Delete the file ('git rm ...') which will give you a bad-sounding message, but will correctly delete the file when committed.

2) (I believe) Add the file ('git add ...') and then commit it.

It's up to you to decide which you need based on your desired outcome.

Laereom
  • 591
  • 6
  • 12
  • Thanks! by doing "git add . " wasn't working till I removed the actual files after keeping a backup, continued rebase and then added those files again in a separate commit after successful rebase. – QauseenMZ Mar 06 '20 at 21:10
  • Thanks! I did not think to ignore the message and `git rebase --continue`. (The problem is the same with rebase or merge.) – benjifisher Jan 11 '21 at 16:45
0

This worked for me https://stackoverflow.com/a/41486339/13676084 , and it's well explained. Follow the steps orderly as mentioned there.

Sten Techy
  • 31
  • 4