Merge versus rebase: choose with a graph

• Start merge and rebase from identical copies, so the comparison is fair.
• Read a merge commit's two parents and a rebased commit's single new parent.
• Explain why two copies can end with the same files and still have different histories.
• Choose with one rule: rewrite only commits that nobody else has.

You need two separate copies of the divergence from lesson 20, named gittree-merge and gittree-rebase. In each copy the branch feature/signup-form holds one commit of yours (call it S), the branch updated-main holds one different commit (call it N), both started from the same commit M, and rescue/signup-before-rebase points at S. The topic branch is checked out and the work tree is clean. Do not make the second copy from the result of the first.

Everything here 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), and you should never run this lesson inside a real project.

Make the changes in GitTree or with the native Git commands, not both in the same copy. Reading the result afterwards is always safe. The menu labels come from GitTree 2.0's own strings; the native commands were run with Git 2.43 in disposable copies. The GitTree steps were not run on macOS, Windows or Linux; the app's shortcuts use Command on macOS where this page writes Ctrl.

A comparison is only fair when both copies start from the same refs and the same files. If you merge first and then rebase that result, you are asking a different question: the replay now has a merge commit in its range.

Merge keeps both lines of work. It adds one new commit, K, with two parents: S first, then N. S and N keep their IDs.

Rebase replays your commit on top of N. The result, S′, has the same change as S but a new parent, and a commit's ID includes its parent, so S′ has a new ID. The old S survives only because the rescue branch still points at it.

When nothing conflicts, both copies end with the same file tree. Equal trees do not mean equal history: one graph keeps a diamond, the other a straight line, and the commit IDs differ.

Which one is right is not a matter of taste. If other people already have your commits, replaying them breaks their copies, so merge. If the commits are private, a rebase is safe and gives a linear history if your team prefers one. Neither makes the code better.

In each copy only the topic branch moves. The server, updated-main and the original main are not touched.

Make one divergence, then copy it twice. Start from a separate ordinary copy of the project as lesson 18 left it (main is the merge commit M). Leave your original gittree-features untouched, and never run this in a source checkout. The demo identity is GitTree Demo, demo@example.com, with signing turned off in this repository only.

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 — SIGNUP

<!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>
    <section aria-labelledby="signup-title">
      <h2 id="signup-title">Try the demo form</h2>
      <form id="signup-form" novalidate>
        <label for="demo-email">Demo email</label>
        <input id="demo-email" name="email" type="email" autocomplete="off" aria-describedby="signup-hint">
        <p id="signup-hint">Use a fictional example.com address. Nothing is sent.</p>
        <button type="submit">Check the address locally</button>
        <p id="signup-result" role="status"></p>
      </form>
    </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>

docs/integration-note.md — DOC_MERGE

# Integration review

This note was written on main while signup work was private.

Open the palette with Command+Shift+P (Ctrl+Shift+P on Ubuntu), type the exact command name and choose it. Actions on a named branch use that branch's right-click menu.

1. Open gittree-merge. Then choose New Tab and open gittree-rebase from its Recent list. Each tab is titled with its folder name, so you can tell the two apart.
2. In the gittree-merge tab keep feature/signup-form checked out. Right-click updated-main and choose Merge updated-main into feature/signup-form.
3. Under Record it as choose Always a merge commit, then choose Merge once. The new commit has two parents: S first, then N.
4. Switch to the gittree-rebase tab. It is still at S and N, exactly as you saved it. Do not use the merge copy.
5. Right-click updated-main and choose Rebase feature/signup-form onto updated-main. Read Options for this rebase and leave both options off, then choose Rebase feature/signup-form once.
6. Select the replayed commit. Its parent is N and its ID is new. The old S is still named by rescue/signup-before-rebase.
7. In each tab open Show Files → index.html and docs/integration-note.md. They are the same page and the same note in both copies. Then return with Back to Graph.
8. Compare the two graphs, then say which rule decides the choice for this branch before you pick a result. Keep both copies as they are.

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. This lesson makes no ordinary commit.

Build the divergence in a separate clean copy of lesson 18's result (the work you did in the app, written as native commands):

git switch --create feature/signup-form

Save the full SIGNUP page as index.html, then:

git add -- index.html
git commit --quiet -m "feat: add the local signup demonstration"
git branch rescue/signup-before-rebase
BASE_SHA="$(git rev-parse HEAD~1)"
git switch --quiet --create updated-main "$BASE_SHA"

On updated-main save the full DOC_MERGE note as docs/integration-note.md, then:

git add -- docs/integration-note.md
git commit --quiet -m "docs: add the integration review"
git switch --quiet feature/signup-form

BASE_SHA is the commit M that both lines grow from. Now make the two independent copies from this exact state (cd .. && cp -R gittree-features gittree-merge && cp -R gittree-features gittree-rebase). In the merge copy:

git merge --quiet --no-ff --no-edit updated-main
git rev-list --parents -n 1 HEAD
git rev-parse 'HEAD^{tree}'
git status --short

In the untouched rebase copy:

git rebase --quiet --no-autostash --no-update-refs --no-autosquash updated-main
git rev-list --parents -n 1 HEAD
git rev-parse 'HEAD^{tree}'
git status --short

git rev-list --parents -n 1 HEAD prints the commit's ID followed by its parents: three IDs in the merge copy, two in the rebase copy. The two HEAD^{tree} lines are the same ID, and git status --short prints nothing in both. The two HEAD commit IDs are different. Your IDs will differ from anyone else's; compare yours with each other, not with this page.

If the topic had no commit of its own and updated-main were simply ahead of it, git merge would fast-forward by default and create no merge commit. That is a different input and a different result; choose it on purpose, never fake a two-parent merge.

Where you end: the merge copy has a new commit K with parents S and N; the rebase copy has S′ with parent N, and the old S is kept by the rescue branch. The file trees are equal, both statuses are clean, and the original main, M and the server are untouched.

• Assuming a straight graph means the old commit ID survived. A rebase always creates new commits.
• Starting the rebase from the merge result. That is a different experiment, and the replay can include the merge commit.
• Comparing the two HEAD IDs and expecting them to agree. Compare the trees instead.
• Repeating the merge or the rebase after it has already finished.

Do not discard either result to force them to match. If the trees differ, compare the starting refs, any conflict resolution and any extra commit, then start again from the saved divergence. A rescue branch keeps committed history only; it does not keep uncommitted files.

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

1. Question 1 of 6

   Question 1 of 6

   From the same start, you merge updated-main into feature/signup-form in one copy and rebase feature/signup-form onto updated-main in another. How many parents does the topic's new tip commit have in each copy?

   Choose one answer.

   Both copies: two.

   Both copies: one.

   Merge copy: two. Rebase copy: one.

   Merge copy: one. Rebase copy: two.

   Check answer
2. Question 2 of 6

   Question 2 of 6

   Which of these are the same in both copies once the merge and the rebase have finished without conflicts?

   Choose every answer that applies.

   The commit your topic branch started with

   The file tree of the tip commit

   The ID of the tip commit

   The content of docs/integration-note.md

   Check answer
3. Question 3 of 6

   Question 3 of 6Required

   After the rebase, what happened to your original topic commit S?

   Choose one answer.

   A new commit S′ with a new ID was created; the old S is only reachable through the rescue branch.

   S kept its ID and only its parent changed.

   S was deleted from the repository at once.

   S was pushed to the server.

   Check answer
4. Question 4 of 6

   Question 4 of 6

   Change the input: your topic has no commit of its own, and updated-main is simply ahead of it. You merge with the default mode, "Fast-forward if possible, else a merge commit". What happens?

   Choose one answer.

   Git refuses, because the branches have not diverged.

   A merge commit with two parents is always created.

   The branch label moves forward and no merge commit is created.

   Every commit is rewritten with a new ID.

   Check answer
5. Question 5 of 6

   Question 5 of 6Required

   A colleague already pulled feature/signup-form and is building on it. You want main history to stay tidy. What is the safe choice?

   Choose one answer.

   Rebase and force-push it, because a straight graph is cleaner.

   Delete the branch and create it again with the same name.

   Merge updated-main into the branch, so their commits keep their IDs.

   Reset the branch to updated-main.

   Check answer
6. Question 6 of 6

   Question 6 of 6Required

   Which readbacks show the comparison was fair and show how it ended?

   Choose every answer that applies.

   The two copies had the same S and N before you started.

   git rev-parse HEAD^{tree} prints the same ID in both copies.

   git rev-list --parents -n 1 HEAD prints three IDs for the merge copy and two for the rebase copy.

   git rev-parse HEAD prints the same ID in both copies.

   Check answer

Report the two parent lists, the two HEAD IDs and the two tree IDs. Explain why equal tree IDs next to different HEAD IDs is the expected result. Then predict, without doing it, what a default merge does when the topic has no commit of its own.

• Same start, different history.
• Equal trees do not mean equal history.
• Merge when others have your commits. Rebase only private ones.

• Merge branches with diverged history (lesson 18)
• Understand fast-forward merges (lesson 19)
• Rebase unpublished work onto a new base (lesson 20)
• Interactive rebase in a GUI
• Download GitTree

Rebase — إعادة تأسيس; replay — إعادة تطبيق; rescue branch — فرع حفظ.