Git Conflict Resolver

A free, browser-based Git conflict resolver and visual merge tool. Paste any file containing Git conflict markers (<<<<<<<, =======, >>>>>>>) to inspect side-by-side diffs between Current (HEAD) and Incoming branches. Select Current, Incoming, Both (Current First), Both (Incoming First), or manually edit the code inline. Supports bulk resolution (Accept All Current or Accept All Incoming), standard 2-way and diff3 3-way conflict markers, rebase commit SHA markers, and syntax-agnostic parsing across JavaScript, TypeScript, Python, Go, Rust, JSON, and YAML. Runs 100% client-side with zero data transmission for maximum security.

JavaScript is required to use this interactive tool. Please enable JavaScript in your browser, or use our Git Conflict Resolver API for programmatic access.

Browse all Text & Data tools →

Popular Text & Data tools

Browse all 12 Text & Data tools →

Git Conflict Resolver is also known as: Git Merge Conflict Resolver, Merge Conflict Tool Online, Git Conflict Marker Parser, Git 3-Way Diff Tool, Online Git Merge Tool, Git Rebase Conflict Resolver.

How to Git Conflict Resolver Online

Copy the raw contents of the conflicting file containing Git markers (<<<<<<<, =======, >>>>>>>) and paste it into the editor.
Click 'Parse Conflicts' or press ⌘↵ (Mac) / Ctrl+Enter (Windows) to instantly extract all conflicting hunks and line positions.
Review each section in the visual side-by-side comparison: inspect 'Current' (HEAD/target) on the left and 'Incoming' (branch/source) on the right.
Choose your resolution strategy per conflict: 'Accept Current', 'Accept Incoming', 'Both (Current First)', 'Both (Incoming First)', or 'Manual Edit'.
Use 'Accept All Current' (⌘⇧A) or 'Accept All Incoming' (⌘⇧I) in the toolbar to bulk-resolve multiple conflicts in one operation.
Inspect the merged output in the 'Resolved Output' panel and click 'Copy Resolved' (⌘⇧C) to copy the clean, marker-free code ready for git add.

Git Conflict Resolver Features

Visual side-by-side diffing: compare 'Current' (HEAD) vs 'Incoming' (feature branch) code side-by-side with clear color highlights.
Automatic conflict marker parser: detects standard 2-way markers, 3-way diff3 markers, and rebase commit hash headers.
Granular resolution options: toggle between Current, Incoming, Both (Current First), Both (Incoming First), or inline custom manual editing.
Bulk resolution buttons: resolve entire files in one click with "Accept All Current" or "Accept All Incoming".
Real-time conflict statistics: tracks total conflict count, clean code sections, line additions, and remaining unresolved blocks.
Syntax & language agnostic: seamlessly resolves JavaScript, TypeScript, Python, Go, Rust, C++, Java, JSON, YAML, and Markdown files.
Fast keyboard shortcuts: speed up resolutions with ⌘↵ (parse), ⌘⇧A (all current), ⌘⇧I (all incoming), and ⌘⇧C (copy output).
100% private & client-side: all parsing and string assembly execute locally in your browser; no source code or proprietary tokens ever touch a server.
Clean output generation: completely strips all conflict markers and metadata headers, leaving pristine file content ready for git commit.
Empty side & deletion handling: properly manages conflicts where lines were deleted or created on only one branch.
Malformed marker detection: alerts you to incomplete marker triplets or corrupted diff chunks before resolution.
Rebase & cherry-pick compatibility: parses branch labels, commit SHAs (7-40 hex chars), and remote tracking branches.

Supported Formats & Dialects

The Git Conflict Resolver supports 6 syntax formats and dialects for accurate parsing and processing.

Standard Git 2-Way Conflict Markers (merge.conflictstyle = merge): The default Git conflict marker format displaying only the current branch (HEAD) and incoming branch versions separated by =======.
Diff3 3-Way Conflict Markers (merge.conflictstyle = diff3): Includes an additional ||||||| section displaying the common ancestor base commit, clarifying what existed before either branch diverged.
Zdiff3 Compact 3-Way Conflict Markers (merge.conflictstyle = zdiff3): Modern Git 2.35+ conflict style that trims common prefix and suffix lines from the ancestor base block, reducing visual noise.
Git Rebase Conflict Markers (Commit SHA Headers): Occurs during git rebase or cherry-pick where the conflict headers contain 7-40 character hexadecimal commit hashes instead of branch names.
Git Stash & Patch Conflict Markers: Generated when applying stashed changes with git stash pop or applying formatted patches with git apply --reject.
Single-Sided Deletion / Addition Conflicts: Conflicts where one side of the marker is completely empty, representing code that was deleted on one branch and modified on the other.

All Guides

developer tools

GitHub Actions YAML Workflow Debugging: The Top 10 Syntax & Runtime Pitfalls

A comprehensive developer guide to identifying and fixing GitHub Actions YAML syntax errors, matrix build bugs, expression interpolation traps, and concurrency race conditions.

Read Field Manual

text data

Mastering Git Merge Conflict Resolution: 3-Way Diff, Diff3 Markers & Rebase Workflows

Resolve Git merge and rebase conflicts with confidence. Master standard vs diff3 conflict markers, 3-way merge logic, and conflict prevention strategies.

Read Field Manual

text data

Visual Text Diffing, Unified Diff Syntax & Git Patch Workflows

Master code diff algorithms (Myers, Patience, Histogram), unified diff patch anatomy (@@ coordinates), side-by-side vs inline comparison, and patch workflows.

Read Field Manual

All Standards

Diff & Unified Diff FormatDeveloper Tools

A diff is a data comparison algorithm and output format displaying line-by-line insertions, deletions, and modifications between text files.

GitHub Actions (CI/CD & Workflow Automation)DevOps

GitHub Actions is a declarative continuous integration and continuous delivery (CI/CD) platform integrated into GitHub that enables automated testing, building, linting, and deployment via YAML workflows.

Merge Conflict (Git & Version Control)Developer Tools

A merge conflict occurs in distributed version control when concurrent, divergent modifications target the same file lines or structure and cannot be resolved automatically.

Pre-built Automation Pipelines

Chain Git Conflict Resolver with other utilities in a multi-step visual workflow.

beginner

encoding

Base64 Decode → JSON Format

Decode a Base64 string and pretty-print the JSON inside it.

Flow:

InputBase64 Encode/DecodeJSON FormatterOutput

4 nodes

beginner

data-transformation

CSV → JSON → YAML

Convert CSV data to JSON, then to YAML format.

Flow:

InputCSV to JSONYAML ConverterOutput

4 nodes

intermediate

development

JSON Format → TypeScript Schema

Format JSON and generate TypeScript/Zod schema from it.

Flow:

InputJSON FormatterJSON to TypeScript & Schema GeneratorOutput

4 nodes

Example Input & Output

Sample Reference

Interactive Example: Git Conflict Resolver in Action

Show example

Sample Input (text)

function greet(name) {
<<<<<<< HEAD
  console.log("Hello, " + name + "!");
=======
  console.log(`Greetings, ${name}!`);
>>>>>>> feature-branch
}

Sample Output

[Processed output for Git Conflict Resolver]
Input transformed successfully using git conflict resolver, merge conflict resolver online, resolve git conflicts online.

What happened:

Visually resolve Git merge conflicts by picking current, incoming, or both versions.

Explore related converters

Frequently Asked Questions

What causes a Git merge conflict and how do conflict markers work?: A Git merge conflict occurs when two branches modify the exact same lines of a file in divergent ways, or when one branch deletes a file that another branch modified. Git cannot automatically decide which change is correct, so it halts the merge and inserts text markers: "<<<<<<< HEAD" marks the start of your current branch changes, "=======" acts as the midpoint divider, and ">>>>>>> <branch>" marks the end of the incoming branch changes.
What is the difference between standard conflict markers, diff3, and zdiff3?: Standard Git markers show a 2-way comparison (Current vs Incoming). In contrast, "diff3" adds a middle section ("||||||| <base>") showing the common ancestor code before both branches made changes. "zdiff3" (available in Git 2.35+) improves diff3 by removing identical prefix and suffix lines from the conflict hunk, significantly reducing visual noise and making it easier to identify the exact modifications.
How do I resolve conflicts during a git rebase versus a git merge?: During a "git merge", HEAD represents your target branch and the incoming section represents the feature branch. During a "git rebase", HEAD represents the commit being replayed on top of the upstream base. After resolving the conflict markers in your file, run "git add <file>" and "git merge --continue" for a merge, or "git rebase --continue" for a rebase. Never run "git commit" directly during a rebase.
What is git rerere and how does it help with repeated conflicts?: git rerere stands for "Reuse Recorded Resolution". When enabled ("git config --global rerere.enabled true"), Git records how you resolved a conflicting hunk. If you rebase frequently or merge long-lived branches that encounter the exact same conflict repeatedly, Git automatically reapplies your previous manual resolution.
When should I choose "Both (Current First)" versus "Both (Incoming First)"?: Choose "Both" when both branches introduced valid, non-overlapping additions (such as appending new items to an array, registering new routes, adding imports, or configuring dependencies). The order depends on sequence requirements: "Current First" preserves the existing branch order, while "Incoming First" prioritizes newly merged logic.
Can this tool resolve binary file conflicts like images or compiled binaries?: No. Git conflict markers are text-based. For binary conflicts (e.g. PNG images, SQLite databases, compiled binaries), Git does not inject marker lines into the file. Instead, you must resolve binary conflicts in your terminal by selecting either "git checkout --ours <file>" or "git checkout --theirs <file>".
How do Git merge strategies like ort and recursive differ?: Git 2.33+ uses the "ort" (Ostensibly Recursive's Twin) merge strategy by default, replacing the legacy "recursive" strategy. ort is significantly faster, resolves renames across directories more accurately, and produces cleaner conflict hunks. However, when conflicts do arise, the marker syntax remains identical.
What should I do if a conflict involves deleted lines on one side?: In deletion conflicts, one side of the conflict marker will be empty. If you want to keep the deletion, accept the empty side (Incoming or Current depending on which branch performed the delete). If you want to keep the original code or modified code, accept the non-empty side or use "Manual Edit" to combine the logic.
Is my proprietary source code sent to any server when using this tool?: No. This resolver runs 100% client-side in your browser using pure JavaScript regex and string parsing. Your source code, API keys, and repository files never leave your machine and are never transmitted across the network.
How can I safely abort a merge or rebase if things go wrong in terminal?: If you encounter complex conflicts and want to abort the operation completely and return your working directory to its pre-merge state, run "git merge --abort" (for an active merge) or "git rebase --abort" (for an active rebase). If you used "git pull", running "git merge --abort" will restore your local branch.

Developer Reference & Learning Hubs

Developer Guides

In-depth technical tutorials, debugging guides, and best practices.

Technical Glossary

Authoritative definitions for RFC standards, formats, and protocols.

AI Models Directory

Verified per-token API pricing, rate cards, and benchmarks across LLMs.

How to Git Conflict Resolver Online

Copy the raw contents of the conflicting file containing Git markers (<<<<<<<, =======, >>>>>>>) and paste it into the editor.

Click 'Parse Conflicts' or press ⌘↵ (Mac) / Ctrl+Enter (Windows) to instantly extract all conflicting hunks and line positions.

Review each section in the visual side-by-side comparison: inspect 'Current' (HEAD/target) on the left and 'Incoming' (branch/source) on the right.

Choose your resolution strategy per conflict: 'Accept Current', 'Accept Incoming', 'Both (Current First)', 'Both (Incoming First)', or 'Manual Edit'.

Use 'Accept All Current' (⌘⇧A) or 'Accept All Incoming' (⌘⇧I) in the toolbar to bulk-resolve multiple conflicts in one operation.

Inspect the merged output in the 'Resolved Output' panel and click 'Copy Resolved' (⌘⇧C) to copy the clean, marker-free code ready for git add.

Git Conflict Resolver Features

Visual side-by-side diffing: compare 'Current' (HEAD) vs 'Incoming' (feature branch) code side-by-side with clear color highlights.

Automatic conflict marker parser: detects standard 2-way markers, 3-way diff3 markers, and rebase commit hash headers.

Granular resolution options: toggle between Current, Incoming, Both (Current First), Both (Incoming First), or inline custom manual editing.

Bulk resolution buttons: resolve entire files in one click with "Accept All Current" or "Accept All Incoming".

Real-time conflict statistics: tracks total conflict count, clean code sections, line additions, and remaining unresolved blocks.

Syntax & language agnostic: seamlessly resolves JavaScript, TypeScript, Python, Go, Rust, C++, Java, JSON, YAML, and Markdown files.

Fast keyboard shortcuts: speed up resolutions with ⌘↵ (parse), ⌘⇧A (all current), ⌘⇧I (all incoming), and ⌘⇧C (copy output).

100% private & client-side: all parsing and string assembly execute locally in your browser; no source code or proprietary tokens ever touch a server.

Clean output generation: completely strips all conflict markers and metadata headers, leaving pristine file content ready for git commit.

Empty side & deletion handling: properly manages conflicts where lines were deleted or created on only one branch.

Malformed marker detection: alerts you to incomplete marker triplets or corrupted diff chunks before resolution.

Rebase & cherry-pick compatibility: parses branch labels, commit SHAs (7-40 hex chars), and remote tracking branches.

Supported Formats & Dialects

The Git Conflict Resolver supports 6 syntax formats and dialects for accurate parsing and processing.

Standard Git 2-Way Conflict Markers (merge.conflictstyle = merge)

The default Git conflict marker format displaying only the current branch (HEAD) and incoming branch versions separated by =======.

Diff3 3-Way Conflict Markers (merge.conflictstyle = diff3)

Includes an additional ||||||| section displaying the common ancestor base commit, clarifying what existed before either branch diverged.

Zdiff3 Compact 3-Way Conflict Markers (merge.conflictstyle = zdiff3)

Modern Git 2.35+ conflict style that trims common prefix and suffix lines from the ancestor base block, reducing visual noise.

Git Rebase Conflict Markers (Commit SHA Headers)

Occurs during git rebase or cherry-pick where the conflict headers contain 7-40 character hexadecimal commit hashes instead of branch names.

Git Stash & Patch Conflict Markers

Generated when applying stashed changes with git stash pop or applying formatted patches with git apply --reject.

Single-Sided Deletion / Addition Conflicts

Conflicts where one side of the marker is completely empty, representing code that was deleted on one branch and modified on the other.

Frequently Asked Questions

What causes a Git merge conflict and how do conflict markers work?

A Git merge conflict occurs when two branches modify the exact same lines of a file in divergent ways, or when one branch deletes a file that another branch modified. Git cannot automatically decide which change is correct, so it halts the merge and inserts text markers: "<<<<<<< HEAD" marks the start of your current branch changes, "=======" acts as the midpoint divider, and ">>>>>>> <branch>" marks the end of the incoming branch changes.

What is the difference between standard conflict markers, diff3, and zdiff3?

Standard Git markers show a 2-way comparison (Current vs Incoming). In contrast, "diff3" adds a middle section ("||||||| <base>") showing the common ancestor code before both branches made changes. "zdiff3" (available in Git 2.35+) improves diff3 by removing identical prefix and suffix lines from the conflict hunk, significantly reducing visual noise and making it easier to identify the exact modifications.

How do I resolve conflicts during a git rebase versus a git merge?

During a "git merge", HEAD represents your target branch and the incoming section represents the feature branch. During a "git rebase", HEAD represents the commit being replayed on top of the upstream base. After resolving the conflict markers in your file, run "git add <file>" and "git merge --continue" for a merge, or "git rebase --continue" for a rebase. Never run "git commit" directly during a rebase.

What is git rerere and how does it help with repeated conflicts?

git rerere stands for "Reuse Recorded Resolution". When enabled ("git config --global rerere.enabled true"), Git records how you resolved a conflicting hunk. If you rebase frequently or merge long-lived branches that encounter the exact same conflict repeatedly, Git automatically reapplies your previous manual resolution.

When should I choose "Both (Current First)" versus "Both (Incoming First)"?

Choose "Both" when both branches introduced valid, non-overlapping additions (such as appending new items to an array, registering new routes, adding imports, or configuring dependencies). The order depends on sequence requirements: "Current First" preserves the existing branch order, while "Incoming First" prioritizes newly merged logic.

Can this tool resolve binary file conflicts like images or compiled binaries?

No. Git conflict markers are text-based. For binary conflicts (e.g. PNG images, SQLite databases, compiled binaries), Git does not inject marker lines into the file. Instead, you must resolve binary conflicts in your terminal by selecting either "git checkout --ours <file>" or "git checkout --theirs <file>".

How do Git merge strategies like ort and recursive differ?

Git 2.33+ uses the "ort" (Ostensibly Recursive's Twin) merge strategy by default, replacing the legacy "recursive" strategy. ort is significantly faster, resolves renames across directories more accurately, and produces cleaner conflict hunks. However, when conflicts do arise, the marker syntax remains identical.

What should I do if a conflict involves deleted lines on one side?

In deletion conflicts, one side of the conflict marker will be empty. If you want to keep the deletion, accept the empty side (Incoming or Current depending on which branch performed the delete). If you want to keep the original code or modified code, accept the non-empty side or use "Manual Edit" to combine the logic.

Is my proprietary source code sent to any server when using this tool?

No. This resolver runs 100% client-side in your browser using pure JavaScript regex and string parsing. Your source code, API keys, and repository files never leave your machine and are never transmitted across the network.

How can I safely abort a merge or rebase if things go wrong in terminal?

If you encounter complex conflicts and want to abort the operation completely and return your working directory to its pre-merge state, run "git merge --abort" (for an active merge) or "git rebase --abort" (for an active rebase). If you used "git pull", running "git merge --abort" will restore your local branch.

Popular Text & Data tools

How to Git Conflict Resolver Online

Git Conflict Resolver Features

Supported Formats & Dialects

In-Depth Technical Guides

GitHub Actions YAML Workflow Debugging: The Top 10 Syntax & Runtime Pitfalls

Mastering Git Merge Conflict Resolution: 3-Way Diff, Diff3 Markers & Rebase Workflows

Visual Text Diffing, Unified Diff Syntax & Git Patch Workflows

Related Standards & RFC Specifications

Pre-built Automation Pipelines

Base64 Decode → JSON Format

CSV → JSON → YAML

JSON Format → TypeScript Schema

Example Input & Output

Sample Input (text)

Sample Output

What happened:

Frequently Asked Questions

Related Developer Tools

Developer Reference & Learning Hubs

Git Conflict Resolver

Git Conflict Resolver

Popular Text & Data tools

How to Git Conflict Resolver Online

Git Conflict Resolver Features

Supported Formats & Dialects

In-Depth Technical Guides

GitHub Actions YAML Workflow Debugging: The Top 10 Syntax & Runtime Pitfalls

Mastering Git Merge Conflict Resolution: 3-Way Diff, Diff3 Markers & Rebase Workflows

Visual Text Diffing, Unified Diff Syntax & Git Patch Workflows

Related Standards & RFC Specifications

Pre-built Automation Pipelines

Base64 Decode → JSON Format

CSV → JSON → YAML

JSON Format → TypeScript Schema

Example Input & Output

Sample Input (text)

Sample Output

What happened:

Frequently Asked Questions

Related Developer Tools

Developer Reference & Learning Hubs

Git Conflict Resolver