Rebasieren Sie unveröffentlichte Arbeiten auf einer neuen Basis

• Identifizieren Sie den genauen privaten Wiedergabebereich.
• Schützen Sie den alten Commit-Verlauf vor der Wiedergabe.
• Erkennen Sie neu erstellte Commit-Identitäten.
• Überprüfen Sie den übergeordneten und vollständigen resultierenden Baum.

Beginnen Sie mit einer separaten Kopie des Ergebnisses von Lektion 18 (Hauptthema ist die Zusammenführung M, sauber): Das private Thema „feature/signup-form“ enthält ein Commit S, „updatet-main“ enthält ein anderes Commit N, beide auf M, und „rettung/signup-before-rebase“ zeigt ebenfalls auf S. Das Thema ist ausgecheckt, sauber und unveröffentlicht.

Das Video wurde mit Git 2.52.0 und GitTree 2.0 auf Ubuntu 24.04 aufgenommen: Das private Thema und die neuere Basis wurden im Terminal erstellt; der Rebase, sein Dialog und die Überprüfung des Ergebnisses wurden in der App durchgeführt; Das Ergebnis wurde im Terminal zurückgelesen. Die folgende native Wiedergabe wurde in einer Einwegkopie ausgeführt und lieferte das gleiche Ergebnis. Auf macOS oder Windows wurde nichts ausgeführt, und Ubuntu ist das einzige aufgezeichnete Linux-System. Die Quell-Git-Ebene von GitTree ist 2.39.0.

GitTree fordert Sie auf, sich anzumelden; Der Free-Plan deckt hier dann jeden Schritt ab. Es ist kein Anbieterkonto, Pro-/Testversion, API-Anmeldeinformationen oder Internetdienst erforderlich. Ein lokaler nackter Ursprung ist nicht GitLab oder CI. Alle Identitäten verwenden example.com; Führen Sie diese Lektion niemals innerhalb einer Quellprüfung durch.

Nehmen Sie Mutationen entweder über GitTree oder den nativen Pfad an identischen Eingaben vor, nicht beide nacheinander. In beiden Fällen kann eine schreibgeschützte Überprüfung erfolgen. Jede als Terminalarbeit beschriebene Vorbereitung wird als native Vorbereitung bezeichnet und niemals als erfundene App-Funktion.

Rebase wählt Commits aus, die für das aktuelle Thema eindeutig sind, und spielt ihre Änderungen auf einer neuen Basis ab. Die alten Commits selbst werden dadurch nicht verschoben; Es erstellt neue Commits mit neuen Eltern und normalerweise neuen IDs.

Der Quellzweig muss der beabsichtigte aktuelle Zweig sein. In diesem Fixture fügt S die Anmeldung und N ein anderes Dokument hinzu, sodass die Wiedergabe konfliktfrei ist, aber das macht willkürliche Rebases nicht sicher.

Die veröffentlichte Geschichte ist eine Koordinationsgrenze. Diese Commits sind absichtlich privat; Ändern Sie nicht die bereits veröffentlichte Preisfunktion, nur um die Grafik zu vereinheitlichen. Eine Rettungsreferenz schützt die festgelegte Abstammung, nicht den nicht gespeicherten Text.

Merkmal und HEAD-Vorschub S→S′; index/work wird zum kombinierten Baum. N/aktualisiertes Haupt-, Rettungs-S- und ursprüngliches Haupt-/M-System bleiben fest. Keine Servermutation oder automatischer Push.

Beginnen Sie mit einer separaten, normalen Kopie des Projekts, so wie es in Lektion 18 hinterlassen wurde (hauptsächlich ist die Zusammenführung M). Die ursprünglichen Gittree-Funktionen bleiben erhalten; Führen Sie dieses Szenario nicht im Original- oder Quell-Checkout aus. Führen Sie dann die genaue Vorbereitung unten durch. Die Repository-lokale Demo-Signierung ist deaktiviert und GitTree Demo <demo@example.com> ist die Identität.

Speichern Sie nur in der unten genannten Phase. Dabei handelt es sich um vollständige UTF-8/LF-Körper mit einem abschließenden Zeilenumbruch; Fügen Sie niemals Markdown-Zäune ein. Unveränderte ausführbare Dateien erben die benannte Eingabe. Versionen in separaten Varianten dürfen das Original nicht überschreiben.

index.html – ANMELDEN

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

Palette: Befehl+Umschalt+P (Strg+Umschalt+P bei Ubuntu); Geben Sie den genau benannten Befehl ein und wählen Sie ihn aus. Benannte Ref-Aktionen verwenden das Kontextmenü dieser Zeile und keine argumentfreie Palettenverknüpfung.

1. Bereiten Sie den genauen Divergenz- und Rettungszweig mithilfe des unten beschrifteten nativen Setups vor; Kein veröffentlichter Zweig wird neu geschrieben.
2. Bestätigen Sie in der App, dass die Funktion/das Anmeldeformular ausgecheckt, sauber und unveröffentlicht ist. Überprüfen Sie S und N.
3. Klicken Sie mit der rechten Maustaste auf updated-main im Diagramm → Rebase feature/signup-form onto updated-main; Der Dialog benennt den aktuellen Zweig und das Ziel.
4. Lesen Sie Options for this rebase. Lassen Sie Stash local changes and put them back und Move the branches that point into these commits ausgeschaltet. Der Dialog besagt, dass das alte Feature/Anmeldeformular unter refs/ogt/trash aufbewahrt wird.
5. Wählen Sie einmal Rebase feature/signup-form; Warten Sie auf die Benachrichtigung, dass die Rebase abgeschlossen ist. Wenn es stoppt, behalten Sie den Betriebszustand bei, anstatt erneut zu klicken.
6. Untersuchen Sie S′, Elternteil N und Subjekt. Vergleichen Sie tatsächliche alte/neue IDs, nicht Modellbezeichnungen als Terminalausgabe.
7. Überprüfen Sie SIGNUP und DOC_MERGE im resultierenden Baum vollständig. Der Rettungszweig zeigt immer noch auf den alten S.
8. Überprüfen Sie den Clean-Status und keinen Rebase-Vorgang. Lassen Sie das ursprüngliche Main/M und alle Server-Refs in Ruhe.

Für jeden gewöhnlichen Commit: Zusammenfassung ist der angegebene Betreff; Beschreibung leer; Vorheriges Commit ändern, Hooks überspringen, „Signiert von“ und „Anderer Autor“ hinzufügen, „Nach Commit verschieben“ und „Leeres Commit deaktivieren“ zulassen; keine Co-Autoren. Stellen Sie nur die benannten Dateien bereit und übernehmen Sie dann die Änderungen einmal in N Dateien (Datei für eine) oder alternativ Befehl+Eingabetaste. Warten Sie auf das tatsächliche Ergebnis. Eine Lektion, die explizit Änderungen vornimmt, ändert nur die angegebene Option.

Erstellen Sie in einer separaten Kopie der sauberen Lektion 18/M das private Thema:

git switch --create feature/signup-form

Platzieren Sie die gespeicherte SIGNUP-Datei über index.html (das Video speicherte die Dateien der Lektion in ~/Downloads und verwendet cp ~/Downloads/SIGNUP.html index.html), dann:

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"

Geben Sie auf „updates-main“ DOC_MERGE unter docs/integration-note.md (cp ~/Downloads/DOC_MERGE.md docs/integration-note.md) ein, dann:

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

BASE_SHA ist das gemessene M-Elternteil vor dem privaten Anmelde-Commit. Sowohl „Topic“ als auch „Updated-Main“ haben jetzt einen unabhängigen Commit; „rettung/signup-before-rebase“ behält das alte Thema bei. Zu diesem Thema wird nichts veröffentlicht.

Alternative zur nativen Wiedergabe:

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

Beobachtetes Thema:

feat: add the local signup demonstration

Der tatsächliche KOPF weicht vom geretteten S ab; HEAD^ entspricht aktualisiert-main/N. Das unabhängige Dokument und der genaue SIGNUP-Körper bleiben beide erhalten; Kurzer Status ist still. Stoppen Sie bei einer unerwarteten veröffentlichten/ungültigen Eingabe, anstatt Force-Optionen hinzuzufügen. Zur Konfliktvariante siehe Lektion 23; Behandeln Sie einen gestoppten Rebase nicht als bereits abgeschlossen.

Where you end: Feature/Signup-Form-Punkte S′, übergeordnetes N, mit Anmeldung plus DOC_MERGE; Das alte S überlebt in Rescue/Signup-before-Rebase. Keine Operation aktiv, sauber; main/M und server unverändert.

• Angenommen, ein gerades Diagramm bedeutet, dass die alte Commit-ID erhalten geblieben ist.
• Behandeln des alternativen Bereichs als ursprünglichen Prüfpunkt.
• Wiederholen einer abgeschlossenen Mutation nach App-Erfolg.

Vor der Wiedergabe behält der Rettungszweig S bei. Wenn der Vorgang stoppt, überprüfen Sie das Banner und lösen Sie es auf oder brechen Sie es explizit ab. Ein abgeschlossener Rebase wird nicht durch rebase --abort abgebrochen. Gehen Sie niemals davon aus, dass Native Replay ein GitTree-Tagebuch geschrieben hat.

Beantworten Sie jede Frage und lesen Sie dann, warum. Mit „erforderlich“ gekennzeichnete Fragen zählen zum Abschluss der Lektion.

1. Frage 1 von 6

   Frage 1 von 6

   Was wird wiedergegeben?

   Wählen Sie eine Antwort.

   Jede Repository-Datei blind

   Der Remote-Server

   Private Themenänderungen

   Antwort prüfen
2. Frage 2 von 6

   Frage 2 von 6

   Was muss überprüft werden?

   Wählen Sie jede zutreffende Antwort aus.

   Aktueller Zweig und Ziel

   Privatbereich und Rettungsreferent

   Nur Diagrammfarbe

   Antwort prüfen
3. Frage 3 von 6

   Frage 3 von 6Erforderlich

   S wiederholt auf N: Elternteil?

   Wählen Sie eine Antwort.

   Der aktualisierte Haupt-Commit N

   S als sein eigenes Elternteil

   Nur altes M

   Antwort prüfen
4. Frage 4 von 6

   Frage 4 von 6Erforderlich

   Eingabe ändern: Dieselbe Heldenlinie auf beiden Seiten geändert.

   Wählen Sie eine Antwort.

   Immer keine Konflikte

   Eine Seite automatisch verwerfen

   Ein Konflikt kann die Wiedergabe stoppen

   Antwort prüfen
5. Frage 5 von 6

   Frage 5 von 6

   Kann --abort ein bereits abgeschlossenes Rebase rückgängig machen?

   Wählen Sie eine Antwort.

   Es macht Server-Pushs rückgängig

   Immer

   Es ist kein aktiver Vorgang vorhanden

   Antwort prüfen
6. Frage 6 von 6

   Frage 6 von 6Erforderlich

   Was beweist dieses Ergebnis?

   Wählen Sie jede zutreffende Antwort aus.

   Neue ID und Eltern-N

   Altes S gerettet, alle Dateien sauber

   Nur die Nachricht bleibt unverändert

   Antwort prüfen

Beweisen Sie, dass sich der neue HEAD von der Rettung unterscheidet, dass sein übergeordnetes Element gleich N ist und dass die vollständigen Anmelde-/Dokumentbytes übereinstimmen. Prognostizieren Sie Konflikte, wenn beide Seiten dieselbe Heldenlinie ändern, in einer separaten Kopie von Lektion 23.

• Rebase erstellt Commits neu.
• Wählen Sie explizit den aktuellen Zweig und das Ziel aus.
• Private Historie und Wiederherstellungsumfang sind wichtig.

• Zweige mit abweichendem Verlauf zusammenführen (Lektion 18)
• Fast-Forward-Merges verstehen (Lektion 19)
• Erstellen Sie einen Feature-Zweig und entfernen Sie nur die verfügbare Referenz (Lektion 9)
• Laden Sie GitTree herunter

Rebase – إعادة تأسيس; Wiederholung – إعادة تطبيق; Rettungsreferent — مرجع حفظ.