Resolve merge and rebase conflicts

• Read a real conflict: the base, the current side and the incoming side.
• Explain why "ours" and "theirs" swap between a merge and a rebase.
• Write one deliberate resolution, then mark it resolved.
• Continue the operation and check that nothing is left half-done.

Two teammates changed the same line of the page. On conflict/sara, Sara changed the hero heading to "Review changes with confidence." On conflict/omar, Omar changed the same line to "Understand each saved change." Both branches start from the commit M, where the heading was "See your work clearly.", and each branch has exactly one commit. You make two identical copies of this divergence: one for the merge (gittree-conflict-merge) and one for the rebase (gittree-conflict-rebase). In both, conflict/sara is checked out and the work tree is clean. No merge or rebase is running.

Everything is local and on the Free plan (GitTree asks you to sign in): no hosting account, no provider, no internet. Every identity is fictional (example.com). Never run this lesson in a real project.

Make the changes in GitTree or with the native Git commands, not both in the same copy. Reading the result is always safe. The menu labels come from GitTree 2.0's own strings and the native commands were run with Git 2.43 in disposable copies. The GitTree steps were not run on macOS, Windows or Linux.

A content conflict means Git cannot pick one result on its own: both sides changed the same lines differently. Git stops and keeps three versions of the file in the index: stage 1 is the common base, stage 2 is "ours" and stage 3 is "theirs". It also writes conflict markers into the file in your work tree. Removing the markers in an editor does not resolve anything for Git: the file is resolved only when you save the result and stage it, which brings back stage 0.

"Ours" and "theirs" are positions, not people. In a merge you are on Sara's branch, so ours is Sara's version (the current side) and theirs is Omar's (the incoming side). In a rebase of Sara onto Omar, Git first moves to Omar's branch and then replays Sara's commit, so ours is Omar's version (the branch you are rebasing onto) and theirs is Sara's commit. GitTree prints the role next to each name so you do not have to remember: "(current)" and "(incoming)" in a merge, "(rebasing onto)" and "(your commit)" in a rebase.

The right result is rarely one side. Here the intended resolution is "Review each change with confidence.", neither Sara's line nor Omar's. Keep every other line of the page exactly as it was. Marking the file resolved stages your result; continuing is a separate step that finishes the merge commit or recreates Sara's commit on Omar's.

While the operation is stopped, the branch is where the operation left it and the file is conflicted. Nothing reaches a server.

Make one divergence, then copy it twice. Start from a separate ordinary copy of the project as lesson 18 left it, and leave your original gittree-features untouched. The page versions are below: MERGED is the shared base, SARA and OMAR are the two competing versions, and RESOLVED is the result you will save.

Save only at the phase named below. These are full UTF-8/LF bodies with a final newline; never paste Markdown fences. Unchanged runnable files inherit the named input. Versions in separate variants must not overwrite the original.

index.html — MERGED

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>GitTree Features — course demo</title>
  <link rel="stylesheet" href="styles.css">
</head>
<body>
  <header class="site-header">
    <a href="#main">GitTree Features</a>
  </header>
  <main id="main" tabindex="-1">
    <section class="hero" aria-labelledby="hero-title">
      <p class="eyebrow">GitTree Learn demo project</p>
      <h1 id="hero-title">See your work clearly.</h1>
      <p id="hero-copy">Choose one change, then check what Git saved.</p>
    </section>
    <section class="features" aria-labelledby="features-title">
      <h2 id="features-title">Follow your work</h2>
      <div class="cards">
        <article class="feature-card">
          <h3>History</h3>
          <p>Read commits and branches together.</p>
        </article>
        <article class="feature-card">
          <h3>Changes</h3>
          <p>Review the exact content selected for a commit.</p>
        </article>
        <article class="feature-card">
          <h3>Recovery</h3>
          <p>Inspect the scope of a recovery point before using it.</p>
        </article>
      </div>
    </section>
    <section aria-labelledby="plans-title">
      <h2 id="plans-title">Choose the workflow you need</h2>
      <div class="cards">
        <article class="feature-card">
          <h3>Local Git</h3>
          <p>Local Git workflows work without signing in.</p>
        </article>
        <article class="feature-card">
          <h3>Connected workflows</h3>
          <p>Provider integrations and Nour require Pro or an applicable trial.</p>
        </article>
      </div>
    </section>
  </main>
  <footer><p>Built by a fictional team for GitTree Learn. Review one change at a time.</p></footer>
  <script type="module" src="site.js"></script>
</body>
</html>

index.html — SARA

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>GitTree Features — course demo</title>
  <link rel="stylesheet" href="styles.css">
</head>
<body>
  <header class="site-header">
    <a href="#main">GitTree Features</a>
  </header>
  <main id="main" tabindex="-1">
    <section class="hero" aria-labelledby="hero-title">
      <p class="eyebrow">GitTree Learn demo project</p>
      <h1 id="hero-title">Review changes with confidence.</h1>
      <p id="hero-copy">Choose one change, then check what Git saved.</p>
    </section>
    <section class="features" aria-labelledby="features-title">
      <h2 id="features-title">Follow your work</h2>
      <div class="cards">
        <article class="feature-card">
          <h3>History</h3>
          <p>Read commits and branches together.</p>
        </article>
        <article class="feature-card">
          <h3>Changes</h3>
          <p>Review the exact content selected for a commit.</p>
        </article>
        <article class="feature-card">
          <h3>Recovery</h3>
          <p>Inspect the scope of a recovery point before using it.</p>
        </article>
      </div>
    </section>
    <section aria-labelledby="plans-title">
      <h2 id="plans-title">Choose the workflow you need</h2>
      <div class="cards">
        <article class="feature-card">
          <h3>Local Git</h3>
          <p>Local Git workflows work without signing in.</p>
        </article>
        <article class="feature-card">
          <h3>Connected workflows</h3>
          <p>Provider integrations and Nour require Pro or an applicable trial.</p>
        </article>
      </div>
    </section>
  </main>
  <footer><p>Built by a fictional team for GitTree Learn. Review one change at a time.</p></footer>
  <script type="module" src="site.js"></script>
</body>
</html>

index.html — OMAR

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>GitTree Features — course demo</title>
  <link rel="stylesheet" href="styles.css">
</head>
<body>
  <header class="site-header">
    <a href="#main">GitTree Features</a>
  </header>
  <main id="main" tabindex="-1">
    <section class="hero" aria-labelledby="hero-title">
      <p class="eyebrow">GitTree Learn demo project</p>
      <h1 id="hero-title">Understand each saved change.</h1>
      <p id="hero-copy">Choose one change, then check what Git saved.</p>
    </section>
    <section class="features" aria-labelledby="features-title">
      <h2 id="features-title">Follow your work</h2>
      <div class="cards">
        <article class="feature-card">
          <h3>History</h3>
          <p>Read commits and branches together.</p>
        </article>
        <article class="feature-card">
          <h3>Changes</h3>
          <p>Review the exact content selected for a commit.</p>
        </article>
        <article class="feature-card">
          <h3>Recovery</h3>
          <p>Inspect the scope of a recovery point before using it.</p>
        </article>
      </div>
    </section>
    <section aria-labelledby="plans-title">
      <h2 id="plans-title">Choose the workflow you need</h2>
      <div class="cards">
        <article class="feature-card">
          <h3>Local Git</h3>
          <p>Local Git workflows work without signing in.</p>
        </article>
        <article class="feature-card">
          <h3>Connected workflows</h3>
          <p>Provider integrations and Nour require Pro or an applicable trial.</p>
        </article>
      </div>
    </section>
  </main>
  <footer><p>Built by a fictional team for GitTree Learn. Review one change at a time.</p></footer>
  <script type="module" src="site.js"></script>
</body>
</html>

index.html — RESOLVED

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>GitTree Features — course demo</title>
  <link rel="stylesheet" href="styles.css">
</head>
<body>
  <header class="site-header">
    <a href="#main">GitTree Features</a>
  </header>
  <main id="main" tabindex="-1">
    <section class="hero" aria-labelledby="hero-title">
      <p class="eyebrow">GitTree Learn demo project</p>
      <h1 id="hero-title">Review each change with confidence.</h1>
      <p id="hero-copy">Choose one change, then check what Git saved.</p>
    </section>
    <section class="features" aria-labelledby="features-title">
      <h2 id="features-title">Follow your work</h2>
      <div class="cards">
        <article class="feature-card">
          <h3>History</h3>
          <p>Read commits and branches together.</p>
        </article>
        <article class="feature-card">
          <h3>Changes</h3>
          <p>Review the exact content selected for a commit.</p>
        </article>
        <article class="feature-card">
          <h3>Recovery</h3>
          <p>Inspect the scope of a recovery point before using it.</p>
        </article>
      </div>
    </section>
    <section aria-labelledby="plans-title">
      <h2 id="plans-title">Choose the workflow you need</h2>
      <div class="cards">
        <article class="feature-card">
          <h3>Local Git</h3>
          <p>Local Git workflows work without signing in.</p>
        </article>
        <article class="feature-card">
          <h3>Connected workflows</h3>
          <p>Provider integrations and Nour require Pro or an applicable trial.</p>
        </article>
      </div>
    </section>
  </main>
  <footer><p>Built by a fictional team for GitTree Learn. Review one change at a time.</p></footer>
  <script type="module" src="site.js"></script>
</body>
</html>

Open the palette with Command+Shift+P (Ctrl+Shift+P on Ubuntu). Actions on a named branch use that branch's right-click menu.

1. Build the two copies as the next section shows. Open gittree-conflict-merge, with conflict/sara checked out.
2. Right-click conflict/omar and choose Merge conflict/omar into conflict/sara. Under Record it as choose Always a merge commit. The dialog warns "Will stop with a conflict in 1 file"; choose Merge. The merge stops, which is the expected result.
3. The banner reads "Merging conflict/omar into conflict/sara" with "1 conflict", and Continue is not available yet: "Resolve the 1 conflicts first". Choose Resolve.
4. Open index.html from Conflicted files. Read the two sides, conflict/sara (current) and conflict/omar (incoming), and use Show Base to read the Base (common ancestor).
5. Choose Edit Output, replace the conflicting heading with Review each change with confidence. and keep every other line. Then choose Save and Mark Resolved. Deleting the markers and closing the file is not enough.
6. Back on the banner choose Continue. If a message is offered, keep the proposed one. Wait for the merge to finish: the new commit has two parents.
7. Open gittree-conflict-rebase, with conflict/sara checked out. Right-click conflict/omar and choose Rebase conflict/sara onto conflict/omar. Leave the options under Options for this rebase off, then choose Rebase conflict/sara. It stops with a conflict.
8. Choose Resolve and open index.html. The sides are now conflict/omar (rebasing onto) and conflict/sara (your commit): the roles swapped. Do the same Edit Output → Save and Mark Resolved, then Continue.
9. Check both copies: the file equals RESOLVED, no conflicted file is left and no banner is showing. Keep the two results apart and do not push.

For every ordinary commit in the course: Summary is the stated subject, Description is empty and the options Amend Previous Commit, Skip Hooks, Add Signed-off-by, Different Author, Push After Commit and Allow Empty Commit stay off.

In a separate clean copy of lesson 18's result:

git switch --create conflict/sara
BASE_SHA="$(git rev-parse HEAD)"

Save SARA as index.html, then:

git add -- index.html
git -c user.name="Sara Lindqvist" -c user.email=sara@example.com commit --quiet -m "feat: Sara clarifies the hero"
git switch --quiet --create conflict/omar "$BASE_SHA"

Save OMAR as index.html, then:

git add -- index.html
git -c user.name="Omar Haddad" -c user.email=omar@example.com commit --quiet -m "feat: Omar explains the hero"
git switch --quiet conflict/sara

BASE_SHA is M, before either competing commit. Make two clean copies of this divergence, one for the merge and one for the rebase (cd .. && cp -R gittree-features gittree-conflict-merge && cp -R gittree-features gittree-conflict-rebase). In the merge copy:

git merge --no-ff --no-edit conflict/omar
git ls-files --unmerged
git show :2:index.html
git show :3:index.html

The merge stops with exit code 1 and git ls-files --unmerged lists three entries, stages 1, 2 and 3. git show :2:index.html is Sara's version (ours) and :3: is Omar's (theirs); :1: is the base. Save RESOLVED as index.html, then:

git add -- index.html
git -c core.editor=true merge --continue
git ls-files --unmerged
git status --short

The last two commands print nothing. In the untouched rebase copy:

git rebase conflict/omar
git show :2:index.html
git show :3:index.html

The rebase stops. Now :2: is Omar's version and :3: is Sara's: the roles swapped. Save RESOLVED as index.html, then:

git add -- index.html
git -c core.editor=true rebase --continue
git ls-files --unmerged
git status --short

Both files now equal RESOLVED and nothing is unmerged. core.editor=true only accepts the existing commit message for this one command; it does not change your editor setting. To leave a stopped operation without resolving, use git merge --abort or git rebase --abort.

Where you end: the merge copy has a new commit with two parents and the combined heading; the rebase copy has Sara's commit recreated on Omar's with the same combined heading. In both, index.html equals RESOLVED, no conflict entry is left, the operation is over and the status is clean.

• Assuming "ours" always means your own feature. It means the side Git is standing on, and that changes with the operation.
• Taking one side wholesale ("Take All") before reading both versions and the rest of the file.
• Deleting the conflict markers but never saving and marking the file resolved.
• Repeating a merge or rebase that has already finished.

If a stop looks wrong, Abort… from the banner restores the state the operation started from and drops the resolutions made so far; GitTree keeps a recovery snapshot first. If the file changed while you were editing, use the Compare and Use as Output choices rather than forcing an old save. Keep a copy of your draft before replacing it.

Answer each question, then read why. Questions marked “Required” count toward completing the lesson.

1. Question 1 of 6

   Question 1 of 6

   You are on conflict/sara and merge conflict/omar into it. Which side does Git call "ours"?

   Choose one answer.

   Whichever version has more lines.

   conflict/sara, the branch you are on.

   conflict/omar, because it is the newer change.

   The common ancestor M.

   Check answer
2. Question 2 of 6

   Question 2 of 6

   Which statements about a conflicted file in the index are true?

   Choose every answer that applies.

   git ls-files --unmerged lists the file while it is conflicted.

   Stage 2 is "ours" and stage 3 is "theirs".

   Stage 1 is the common base.

   Stage 0 exists while the file is conflicted.

   Check answer
3. Question 3 of 6

   Question 3 of 6Required

   You rebase conflict/sara onto conflict/omar and it stops with a conflict. Which version is "ours" now?

   Choose one answer.

   Neither; a rebase has no sides.

   Sara's, because it is your branch.

   The base.

   Omar's: the branch you are rebasing onto.

   Check answer
4. Question 4 of 6

   Question 4 of 6

   Change the input: you delete the conflict markers in the editor and save the file, but you never mark it resolved. What state are you in?

   Choose one answer.

   Git stages the file automatically when you save.

   Still conflicted: the index keeps the three stages, and Continue stays unavailable.

   The merge was aborted.

   Resolved, because the markers are gone.

   Check answer
5. Question 5 of 6

   Question 5 of 6Required

   You saved your result, but the banner still says "Resolve the 1 conflicts first" and Continue is not available. What is the most likely cause?

   Choose one answer.

   The file was edited but never saved with Save and Mark Resolved, so the index is still conflicted.

   The remote has newer commits.

   You must push first.

   Git is too old to continue.

   Check answer
6. Question 6 of 6

   Question 6 of 6Required

   Which readbacks show the merge copy finished correctly?

   Choose every answer that applies.

   index.html still contains <<<<<<<.

   git rev-list --parents -n 1 HEAD prints three IDs.

   git status --short prints nothing.

   git ls-files --unmerged prints nothing.

   Check answer

Prove the stage roles for both operations with git show :2:index.html and git show :3:index.html, then save the same RESOLVED file and finish each operation. Predict what would be left in the page if you blindly took "ours" in both copies.

• The roles of ours and theirs depend on the operation.
• Save and mark resolved first, then continue.
• Check the whole file and the operation state afterwards.

• Merge branches with diverged history (lesson 18)
• Rebase unpublished work onto a new base (lesson 20)
• How to resolve Git merge conflicts
• Download GitTree

Conflict — تعارض; base — الأساس; ours — نسختنا; theirs — نسختهم; resolve — حلّ.