未公開の作品を新しいベースにリベースする

• 正確なプライベート再生範囲を特定します。
• 再生する前に古いコミット履歴を保護します。
• 再作成されたコミット ID を認識します。
• 親ツリーと完全な結果ツリーを確認します。

レッスン 18 の結果の別のコピー (メインはマージ M、クリーン) から開始します。プライベート トピックの feature/signup-form は 1 つのコミット S を保持し、updated-main は 1 つの異なるコミット N を保持し、両方とも M 上にあり、rescue/signup-before-rebase も S を指します。トピックはチェックアウトされ、クリーンで未公開です。

このビデオは、Ubuntu 24.04 の Git 2.52.0 と GitTree 2.0 を使用して録画されました。プライベート トピックと新しいベースはターミナルに構築されました。リベース、そのダイアログ、結果のチェックはアプリ内で行われました。結果が端末に読み戻されました。以下のネイティブ リプレイは使い捨てコピーで実行され、同じ結果が得られました。 macOS または Windows では何も実行されず、記録された Linux システムは Ubuntu だけです。 GitTree のソース Git フロアは 2.39.0 です。

GitTree はサインインを求めます。無料プランでは、ここでのすべてのステップがカバーされます。プロバイダー アカウント、プロ/トライアル、API 認証情報、インターネット サービスは必要ありません。ローカルのベアオリジンは GitLab または CI ではありません。すべてのアイデンティティは example.com を使用します。このレッスンをソース チェックアウト内で実行しないでください。

両方を連続してではなく、同一の入力で GitTree またはネイティブ パスのいずれかを介してミューテーションを作成します。読み取り専用検証はどちらの後にも続きます。最終的な作業として説明される準備はすべて、ネイティブの準備としてラベル付けされており、決して発明されたアプリの機能ではありません。

リベースは、現在のトピックに固有のコミットを選択し、その変更を新しいベースにリプレイします。古いコミット自体は移動しません。新しい親と通常は新しい ID を持つ新しいコミットが作成されます。

ソース ブランチは、意図した現在のブランチである必要があります。このフィクスチャでは、S がサインアップを追加し、N が別のドキュメントを追加するため、リプレイは競合しませんが、それによって任意のリベースが安全になるわけではありません。

出版履歴は調整境界です。これらのコミットは意図的に非公開になっています。グラフを直線にするためだけに、すでに公開されている価格設定機能をリベースしないでください。レスキュー参照は、未保存のテキストではなく、コミットされた祖先を保護します。

フィーチャと HEAD は S→S' に進みます。インデックス/ワークは結合ツリーになります。 N/更新メイン、レスキューS、オリジナルメイン/Mは固定のままです。サーバーの突然変異や自動プッシュはありません。

レッスン 18 で残したプロジェクトの別の通常のコピーから開始します (メインはマージ M)。元の gittree の機能は維持されます。このシナリオは、オリジナルまたはソース チェックアウトでは実行しないでください。次に、以下の正確な準備を実行します。リポジトリローカルのデモ署名はオフになっており、GitTree デモ <demo@example.com> が ID です。

以下のフェーズでのみ保存します。これらは、最後に改行を含む完全な 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 を 1 回選択してください。リベースが完了したという通知を待ちます。停止した場合は再度クリックせずに動作状態を維持してください。
6. S'の親Nと被験者を検査します。端末出力としてのモデル ラベルではなく、実際の新旧 ID を比較します。
7. 結果のツリー内の完全な SIGNUP と DOC_MERGE を検査します。レスキュー ブランチは依然として古い S を指しています。
8. クリーンなステータスとリベース操作がないことを確認します。元の main/M とすべてのサーバー参照はそのままにしておきます。

すべての通常のコミット: 概要が記載された主題です。説明が空です。以前のコミットを修正し、フックをスキップし、サインオフ者を追加し、別の作成者を追加し、コミット後にプッシュし、空のコミットをオフに許可します。共著者はいません。指定したファイルのみをステージングし、N 個のファイルへの変更を 1 回コミットする (1 つのファイル)、または代わりに 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 と updated-main の両方に 1 つの独立したコミットが含まれるようになりました。 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^ は updated-main/N に等しい。独立したドキュメントと正確な SIGNUP 本体は両方とも残ります。ショートステータスはサイレントです。強制オプションを追加する代わりに、予期しないパブリッシュ/ダーティ入力を停止します。競合のバリアントについては、レッスン 23 を参照してください。停止したリベースをすでに終了したものとして扱わないでください。

Where you end: 個の機能/登録フォーム ポイント S'、親 N、登録と DOC_MERGE あり。古い S は、Rescue/signup-before-rebase で存続します。アクティブな操作はありません。クリーンです。 main/M とサーバーは変更されません。

• 直線のグラフは、古いコミット ID が残っていることを意味すると仮定します。
• 代替ペインを元のチェックポイントとして扱います。
• アプリが成功した後、完了したミューテーションを繰り返します。

リプレイの前に、レスキュー ブランチは S を保持します。操作が停止した場合は、バナーを調べて解決するか、明示的に中止します。完了したリベースは、rebase --abort によって中止されません。ネイティブ リプレイが GitTree ジャーナルを書き込んだとは決して考えないでください。

各質問に答えてから、その理由を読みましょう。 「必須」とマークされた質問は、レッスンの完了にカウントされます。

1. 質問 1 / 6

   質問 1 / 6

   What is replayed?

   答えを 1 つ選択してください。

   すべてのリポジトリ ファイルを盲目的に

   リモートサーバー

   プライベートトピックの変更

   答えを確認する
2. 質問 2 / 6

   質問 2 / 6

   何を確認する必要がありますか?

   当てはまるものをすべて選択してください。

   現在のブランチとターゲット

   プライベートレンジとレスキューリファレンス

   グラフの色のみ

   答えを確認する
3. 質問 3 / 6

   質問 3 / 6必須

   S が N で再生されました: 親ですか?

   答えを 1 つ選択してください。

   更新されたメインコミット N

   S を自身の親として

   旧Mのみ

   答えを確認する
4. 質問 4 / 6

   質問 4 / 6必須

   入力の変更: 両側で同じヒーローの行が変更されました。

   答えを 1 つ選択してください。

   常に衝突はありません

   片面を自動的に破棄

   競合によりリプレイが停止する可能性があります

   答えを確認する
5. 質問 5 / 6

   質問 5 / 6

   --abort はすでに完了したリベースを元に戻すことができますか?

   答えを 1 つ選択してください。

   サーバープッシュを元に戻します

   いつも

   アクティブな操作が存在しません

   答えを確認する
6. 質問 6 / 6

   質問 6 / 6必須

   この結果を証明するものは何でしょうか?

   当てはまるものをすべて選択してください。

   新しいIDと親N

   古い S が救出され、完全なファイルがクリーンになりました

   メッセージのみ変更なし

   答えを確認する

新しい HEAD がレスキューとは異なり、その親が N に等しく、サインアップ/ドキュメントの全バイトが一致することを証明します。別のレッスン 23 のコピーで、両側が同じヒーロー ラインを変更した場合の競合を予測します。

• Rebase はコミットを再作成します。
• 現在のブランチとターゲットを明示的に選択します。
• 個人的な履歴と回復範囲が重要です。

• 分岐した履歴を持つブランチをマージする (レッスン 18)
• 早送りマージを理解する (レッスン 19)
• 機能ブランチを作成し、使い捨ての ref のみをリタイアする (レッスン 9)
• ダウンロード GitTree

リベース — 再ベース;リプレイ — إعادة تطبيق;レスキュー審判 — مرجع حفظ。