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→ 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
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 command, then commit your version.
You can use thecommand for multiple files if you right click on the parent folder and select → This will bring up a dialog listing all conflicted files in that folder, and you can select which ones to mark as resolved.
In Git (unlike SVN) you have to commit after resolving 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.
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, ...).
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).