将未发表的作品重新建立到新的基础上

• 确定确切的私人重播范围。
• 在重播之前保护旧的提交历史记录。
• 识别重新创建的提交身份。
• 验证父树和完整的结果树。

从第 18 课结果的单独副本开始（main 是合并 M，干净）：私有主题 feature/signup-form 保存一个提交 S，updated-main 保存一个不同的提交 N，两者都在 M 上，rescue/signup-before-rebase 也指向 S。该主题已签出、干净且未发布。

该视频是在 Ubuntu 24.04 上使用 Git 2.52.0 和 GitTree 2.0 录制的：在终端中内置了私有主题和较新的基础；变基、对话框和结果检查都是在应用程序中完成的；结果在终端中读回。下面的本机重播在一次性副本中运行并给出了相同的结果。 macOS 或 Windows 上没有运行任何内容，并且 Ubuntu 是唯一记录的 Linux 系统。 GitTree 的源 Git 版本是 2.39.0。

GitTree 要求您登录；免费计划涵盖了这里的每一步。不需要提供商帐户、专业版/试用版、API 凭证或互联网服务。本地裸源不是 GitLab 或 CI。所有身份均使用 example.com；切勿在源代码检查中运行本课程。

通过 GitTree 或本地路径以相同的输入进行突变，而不是连续进行。只读验证可以遵循其中任何一个。任何被描述为终端工作的准备工作都被标记为本机准备，而不是发明的应用程序功能。

变基选择对当前主题唯一的提交，并将其更改重播到新的基础上。它不会移动旧的承诺本身；它会使用新的父级和通常是新的 ID 创建新的提交。

源分支必须是预期的当前分支。在此装置中，S 添加注册，N 添加不同的文档，因此重播是无冲突的，但这并不能使任意变基安全。

出版的历史是一个协调边界。这些提交是故意保密的；不要仅仅为了使图表变得直观而重新调整已发布的定价功能。救援引用保护已承诺的祖先，而不是未保存的文本。

特征和HEAD前进S→S′；索引/工作成为组合树。 N/updated-main、rescue S 和原始 main/M 保持不变。没有服务器突变或自动推送。

从第 18 课留下的项目的单独普通副本开始（主要是合并 M）。原始的 gittree-features 仍然保留；不要在原始或源结帐中运行此场景。然后执行下面的具体准备工作。存储库本地演示签名已关闭，身份为 GitTree Demo <demo@example.com>。

仅在下面指定的阶段保存。这些是完整的 UTF-8/LF 正文，最后有换行符；永远不要粘贴 Markdown 栅栏。未更改的可运行文件继承命名输入。单独变体中的版本不得覆盖原始版本。

index.html — 注册

<!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.

调色板：Command+Shift+P（在 Ubuntu 上为 Ctrl+Shift+P）；输入确切命名的命令并选择它。命名引用操作使用该行的上下文菜单，而不是无参数的调色板快捷方式。

1. 使用下面标记的本机设置准备准确的分歧和救援分支；没有发布的分支被重写。
2. 在应用程序中确认功能/注册表单已签出、干净且未发布；检查S和N。
3. 右键单击图表中的 updated-main → Rebase feature/signup-form onto updated-main；该对话框命名当前分支和目标。
4. 阅读Options for this rebase。将 Stash local changes and put them back 和 Move the branches that point into these commits 关闭。该对话框显示旧功能/注册表单保存在 refs/ogt/trash 下。
5. 选择Rebase feature/signup-form一次；等待rebase完成的通知。如果停止，则保持其运行状态，不要再次点击。
6. 检查 S' 父母 N 和受试者。比较实际的旧/新 ID，而不是作为终端输出的模型标签。
7. 检查生成的树中的完整 SIGNUP 和 DOC_MERGE；救援分支仍然指向老S。
8. 验证干净状态并且没有变基操作；保留原来的 main/M 和所有服务器引用。

对于每个普通提交：Summary 是规定的主题；描述为空；修改先前的提交、跳过挂钩、添加签署者、不同的作者、提交后推送以及允许空提交；没有共同作者。仅暂存指定的文件，然后将更改提交到 N 个文件一次（文件为一个），或者使用 Command+Enter 作为替代方案。等待真正的结果。明确修改的课程仅更改所述选项。

在单独的干净课程 18/M 副本中，创建私有主题：

git switch --create feature/signup-form

将保存的 SIGNUP 文件放在 index.html 上（视频将课程文件保存在 ~/Downloads 中并使用 cp ~/Downloads/SIGNUP.html index.html），然后：

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"

在 Updated-main 上将 DOC_MERGE 放在 docs/integration-note.md (cp ~/Downloads/DOC_MERGE.md docs/integration-note.md) 中，然后：

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

BASE_SHA 是私有注册提交之前测量的 M 父级。 topic 和 update-main 现在都有一个独立的提交； rescue/signup-before-rebase 保留了旧主题。该主题的任何内容均未发布。

本机重播替代方案：

git rebase --quiet --no-autostash --no-update-refs --no-autosquash updated-main
git log -1 --format=%s
git rev-parse HEAD HEAD^ updated-main rescue/signup-before-rebase
git status --short

观察对象：

feat: add the local signup demonstration

实际的 HEAD 与获救的 S 不同； HEAD^ 等于更新主/N。独立文件和确切的注册正文均保留；短暂的状态是沉默。停止意外的已发布/脏输入，而不是添加强制选项。对于冲突变体，请参阅第 23 课；不要将停止的变基视为已经完成。

Where you end: 特征/注册表单点 S′，父 N，带有注册表加上 DOC_MERGE；老S在救援/重新定位前注册中幸存下来。无主动操作，干净； main/M 和服务器不变。

• 假设直图意味着旧的提交 ID 仍然存在。
• 将替代窗格视为原始检查点。
• 应用程序成功后重复已完成的突变。

在重放之前，救援分支保留 S。如果操作停止，请检查横幅并解决或显式中止；已完成的 rebase 不会被 rebase --abort 中止。切勿假设本机重放写入了 GitTree 日志。

回答每个问题，然后阅读原因。标记为“必填”的问题将有助于完成本课程。

1. 第 1 题，共 6 题

   第 1 题，共 6 题

   重播的内容是什么？

   选择一个答案。

   每个存储库文件都盲目

   远程服务器

   私人话题变更

   检查答案
2. 第 2 题，共 6 题

   第 2 题，共 6 题

   必须检查什么？

   选择每个适用的答案。

   当前分支和目标

   私人靶场和救援裁判

   仅图形颜色

   检查答案
3. 第 3 题，共 6 题

   第 3 题，共 6 题必填

   S在N上重播：家长？

   选择一个答案。

   更新后的主提交 N

   S 作为其自己的父级

   仅限老M

   检查答案
4. 第 4 题，共 6 题

   第 4 题，共 6 题必填

   更改输入：双方更改相同的英雄线。

   选择一个答案。

   始终没有冲突

   自动丢弃一侧

   冲突可能会停止重播

   检查答案
5. 第 5 题，共 6 题

   第 5 题，共 6 题

   --abort 可以撤消已经完成的变基吗？

   选择一个答案。

   它撤消服务器推送

   总是

   不存在活动操作

   检查答案
6. 第 6 题，共 6 题

   第 6 题，共 6 题必填

   什么证明了这个结果呢？

   选择每个适用的答案。

   新ID和父N

   老S获救，完整文件清理

   仅消息未更改

   检查答案

证明新的 HEAD 与救援不同，其父级等于 N 并且完整的注册/文档字节一致。在单独的第 23 课副本中，如果双方更改相同的英雄线，则预测冲突。

• Rebase 重新创建提交。
• 明确选择当前分支和目标。
• 私人历史和恢复范围很重要。

• 合并具有不同历史记录的分支（第 18 课）
• 了解快进合并（第 19 课）
• 创建一个功能分支并仅停用一次性引用（第 9 课）
• 下载GitTree

Rebase — 重新设置；重播——重播；救援裁判 — ????????????