TortoiseGit Manual

During a merge, the working tree files are updated to reflect the result of the merge. Once in a while, you will get a conflict when you merge another branch, cherry-pick commits, rebase or apply a stash: Among the changes made to the common ancestor's version, non-overlapping ones (that is, you changed an area of the file while the other side left that area intact, or vice versa) are incorporated in the final result verbatim. When both sides made changes to the same area, however, Git cannot randomly pick one side over the other, and asks you to resolve it by leaving what both sides did to that area. Whenever a conflict is reported you need to resolve it!

The conflicting area is marked in the file like this (also cf. git-merge(1) man-page):

<<<<<<< yours
    your changes
=======
    changes from the code merged
>>>>>>> their

You can use any editor to manually resolve the conflict or you can launch an external merge tool/conflict editor with TortoiseGit → Edit Conflicts. Then TortoiseGit will place three additional files in your directory for the selected conflicted file and launch the configured conflict editor:

Afterwards execute the command TortoiseGit → Resolved and commit your modifications to the repository (if the conflict occurred while rebasing or cherry-picking make sure you use the cherry-pick resp. rebase dialog for committing and not the normal commit dialog!). 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). In order to resolve the conflict use TortoiseGit → Resolve... and then right click on the conflicted file and choose one of Resolved (the current version of the file which is in the working tree will be used), Resolve conflict using 'mine' (the version of the file of your HEAD will be used), and Resolve conflict using 'theirs' (the version of the file of the merged revision/branch will be used). After that commit.

You can use the Resolved command for multiple files if you right click on the parent folder and select TortoiseGit → Resolve... 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.62. The resolve conflicts dialog

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.63. 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.64. 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 committing the parent working tree).