Führen Sie Zweige mit unterschiedlicher Historie zusammen

• Abweichungen von der Abstammung erkennen.
• Wählen Sie einen expliziten Zusammenführungsaufzeichnungsmodus.
• Überprüfen Sie beide Elternteile und den kombinierten Inhalt.
• Halten Sie die lokale Zusammenführung von der Serververöffentlichung getrennt.

Beginnen Sie dort, wo Lektion 17 endete: main mit Mayas README-Commit, clean; Die veröffentlichten Feature-/Preiskarten sind immer noch F1 und gehen von H5 ab. Sie speichern und committen MAIN_ACCESSIBLE als Vorbereitung, sodass „main“ und „feature“ jeweils unabhängige Commits haben.

Das Video wurde mit Git 2.52.0 und GitTree 2.0 auf Ubuntu 24.04 aufgenommen: Die Seite, ihr Commit und die Zusammenführung wurden in der App durchgeführt; der vorherige Zustand, der verweigerte Schnellvorlauf in einer separaten Kopie und die Prüfungen (einschließlich des projekteigenen Flusens, Tests und Builds) liefen im Terminal. 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.

Divergenz bedeutet, dass keine Spitze einfach der Nachkomme ist, zu dem der andere Zweig schnell vorspulen kann. Git findet einen gemeinsamen Vorfahren und kombiniert die zugehörigen Änderungen. Ein Zweigname allein kann Ihnen nicht sagen, ob ein Merge-Commit erforderlich ist.

Ein Merge-Commit zeichnet zwei übergeordnete Elemente der Reihe nach auf. Das erste übergeordnete Element ist das vorherige Trinkgeld des ausgecheckten Zweigs. Zweitens ist die zusammengeführte Seite. Vorhandene Feature-Commits behalten ihre Identität; Ein neues Merge-Commit verbindet ihre Vorfahren.

Kein Textkonflikt ist kein Beweis für semantische Korrektheit. Überprüfen Sie den fokussierbaren Haupt-, Workflow- und Leo-Erinnerungsabschnitt in der vollständigen Datei. Führen Sie vorhandene Prüfungen durch. Bei einer lokalen Zusammenführung wird der Ursprung erst durch einen separaten autorisierten Push aktualisiert.

Vorbereitung und Zusammenführung, lokales Haupt-/HEAD-Verschieben und Aktualisieren von Index/Arbeit. Die Funktionsreferenz bleibt F1. Beide Ursprungszweige und Version 0.1.0 behalten ihre vorherigen Tipps.

Speichern Sie beim Hauptspeicher MAIN_ACCESSIBLE nur index.html und schreiben Sie den Fix fest: Machen Sie den Hauptmarkstein fokussierbar. Dies macht die native/App-Merge-Eingabe explizit; Übertragen Sie die bereits kombinierte MERGED-Datei nicht vor dem Zusammenführen.

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 – MAIN_ACCESSIBLE

<!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>
  </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 – ZUSAMMENGEFÜHRT

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

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. Speichern Sie MAIN_ACCESSIBLE über Dateien anzeigen → index.html → Speichern; Überprüfen Sie nur den Tabindex-Zusatz.
2. Arbeitsänderungen anzeigen; Bühnendatei index.html; Commit-Fix: Machen Sie den wichtigsten Orientierungspunkt fokussierbar, wenn die normalen Optionen deaktiviert sind.
3. Untersuchen Sie die Abstammung des Haupt- und Feature-/Preiskartendiagramms. Halten Sie main ausgecheckt.
4. Öffnen Sie unter „Lokal“ den Ordner feature und klicken Sie mit der rechten Maustaste auf pricing-cards → Merge feature/pricing-cards into main. Der Dialog folgt mit Record it as.
5. In Record it as stehen nach Möglichkeit Schnellvorlauf zur Auswahl, andernfalls ein Zusammenführungs-Commit. Always a merge commit; Nur schneller Vorlauf; und Squash in gestaffelte Änderungen (kein Commit). Wählen Sie Immer ein Merge-Commit aus. Abbrechen, wenn in der tatsächlichen Vorschau unerwartete Pfade oder Konflikte angezeigt werden.
6. Wählen Sie „Einmal zusammenführen“ und warten Sie auf den tatsächlichen Abschluss. Ersetzen Sie Squash nicht in gestaffelten Änderungen.
7. Untersuchen Sie die beiden übergeordneten Elemente des resultierenden Commits und vergleichen Sie die vollständige index.html mit MERGED. Überprüfen Sie alle drei unabhängigen Änderungen.
8. Führen Sie die lokalen Prüfungen und Bereinigungsstatusabfragen aus; Belassen Sie main bei der lokalen Zusammenführung, ohne Push After Commit. Der eigene Merge-Betreff der App lautet „Merge branch 'feature/pricing-cards'“; Es muss nicht mit der nativen Nachricht unten übereinstimmen.

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.

Nach dem Speichern von MAIN_ACCESSIBLE erfolgt die native Vorbereitung und Zusammenführung:

git add -- index.html
git commit --quiet -m "fix: make the main landmark focusable"
git branch course-before-merge
git merge --quiet --no-ff feature/pricing-cards --message "merge: combine workflow cards with accessibility"
git log -1 --format=%s
git rev-list --parents -n 1 HEAD
git status --short

Eigentliches Thema:

merge: combine workflow cards with accessibility

Die übergeordnete Abfrage gibt den tatsächlichen Zusammenführungs-SHA aus, gefolgt von genau zwei übergeordneten SHAs. Die IDs variieren. Die vollständig zusammengeführte index.html stimmte Byte für Byte mit MERGED im Fixture überein; Status war leer. Der explizite native Betreff muss nicht mit dem von der App generierten Betreff übereinstimmen: Akzeptieren Sie die tatsächliche App-Nachricht, wenn Abstammung/Inhalt übereinstimmen, und überlagern Sie niemals eine gefälschte native Nachricht.

npm run --silent lint
npm test -- --test-reporter=tap
npm run --silent build

Führen Sie diese gegen den zusammengeführten Prüfpunkt aus. Der Quelltext und die Anzahl der übergeordneten Elemente allein beweisen die Prüfungen nicht. Die Fixture-Suite verfügt über sechs Tests. Ein separater Nur-FF-Versuch für die divergierte Eingabe muss abgelehnt werden, anstatt diesen Zusammenführungsmodus stillschweigend auszuwählen.

Where you end: Hauptpunkte zum Zusammenführen von M mit dem ersten Elternteil, dem vorbereiteten Haupttipp, und dem zweiten Elternteil F1; Die vollständige MERGED-Seite enthält Workflowkarten, eine Leo-Fußzeile und eine fokussierbare Hauptseite. Index/Arbeit sauber; kein Remote-Push.

• Zusammenführen in die falsche Richtung.
• Einen Squash als Zwei-Eltern-Zusammenführung bezeichnen.
• Vertrauen Sie auf die konfliktfreie Vorschau als semantischen Beweis.

Wenn eine echte Zusammenführung stoppt, behalten Sie den Betriebsstatus bei und verwenden Sie den später erläuterten Konflikt-/Abbruch-Workflow. Führen Sie keinen unabhängigen Reset durch. Vor einer abgeschlossenen nativen Zusammenführung behält „Course-before-Merge“ nur den alten festgeschriebenen Tipp bei, nicht willkürliche Arbeitsbytes.

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 zeichnet einen Merge-Commit aus?

   Wählen Sie eine Antwort.

   Seine Farbe

   Sein Betreff enthält Merge

   Mehrere Eltern

   Antwort prüfen
2. Frage 2 von 6

   Frage 2 von 6

   Welche Beweise werden benötigt?

   Wählen Sie jede zutreffende Antwort aus.

   Beide Elternrollen

   Nur ein konfliktfreies Label

   Kombinierte ganze Seite

   Antwort prüfen
3. Frage 3 von 6

   Frage 3 von 6Erforderlich

   Was passiert mit der Identität von F1?

   Wählen Sie eine Antwort.

   Es bleibt unverändert

   Es wird als F1′ wiedergegeben.

   Es wird zur übergeordneten Wurzel von main

   Antwort prüfen
4. Frage 4 von 6

   Frage 4 von 6Erforderlich

   Wählen Sie ff-only für diese divergierende Eingabe: Ergebnis?

   Wählen Sie eine Antwort.

   Feature-Löschung

   Automatisches Merge-Commit

   Ablehnung

   Antwort prüfen
5. Frage 5 von 6

   Frage 5 von 6

   Kein Textkonflikt bedeutet, dass Tests unnötig sind?

   Wählen Sie eine Antwort.

   Ja

   Nur die Anzahl der Eltern zählt

   Nein

   Antwort prüfen
6. Frage 6 von 6

   Frage 6 von 6Erforderlich

   Was ist der endgültige Umfang?

   Wählen Sie jede zutreffende Antwort aus.

   Lokales Haupt-M mit zwei Eltern

   Alles wurde automatisch verschoben

   Feature F1 und Server-Referenzen unverändert

   Antwort prüfen

Überprüfen Sie die genauen MERGED-Bytes und zwei tatsächliche übergeordnete Bytes, wobei F1 unverändert bleibt. Sagen Sie voraus, dass der Schnellvorlauf nur bei der ursprünglich divergierten Eingabe ablehnt; Test nur in separater Kopie.

• Divergenz ist eine Abstammungsbeziehung.
• Beim Zusammenführen bleiben alte Commit-Identitäten erhalten.
• Es sind sowohl Inhalts- als auch Elternprüfungen erforderlich.

• Erstellen Sie einen Feature-Zweig und entfernen Sie nur die verfügbare Referenz (Lektion 9)
• Push-Commits und Veröffentlichung eines Zweigs (Lektion 13)
• Laden Sie GitTree herunter

Zusammenführen – دمج; Merge-Commit – Standardwert; gemeinsamer Vorfahre – سلف مشترك; erster Elternteil – الأب الأول.