Resolving Git Merge Conflicts in Windows Explorer with TortoiseGit

The problem: red icons and a merge you don't want to fix in a terminal

You pull a teammate's branch into your local main, and Windows Explorer suddenly marks a file with a red icon. TortoiseGit uses shell extensions to overlay Git status directly on files and folders, so red means a merge conflict: Git stopped auto-merging and left conflict markers in the file. You could open Git Bash and edit conflict markers by hand, but if your team prefers a visual diff, you can stay in Explorer.

Takeaway: TortoiseGit lets you resolve conflicts and commit from the Windows context menu, but you must register TortoiseGitMerge as Git's merge tool first, and you still need to know what a conflict means before you mark a file resolved.

Configure TortoiseGitMerge before you need it

TortoiseGitMerge is bundled with TortoiseGit, but Git does not use it automatically. Open TortoiseGit settings (right-click any folder in Explorer > TortoiseGit > Settings), go to Diff/Merge, and choose TortoiseGitMerge as the merge tool. For repository-specific settings, edit .git/config or use the settings dialog's per-repository options.

Example .gitconfig entries, added in Git Bash or by editing the file directly:

[merge]
    tool = tortoisegitmerge
[mergetool "tortoisegitmerge"]
    cmd = tortoisegitmerge.exe /base:"$BASE" /mine:"$LOCAL" /theirs:"$REMOTE" /merged:"$MERGED"
    trustExitCode = false

Run configuration commands in Git Bash with write access to the repository. The placeholder paths such as $BASE and $MERGED are filled in by Git when the tool launches. Incorrect executable paths will make the merge tool fail to open, so verify that tortoisegitmerge.exe matches your TortoiseGit installation folder.

Worked example: resolve a conflict from Explorer

1. In Windows Explorer, open the repository folder, for example C:\Projects\my-app.
2. Right-click the file with the red conflict icon and choose TortoiseGit > Resolve. This launches TortoiseGitMerge with three panes: theirs, mine, and the merged result.
3. Review each conflicting block, choose the correct side, or edit the merged output directly, then save and close TortoiseGitMerge.
4. Right-click the file again and confirm the icon changed from red to green. Then right-click the folder and choose TortoiseGit > Commit to stage the resolved file, write a message, and create the local commit.

Expected check: after Commit, the file should show a green checkmark and the working tree should appear clean in the TortoiseGit Commit dialog. Risk: closing TortoiseGitMerge without saving leaves conflict markers in the file, and committing anyway records broken code.

Trade-off: the GUI hides Git concepts it cannot replace

TortoiseGit translates every click into standard Git commands, but it does not remove the need to understand detached HEAD, force push, or history rewriting. The Commit dialog can amend the previous commit or add a sign-off, which rewrites local history; that is safe only before you push to a shared branch. Shell extensions also add menu items to every right-click, which can slow down Explorer on very large repositories.

If something goes wrong

Because resolving a merge changes the working tree, you can abort the in-progress merge before committing: right-click the repository folder, choose TortoiseGit > Switch/Checkout, or run git merge --abort in Git Bash. This restores the pre-merge state. To undo the merge-tool configuration, remove the [merge] and [mergetool] sections from .git/config or reset them in TortoiseGit settings.

Closing

Use TortoiseGit's Explorer integration for routine commits and visual conflict resolution, but keep Git Bash nearby for operations the GUI does not expose. Verify the merge tool path, test the flow on a throwaway branch first, and never mark a conflict resolved until the merged file actually compiles.