How to Resolve Merge Conflicts in GitHub Desktop Without Losing Work

You can paste an old copy of a file over a teammate's newer fix, and nobody notices. Hand rescues feel safe, but Git already keeps committed work safe. This guide shows how to resolve merge conflicts GitHub Desktop shows you with one routine and no backup folder.

Picture a common setup. You and one teammate build a booking website for a dance school. You share one GitHub repository and both use GitHub Desktop. The setup is made up, but the problem is real.

Whenever GitHub Desktop shows an error while you pull (download your teammate's new work), you copy the project folder somewhere safe. Then you discard your edits, pull, and paste your files back. Each rescue takes about 15 minutes (made up).

Your teammate has a different habit: typing git stash in a terminal before every pull, even when nothing is blocking. Both habits work most days, but both add steps every time.

One Friday the paste goes wrong. Your old copy of prices.html lands on top of a fix your teammate pushed that morning. The fix vanishes from the live site for two days, destroyed by the backup meant to protect work.

This guide replaces both habits with one routine. First, it separates two situations that look alike on screen.

You need six words. Each gets a plain meaning and an example from the dance-school site.

Commit. A commit is a saved snapshot of your changes, with a short message, stored in the project's history. Example: you edit one line and commit it with the message Raise monthly price.

Branch. A branch is a separate line of work inside the same project. The shared version usually lives on a branch called main. You build a new booking form on a branch called booking-form without touching main.

Remote. The remote is the copy of the project on GitHub, usually named origin, which is why the buttons say origin. Fetch origin checks it for new commits. Push origin sends your commits up to it.

Pull. Pulling downloads your teammate's new commits and merges them into your branch. In GitHub Desktop that is the Pull origin button, which appears when a fetch finds new commits.

Merge conflict. A merge conflict happens when two commits change the same or neighbouring lines of a file in different ways, or one side edits a file the other side deleted. Git cannot choose, so it asks you.

Inside the file, Git marks each clash with three marker lines: seven less-than signs, seven equals signs and seven greater-than signs. These are the conflict markers, and you delete them when you finish.

Stash. A stash is a shelf for changes you are not ready to commit. The changes leave your files for now, and you can restore them later.

Read the window GitHub Desktop shows, because there are two different situations. An error saying it is unable to pull when changes are present means nothing has merged yet. A window titled Resolve conflicts before Merge means a merge has started and is waiting for you.

Situation 1: uncommitted changes are blocking you

Uncommitted changes are edits saved in your editor but not yet committed. Git refuses to pull if the incoming commits would overwrite one of those files. It is protecting you, because that work exists nowhere else yet.

GitHub Desktop then shows a box titled Error. It lists the files that would be overwritten and offers a button, Stash changes and continue.

If your uncommitted edits touch only files the pull does not change, the pull simply goes ahead. That is why the error appears on some days and not others. We checked both cases on Git 2.53.0, the Git that GitHub Desktop 3.6.7 bundles on Windows and macOS.

One exception catches terminal users. An edit staged with git add (marked for the next commit) blocks a pull that needs a merge, even in an unrelated file. GitHub Desktop's checkboxes only choose files, and Desktop stages them itself when you commit, so this mostly bites people who also use a terminal.

Think of your scooter parked in the narrow lane outside your house. The scooter is your uncommitted edits, the lane is your project folder, and a water tanker is the incoming commits. Stashing wheels the scooter aside until the tanker passes. Committing parks it inside your compound, where the tanker never needs the space.

Where the picture breaks: the tanker only needs the lane when it changes the same files you edited. And a true conflict is not about space at all, as the next part shows.

Situation 2: a true merge conflict

A true conflict appears after the pull has started merging. Git has already combined every change it could. Only the spots where both sides changed the same or neighbouring lines are left for you, marked inside the file.

Nothing is lost in a true conflict. When the clash is over lines, both versions sit in the file, one above the other, between the markers. You do not need a backup, a discard or a stash. You only choose the final lines.

The diagram below is the whole decision. Start at the pull and follow the arrow that matches the window on your screen.

A merge conflict happens when two commits, grown from the same starting version, change the same part of a file differently. Git merges changes that sit apart by itself. It stops where both sides changed the same lines or lines right next to each other. In our test on Git 2.53.0, edits to lines 14 and 15 conflicted, while edits to lines 14 and 16 merged cleanly.

Here is the case on the dance-school site. On Monday morning, line 14 of prices.html on main says Monthly plan: Rs 999. The client asks your teammate to rename plans to memberships, and the owner asks you to raise the price.

Your teammate changes the line to Monthly membership: Rs 999, also tidies line 2, then commits and pushes first. You change the same line to Monthly plan: Rs 1,199, also edit line 20, and commit. Then you pull.

Pause and predict. Three lines changed in total. Which ones will Git stop on, and which version of line 14 will it keep?

Git merges lines 2 and 20 by itself and stops only on line 14. It keeps neither version alone: it writes both into the file between the markers and waits for you. We ran this exact case on Git 2.53.0.

Follow both arrows down from the shared version. They meet again only at the pull.

Only one line needs a human. Everything else in prices.html, and every other file, merged by itself, so throwing away all your changes is far bigger than the problem.

Commit your work, pull, open each conflicted file in your editor, keep the right lines, delete the markers, save, then click Continue merge. It usually takes a few minutes, and nothing needs a backup. Follow the boxes in order, then read the steps.

1. 1

   Commit before you pull

   In the Changes tab, tick the files you edited, type a short summary and click the commit button below it. Your work is now in history, so a pull cannot overwrite it.

2. 2

   Fetch, then pull

   Click Fetch origin. If it finds new commits, the same button becomes Pull origin, so click it. Most pulls finish here with no questions.

3. 3

   Read the conflicts window

   If both sides changed the same or neighbouring lines, a window titled Resolve conflicts before Merge opens. It lists each conflicted file with a count, such as 1 conflict.

4. 4

   Open the file in your editor

   Click the Open in button next to the file, which shows your editor's name. If no editor is set, choose one under Integrations, in Options on Windows or Settings on macOS.

5. 5

   Choose the final lines

   Keep your version, their version, or write one line that combines both. Delete all three marker lines, then save the file.

6. 6

   Continue the merge

   Back in GitHub Desktop, the file now shows No conflicts remaining. When every file is clear, click Continue merge. Desktop stages the files and creates the merge commit, which joins both lines of work.

7. 7

   Check, then push

   Open the site or run your tests to confirm it still works. Then click Push origin so your teammate gets the resolved version.

You can run the same check yourself. Open Repository, then Open in Terminal (the label shows your shell's name), and type git diff --check. If the terminal says git is not found, install Git from the official Git website first. With line 14 still in conflict, the command prints three lines, one per marker.

Each line names the file and line, such as prices.html:14: leftover conflict marker, then lines 16 and 18. After your fix it prints nothing at all.

If you close the conflicts window by mistake, the merge waits for you. A banner at the top reads Resolve conflicts and commit to merge into main, showing your own branch name. Its View conflicts link reopens the window.

Should you keep the current change, the incoming change or both?

Keep whichever version is right for the project, and that is often a mix of both. During a merge, current means the version on your branch. Incoming means the version arriving from the other side, here your teammate's commit.

These choices come from your code editor, not from GitHub Desktop. Visual Studio Code shows Accept Current Change, Accept Incoming Change, Accept Both Changes and Compare Changes above each conflict. Its own docs warn that accepting both does not promise valid code, so always read the result.

Your case needs a brand new line. The rename and the price rise are both correct, so the final line is Monthly membership: Rs 1,199, which neither side wrote.

Apart from one AI button, covered below, GitHub Desktop itself offers only whole-file choices, in the menu next to each conflicted file, such as Use the modified file from main. For a file both sides edited, it runs git checkout with --ours or --theirs, keeping one side's entire file.

As of 3.6.7, some signed-in accounts also see a button in the conflicts window that asks a built-in AI assistant to propose a resolution. Treat its answer like a teammate's suggestion: read every changed line before you continue.

What the same routine looks like as Git commands

GitHub Desktop runs ordinary Git commands for you. Seeing them once makes the buttons easier to trust. A pull is two steps, fetch and then merge, so this block shows them separately.

# 1. Save your own work first
git add prices.html
git commit -m "Raise monthly price to Rs 1,199"

# 2. Bring in the team's work (Pull origin does both)
git fetch origin
git merge origin/main

# 3. Git stops. Inside prices.html you now see:
#   <<<<<<< HEAD
#   Monthly plan: Rs 1,199
#   =======
#   Monthly membership: Rs 999
#   >>>>>>> origin/main

# 4. Write the final line, delete the markers, save, then:
git add prices.html
git commit --no-edit
git push

# Changed your mind before step 4? Go back to before the merge:
git merge --abort

What just happened? Git stopped at line 14 and wrote both versions. The part above the row of equals signs is yours, labelled HEAD, which means your current commit. The part below is the incoming version from origin/main, your copy of GitHub's main as of the last fetch. After Pull origin, that last marker shows a long commit ID instead of origin/main, and it means the same thing.

In step 4, git add tells Git the file is resolved, and git commit --no-edit creates the merge commit with Git's ready-made message. Desktop's Continue merge does the same two things. We ran this whole block on Git 2.53.0, and the result was a commit with two parents.

The last command, git merge --abort, is what Desktop's Abort merge button runs. Git's documentation warns that abort may not rebuild changes that were uncommitted when the merge started. That is one more reason to commit first.

GitHub Desktop can stash your changes for you, so you never need a manual backup. It offers this at the moment you get stuck, and you can also stash any time yourself.

• Blocked pull. The Error box lists the files at risk and offers Stash changes and continue. The pull then runs, and you restore the stash afterwards.
• Switching branches. A Switch branch window asks whether to leave your changes on the current branch or bring them to the new one. Leaving them stashes them on the branch you are leaving.
• Any time. Choose Branch, then Stash all changes, or right-click the header of the changed files list. Every uncommitted change is stashed, including brand new files.
• Getting them back. Go to the branch you stashed on, click Stashed Changes in the Changes tab, then click Restore. Discard deletes the stash instead.

GitHub's docs say Desktop stashes one set of changes at a time. The 3.6.7 source keeps one stash for each branch. If a branch already has one, the Error box will not offer to stash, and stashing again asks to overwrite it.

Restore needs a clear path. If you have uncommitted edits to the same files, Desktop shows an Error box saying it is unable to restore stashed changes. Commit or discard those edits first.

Restoring can also clash if the pull changed the same or neighbouring lines. You then resolve those lines in your editor, exactly like a merge conflict. Desktop deletes the stash at that point, so your files are now the only easy copy.

Stashing is right when your changes are half done and you do not want them in history yet. Think of a broken experiment, debug lines you will delete, or a quick jump to another branch for an urgent fix.

Say you are halfway through the booking form when your teammate asks for a typo fix on main. You switch to main and choose to leave your changes on booking-form. After the fix, you switch back and click Restore.

The table compares four ways to clear the way for a pull on a small project. Only the first two belong in a daily routine.

If you prefer a terminal, these are the stash commands. Keep the --no-rebase flag: when both sides have new commits and you never set a pull preference, a plain git pull stops with an error instead of merging.

git status             # list files you changed but did not commit
git stash              # put those changes on the shelf
git pull --no-rebase   # the pull can now run, merging like Pull origin
git stash pop          # bring the changes back onto your files

# If pop reports a conflict, fix the lines as usual, then:
git restore --staged prices.html   # clear the conflict mark Git left
git stash list         # the stash is still here, kept for safety
git stash drop         # remove it once your files look right

Merge is the safer default for beginners and small teams. Rebase gives a tidier history but rewrites your commits, so use it only on branches nobody else is using.

Merging keeps both lines of history and joins them with a merge commit. Pull origin merges unless your Git setting pull.rebase is true. If you set pull.ff to only, a pull that needs a merge fails instead. The Branch menu also has Merge into current branch, for bringing main into your branch.

Rebasing replays your commits one by one on top of another branch, as if you had started there. In GitHub Desktop, use Branch, then Rebase current branch. If pull.rebase is true, the pull button reads Pull origin with rebase instead.

You resolve rebase conflicts the same way, but once for each replayed commit that clashes. In our test, two clashing commits meant two separate stops.

Watch the labels during a rebase, because current and incoming swap meaning. The Visual Studio Code docs describe current as the new base plus commits already replayed, and incoming as your commit being replayed. Read the lines, not the labels.

Because rebase creates new commits, a branch already on GitHub then needs Force push origin. That replaces the branch on GitHub, so a teammate who built on your old commits now has history that no longer matches yours.

• Pick merge when the branch is shared, when you are new to Git, or when you want a clear record of when work joined.
• Pick rebase when the branch is yours alone, nobody has reviewed it yet, and your team prefers a straight history.

Never rebase a shared branch such as main. It rewrites history that everyone depends on. On GitHub, a branch protection rule blocks force pushes by default.

Undo it in the gentlest way available: abort before you finish, or fix forward with a new commit after you finish. Avoid rewriting history that your teammate already has.

• Still in the conflicts window. Click Abort merge. If you already resolved some files, Desktop asks you to confirm, because the conflicts you resolved will be discarded. The branch returns to how it was before the merge.
• Merged but not pushed, small mistake. Open the file, correct the lines, and make a normal commit such as Fix merged price line. This is the simplest repair.
• Merged and pushed. Fix forward the same way, with a new commit. Your teammate pulls the fix, and nobody's history breaks.
• Badly wrong and not pushed. The Undo button below the commit box undoes your latest unpushed commit. For a merge commit, Desktop warns that commits from the merged branch could disappear from your branch.

The History tab also offers Revert changes in commit, which adds a new commit that reverses an old one. On a merge commit, Desktop runs git revert -m 1, which removes everything the merge brought in. A small fix-forward commit is usually what you want.

You prevent most merge conflicts by keeping the gap between your copy and your teammate's copy small. Conflicts grow with time apart and with the size of each change.

• Pull often. Fetch at the start of each work session and before you begin a new change.
• Commit small and often. A commit that changes one thing is easy to merge and easy to undo.
• Keep branches short-lived. A branch that lives for days meets fewer of your teammate's changes than one that lives for weeks.
• Update your branch from main regularly. Choose Branch, then Update from main, so clashes arrive small and early.
• Talk before editing a busy file. A one-line message to your teammate about prices.html can avoid a conflict entirely.
• Avoid mass reformatting. Changing quotes or indentation across a whole file touches every line and clashes with everyone.

Beginners can stop here. The next section is for engineers who script Git, or who want to know exactly what each button does.

Each button runs ordinary Git commands through a copy of Git that Desktop ships with. We read the 3.6.7 source at its release tag, and ran our tests on the Git it bundles, which is 2.53.0.

These details are undocumented as of 19 October 2026. They can change in any release, so pin your version before you script around them.

Why a conflicting restore deletes your stash

Plain Git keeps a stash whose pop hits a conflict. In our test on Git 2.53.0 it exited with code 1, printed a note that the stash entry is kept, and left it in git stash list.

Desktop 3.6.7 sees that exit code 1 with nothing on the error stream and drops the entry itself. A comment in the source admits this is not the greatest approach. Your stashed edits then live only in the conflicted files.

So before you click Restore on a branch the pull changed, commit anything you can. Or restore from a terminal with git stash apply, which keeps the entry even when it conflicts, and drop it yourself afterwards.

A dropped stash is not gone at once. Its commit stays in the repository until Git cleans up data that no branch or stash points to. The search shown in Git's stash docs looks for WIP, which misses Desktop stashes, because Desktop names them GitHub_Desktop plus the branch.

# Find stashes Desktop dropped (as of 3.6.7; needs grep, cut and xargs)
git fsck --unreachable | grep commit | cut -d' ' -f3 |
  xargs git log --merges --no-walk --grep=GitHub_Desktop --oneline

# Each line starts with a short commit ID. Bring that one back:
git stash apply COMMIT_ID

In our test on Git 2.53.0, the search printed one line ending in the branch name, and git stash apply brought the edits back. Replace COMMIT_ID with the ID it prints.

Why the conflict count can look wrong

Desktop counts markers, not conflicts. If you set merge.conflictStyle to diff3 or zdiff3, Git adds a fourth marker showing the original lines. One real conflict then shows as 2 conflicts. Our tests found four markers for one clash with both settings.

Explain it as a calm routine with a check at the end, not as a lucky escape. Interviewers listen for whether you understand what Git is doing and whether you protect your teammates' work.

It comes up in Git-based coding rounds and in team questions, such as a time your code clashed with a teammate's. Shape your answer with these steps.

1. 1

   Name the two situations

   Say that a blocked pull and a true conflict are different. One needs a commit or a stash. The other needs a decision about lines.

2. 2

   Describe your routine

   Commit small, fetch, pull, open each conflicted file, choose or combine the lines, remove the markers, and continue the merge.

3. 3

   Show that you read both sides

   Explain that you check what each side meant to do, and that you ask the teammate when the right answer is unclear.

4. 4

   Verify before sharing

   Mention running the tests or the app before pushing, so a wrong resolution never reaches main.

5. 5

   End with prevention

   Close with habits: short-lived branches, regular updates from main, and a quick word before editing a shared file.