

You can use the Resolved command for multiple files if you right click on the parent folder and select 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). In order to resolve the conflict use TortoiseGit → Resolve. The local file remains unchanged (exactly as you last changed it). If you have conflicts with binary files, Git does not attempt to merge the files itself. It uses "git add" to mark file status as resolved to allow you to commit your changes and it removes the, and files. Please note that the Resolve command does not really resolve the conflict. rebase dialog for committing and not the normal commit dialog!). Just for completeness "theirs" means for "stash"/"merge"/"pull"/"cherry-pick" the version of the to be merged commit/branch and for "rebase" the version of the branch you rebase onto.Īfterwards 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. As you want to merge other changes, this state/version is often also called "theirs". This is the version of file of the revision you want to merge (on a normal merge this correspondents to MERGE_HEAD). Just for completeness "mine" means for "stash"/"merge"/"pull"/"cherry-pick" the HEAD version in your working tree and for "rebase" the version on the branch you rebase.

Therefore, this state/version is often also called "mine". This is your file as it existed in your working tree before you started the merge (i.e., the file conforms to the latest committed state of the HEAD of your local repository) - that is, without conflict markers. This is the common ancestor's version of the conflicted file (this version does contain neither any of your nor any of the changes of the to be merged branch/revision, especially it does not contain any conflict markers). Then TortoiseGit will place three additional files in your directory for the selected conflicted file and launch the configured conflict editor: You can use any editor to manually resolve the conflict or you can launch an external merge tool/conflict editor with TortoiseGit → Edit Conflicts. the section called “HOW CONFLICTS ARE PRESENTED”): The conflicting area is marked in the file like this (also cf. Whenever a conflict is reported you need to resolve it!

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.

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. During a merge, the working tree files are updated to reflect the result of the merge.
