Merge versus Rebase: Wählen Sie mit einem Diagramm

• Beginnen Sie mit der Zusammenführung und dem Rebase von identischen Kopien, damit der Vergleich fair ist.
• Lesen Sie die beiden übergeordneten Elemente eines Merge-Commits und das einzige neue übergeordnete Element eines rebasierten Commits.
• Erklären Sie, warum zwei Kopien mit denselben Dateien enden können und dennoch unterschiedliche Historien haben.
• Wählen Sie mit einer Regel: Schreiben Sie nur Commits neu, die niemand sonst hat.

Sie benötigen zwei separate Kopien der Divergenz aus Lektion 20 mit den Namen gittree-merge und gittree-rebase. In jeder Kopie enthält der Zweig feature/signup-form ein Commit von Ihnen (nennen Sie es S), der Zweig updated-main enthält ein anderes Commit (nennen Sie es N), beide haben mit demselben Commit M begonnen und rescue/signup-before-rebase zeigt auf S. Der Themenzweig ist ausgecheckt und der Arbeitsbaum ist sauber. Erstellen Sie die zweite Kopie nicht aus dem Ergebnis der ersten.

Alles hier ist lokal und im kostenlosen Plan (GitTree fordert Sie auf, sich anzumelden): kein Hosting-Konto, kein Anbieter, kein Internet. Jede Identität ist fiktiv (example.com), und Sie sollten diese Lektion niemals in einem realen Projekt durchführen.

Nehmen Sie die Änderungen in GitTree oder mit den nativen Git-Befehlen vor, nicht beides in derselben Kopie. Das anschließende Ablesen des Ergebnisses ist immer sicher. Die Menübezeichnungen stammen aus den eigenen Strings von GitTree 2.0; Die nativen Befehle wurden mit Git 2.43 in Einwegkopien ausgeführt. Die GitTree-Schritte wurden nicht auf macOS, Windows oder Linux ausgeführt; Die Tastenkombinationen der App verwenden Befehl auf macOS, wobei auf dieser Seite Strg geschrieben wird.

Ein Vergleich ist nur dann fair, wenn beide Kopien mit denselben Referenzen und denselben Dateien beginnen. Wenn Sie zuerst zusammenführen und dann das Ergebnis neu festlegen, stellen Sie eine andere Frage: Die Wiedergabe enthält jetzt einen Zusammenführungs-Commit in ihrem Bereich.

Merge behält beide Arbeitsbereiche bei. Es fügt einen neuen Commit, K, mit zwei Eltern hinzu: S zuerst, dann N. S und N behalten ihre IDs.

Rebase spielt Ihren Commit zusätzlich zu N ab. Das Ergebnis, S‘, hat die gleiche Änderung wie S, aber ein neues übergeordnetes Element, und die ID eines Commits umfasst sein übergeordnetes Element, sodass S‘ eine neue ID hat. Das alte S überlebt nur, weil der Rettungszweig immer noch auf es zeigt.

Wenn kein Konflikt besteht, enden beide Kopien mit demselben Dateibaum. Gleiche Bäume bedeuten nicht gleicher Verlauf: Ein Diagramm behält eine Raute, das andere eine gerade Linie, und die Commit-IDs unterscheiden sich.

Welches das Richtige ist, ist keine Frage des Geschmacks. Wenn andere Personen Ihre Commits bereits haben, werden ihre Kopien durch das erneute Abspielen beschädigt, also führen Sie sie zusammen. Wenn die Commits privat sind, ist ein Rebase sicher und liefert einen linearen Verlauf, wenn Ihr Team dies bevorzugt. Beides macht den Code nicht besser.

In jeder Kopie wird nur der Themenzweig verschoben. Der Server updated-main und der ursprüngliche Hauptserver werden nicht berührt.

Machen Sie eine Divergenz und kopieren Sie sie dann zweimal. Beginnen Sie mit einer separaten normalen Kopie des Projekts, so wie es in Lektion 18 hinterlassen wurde (hauptsächlich ist das Merge-Commit M). Lassen Sie Ihr ursprüngliches gittree-features unberührt und führen Sie es niemals in einem Quell-Checkout aus. Die Demo-Identität ist GitTree Demo, demo@example.com, wobei die Signatur nur in diesem Repository deaktiviert ist.

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.

Öffnen Sie die Palette mit Befehl+Umschalt+P (Strg+Umschalt+P bei Ubuntu), geben Sie den genauen Befehlsnamen ein und wählen Sie ihn aus. Aktionen für einen benannten Zweig verwenden das Rechtsklickmenü dieses Zweigs.

1. Öffnen Sie gittree-merge. Wählen Sie dann New Tab und öffnen Sie gittree-rebase aus der Liste Recent. Jede Registerkarte ist mit ihrem Ordnernamen betitelt, sodass Sie sie unterscheiden können.
2. Lassen Sie auf der Registerkarte gittree-merge feature/signup-form ausgecheckt. Klicken Sie mit der rechten Maustaste auf updated-main und wählen Sie Merge updated-main into feature/signup-form.
3. Wählen Sie unter Record it as Always a merge commit und dann einmal Merge aus. Der neue Commit hat zwei Eltern: S zuerst, dann N.
4. Wechseln Sie zur Registerkarte gittree-rebase. Es befindet sich immer noch auf S und N, genau so, wie Sie es gespeichert haben. Verwenden Sie nicht die Zusammenführungskopie.
5. Klicken Sie mit der rechten Maustaste auf updated-main und wählen Sie Rebase feature/signup-form onto updated-main. Lesen Sie Options for this rebase und lassen Sie beide Optionen deaktiviert. Wählen Sie dann einmal Rebase feature/signup-form aus.
6. Wählen Sie den wiedergegebenen Commit aus. Sein übergeordnetes Element ist N und seine ID ist neu. Das alte S wird immer noch von rescue/signup-before-rebase benannt.
7. Öffnen Sie in jeder Registerkarte Show Files → index.html und docs/integration-note.md. In beiden Kopien handelt es sich um dieselbe Seite und dieselbe Notiz. Dann kehren Sie mit Back to Graph zurück.
8. Vergleichen Sie die beiden Diagramme und sagen Sie dann, welche Regel die Wahl für diesen Zweig bestimmt, bevor Sie ein Ergebnis auswählen. Behalten Sie beide Kopien so wie sie sind.

Für jeden gewöhnlichen Commit im Kurs: Summary ist das angegebene Subjekt, Description ist leer und die Optionen Amend Previous Commit, Skip Hooks, Add Signed-off-by, Different Author, Push After Commit und Allow Empty Commit bleiben ausgeschaltet. Diese Lektion macht kein gewöhnliches Commit.

Erstellen Sie die Divergenz in einer separaten, sauberen Kopie des Ergebnisses von Lektion 18 (die Arbeit, die Sie in der App ausgeführt haben, geschrieben als native Befehle):

git switch --create feature/signup-form

Speichern Sie die vollständige Anmeldeseite als index.html und gehen Sie dann wie folgt vor:

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"

Speichern Sie am updated-main die vollständige DOC_MERGE-Notiz als docs/integration-note.md, 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 Commit M, aus dem beide Zeilen erwachsen. Erstellen Sie nun die beiden unabhängigen Kopien genau aus diesem Zustand (cd .. && cp -R gittree-features gittree-merge && cp -R gittree-features gittree-rebase). In der Zusammenführungskopie:

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 der unberührten Rebase-Kopie:

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 gibt die ID des Commits aus, gefolgt von seinen Eltern: drei IDs in der Merge-Kopie, zwei in der Rebase-Kopie. Die beiden HEAD^{tree}-Zeilen haben die gleiche ID und git status --short gibt in beiden nichts aus. Die beiden HEAD-Commit-IDs sind unterschiedlich. Ihre IDs unterscheiden sich von denen aller anderen. Vergleichen Sie Ihre untereinander, nicht mit dieser Seite.

Wenn das Thema keinen eigenen Commit hätte und updated-main einfach vor ihm wäre, würde git merge standardmäßig vorspulen und keinen Merge-Commit erstellen. Das ist eine andere Eingabe und ein anderes Ergebnis; Wählen Sie es absichtlich und fälschen Sie niemals eine Zusammenführung zweier Elternteile.

Where you end: die Zusammenführungskopie hat einen neuen Commit K mit den Eltern S und N; Die Rebase-Kopie hat S′ mit dem übergeordneten N, und das alte S wird vom Rettungszweig behalten. Die Dateibäume sind gleich, beide Status sind sauber und die ursprüngliche Hauptdatei, M und der Server sind unberührt.

• Angenommen, ein gerades Diagramm bedeutet, dass die alte Commit-ID erhalten geblieben ist. Ein Rebase erstellt immer neue Commits.
• Starten der Rebase aus dem Zusammenführungsergebnis. Das ist ein anderes Experiment und die Wiederholung kann den Merge-Commit beinhalten.
• Vergleich der beiden HEAD-IDs und Erwartung, dass sie übereinstimmen. Vergleichen Sie stattdessen die Bäume.
• Wiederholen des Zusammenführens oder Rebases, nachdem es bereits abgeschlossen ist.

Verwerfen Sie keines der Ergebnisse, um eine Übereinstimmung zu erzwingen. Wenn sich die Bäume unterscheiden, vergleichen Sie die Startrefs, etwaige Konfliktlösungen und etwaige zusätzliche Festschreibungen und beginnen Sie dann erneut mit der gespeicherten Abweichung. Ein Rettungszweig speichert nur den festgeschriebenen Verlauf; Es behält keine nicht festgeschriebenen Dateien bei.

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

   Vom gleichen Anfang an führen Sie updated-main in einer Kopie mit feature/signup-form zusammen und rebasieren feature/signup-form in einer anderen mit updated-main. Wie viele Eltern enthält das neue Tipp-Commit des Themas in jeder Kopie?

   Wählen Sie eine Antwort.

   Beide Exemplare: zwei.

   Beide Exemplare: eins.

   Kopie zusammenführen: zwei. Rebase-Kopie: eins.

   Kopie zusammenführen: eins. Rebase-Kopie: zwei.

   Antwort prüfen
2. Frage 2 von 6

   Frage 2 von 6

   Welche davon sind in beiden Kopien gleich, nachdem die Zusammenführung und das Rebase ohne Konflikte abgeschlossen wurden?

   Wählen Sie jede zutreffende Antwort aus.

   Der Commit, mit dem Ihr Themenzweig begonnen hat

   Der Dateibaum des Tip-Commits

   Die ID des Tip-Commits

   Der Inhalt von docs/integration-note.md

   Antwort prüfen
3. Frage 3 von 6

   Frage 3 von 6Erforderlich

   Was ist nach dem Rebase mit Ihrem ursprünglichen Topic-Commit S passiert?

   Wählen Sie eine Antwort.

   Ein neuer Commit S‘ mit einer neuen ID wurde erstellt; Das alte S ist nur über den Rettungszweig erreichbar.

   S behielt seine ID und nur sein übergeordnetes Element änderte sich.

   S wurde sofort aus dem Repository gelöscht.

   S wurde auf den Server übertragen.

   Antwort prüfen
4. Frage 4 von 6

   Frage 4 von 6

   Ändern Sie die Eingabe: Ihr Thema hat kein eigenes Commit und updated-main steht einfach vor ihm. Sie führen die Zusammenführung mit dem Standardmodus „Schneller Vorlauf wenn möglich, andernfalls ein Zusammenführungs-Commit“ durch. Was geschieht?

   Wählen Sie eine Antwort.

   Git lehnt ab, weil die Zweige nicht auseinander gegangen sind.

   Es wird immer ein Merge-Commit mit zwei übergeordneten Elementen erstellt.

   Die Verzweigungsbezeichnung wird vorwärts verschoben und es wird kein Merge-Commit erstellt.

   Jeder Commit wird mit einer neuen ID neu geschrieben.

   Antwort prüfen
5. Frage 5 von 6

   Frage 5 von 6Erforderlich

   Ein Kollege hat bereits feature/signup-form erstellt und baut darauf auf. Sie möchten, dass der main-Verlauf übersichtlich bleibt. Was ist die sichere Wahl?

   Wählen Sie eine Antwort.

   Rebase und Force-Push, da ein gerader Graph sauberer ist.

   Löschen Sie den Zweig und erstellen Sie ihn erneut mit demselben Namen.

   Führen Sie updated-main in den Zweig ein, damit ihre Commits ihre IDs behalten.

   Setzen Sie den Zweig auf updated-main zurück.

   Antwort prüfen
6. Frage 6 von 6

   Frage 6 von 6Erforderlich

   Welche Readbacks zeigen, dass der Vergleich fair war und wie er endete?

   Wählen Sie jede zutreffende Antwort aus.

   Die beiden Exemplare hatten das gleiche S und N, bevor Sie angefangen haben.

   git rev-parse HEAD^{tree} gibt in beiden Kopien dieselbe ID aus.

   git rev-list --parents -n 1 HEAD gibt drei IDs für die Merge-Kopie und zwei für die Rebase-Kopie aus.

   git rev-parse HEAD gibt in beiden Kopien dieselbe ID aus.

   Antwort prüfen

Melden Sie die beiden übergeordneten Listen, die beiden HEAD-IDs und die beiden Baum-IDs. Erklären Sie, warum gleiche Baum-IDs neben unterschiedlichen HEAD-IDs das erwartete Ergebnis sind. Sagen Sie dann vorher, ohne es zu tun, was eine Standardzusammenführung bewirkt, wenn das Thema kein eigenes Commit hat.

• Gleicher Anfang, andere Geschichte.
• Gleiche Bäume bedeuten nicht gleiche Geschichte.
• Führen Sie eine Fusion durch, wenn andere Ihre Verpflichtungen haben. Rebase nur private.

• Zweige mit abweichendem Verlauf zusammenführen (Lektion 18)
• Fast-Forward-Merges verstehen (Lektion 19)
• Unveröffentlichte Arbeit auf eine neue Basis umstellen (Lektion 20)
• Interaktives Rebase in einer GUI
• Laden Sie GitTree herunter

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