TortoiseGit Manual

Resolving Conflicts

Once in a while, you will get a conflict when you update your files from the repository. A conflict occurs when two or more developers have changed the same few lines of a file. As Git knows nothing of your project, it leaves resolving the conflicts to the developers. Whenever a conflict is reported, you should open the file in question, and search for lines starting with the string <<<<<<<. The conflicting area is marked like this:

<<<<<<< filename
    your changes
    code merged from repository
>>>>>>> revision

You can launch an external merge tool / conflict editor with TortoiseGitEdit Conflicts or you can use any other editor to manually resolve the conflict. You should decide what the code should look like, do the necessary changes and save the file. For this, Git places three additional files in your directory for the selected conflicted file:


This is your file as it existed in your working tree before you updated your working tree - that is, without conflict markers. This file has your latest changes in it and nothing else.


This is the file that was the BASE revision before you updated your working tree. That is, it the file that you checked out before you made your latest edits.


This is the file that your Git client just received from the server when you updated your working tree. This file corresponds to the HEAD revision of the repository.

Afterwards execute the command TortoiseGitResolved and commit your modifications to the repository. Please note that the Resolve command does not really resolve the conflict. It uses "git add" to mark file status as resolved to allow you to commit your changes and it removes the filename.ext.BASE.ext, filename.ext.LOCAL.ext and filename.ext.REMOTE.ext files.

If you have conflicts with binary files, Git does not attempt to merge the files itself. The local file remains unchanged (exactly as you last changed it) and you have filename.ext.BASE|LOCAL|REMOTE.ext files. If you want to discard your changes and keep the repository version, just use the Revert command. If you want to keep your version and overwrite the repository version, use the Resolved command, then commit your version.

You can use the Resolved command for multiple files if you right click on the parent folder and select TortoiseGitResolve... This will bring up a dialog listing all conflicted files in that folder, and you can select which ones to mark as resolved.

Figure 2.44. The resolve conflicts dialog

The resolve conflicts dialog


In Git (unlike SVN) you have to commit after resolving conflicts.

Special conflict cases

Delete-modify conflicts

A special conflict case is a delete-modify conflict. Here, a file is deleted on one branch and the same file is modified on another branch. In order to resolve this conflict the user has to decide whether to keep the modified version or delete the file from the working tree.

Figure 2.45. Resolve delete-modify conflict Dialog

Resolve delete-modify conflict Dialog

Submodule conflicts

Another special conflict case is a conflict involving a submodule. Here, a submodule is changed in different (conflicting) ways on two branches.

The resolve submodule conflict dialog shows the base, the local and the remote commit of the conflicting submodule as well as the commit type (rewind, fast-forward, ...).

Figure 2.46. Resolve submodule conflict Dialog

Resolve submodule conflict Dialog

Uninitialized submodules

If the submodule is not yet initialized the resolve submodule conflict dialog only shows the commit IDs (SHA-1). Also, the conflict cannot be resolved automatically: First, you have to manually clone the submodule into the right folder. Then, you can resolve the conflict using TortoiseGit or git (by checking out the right commit in the submodule and commiting the parent working tree).