Stellen Sie den beabsichtigten Snapshot bereit und führen Sie Ihren ersten Commit durch

• Erstellen und speichern Sie die ersten beiden Projektdateien in GitTree.
• Bereitstellen und Aufheben der Bereitstellung, ohne dass einer der Vorgänge mit dem Löschen einer Arbeitsdatei verwechselt wird.
• Vergleichen Sie den Index vor dem Festschreiben mit dem Arbeitsbaum.
• Schreiben Sie eine nützliche Zusammenfassung und übertragen Sie nur den vorbereiteten Snapshot.
• Überprüfen Sie die Dateien, die Identität und die verbleibenden Arbeitsänderungen des ersten Commits.

Beginnen Sie dort, wo Lektion 4 endet. Das original gittree-features ist ein gewöhnliches Repository auf unborn main, ohne Commits, Projektdateien oder Remotes. Seine lokale Identität ist GitTree Demo / demo@example.com. Fahren Sie nicht innerhalb der Ergänzung gittree-features-copy von Lektion 4 fort.

Das überprüfte Minimum von GitTree beträgt Git 2.39.0. Das Video wurde mit Git 2.52.0 und GitTree 2.0 auf Ubuntu 24.04 aufgenommen: Die beiden Dateien, ihr Staging und der erste Commit wurden in der App selbst vorgenommen, und die Terminalprüfungen wurden anhand der von der App erstellten Daten oder anhand separater Kopien des Projekts in den Zuständen A, B und C durchgeführt, sodass das Original nie wiedergegeben wurde. Auf macOS oder Windows wurde nichts ausgeführt, und Ubuntu ist das einzige aufgezeichnete Linux-System. Befehlstaste und Windows-Akkorde stammen aus der Keymap-Quelle.

Native Git benötigt kein Konto für einen lokalen Commit. Melden Sie sich in GitTree an und der kostenlose Plan deckt diese Lektion ab. Es ist kein Anbieter, Pro-/Testversion, KI-Entwurf, API-Schlüssel, CI-Runner oder Cloud-Umgebung erforderlich. Fügen Sie keine Fernbedienung hinzu, um einen lokalen Commit durchzuführen.

Ein Commit bedeutet nicht „alles Sichtbare speichern“. In dieser Lektion zeichnet ein normaler Commit den index auf: den kompletten ausgewählten Snapshot. Es erstellt ein Root-Commit und macht darauf aufmerksam. Es drückt nirgendwo hin.

Beim Speichern im Editor wird das working tree aktualisiert. Staging aktualisiert den Index aus der ausgewählten Arbeitsdatei. Das Aufheben der Bereitstellung ändert die Indexauswahl. Es handelt sich nicht um „Verwerfen“ und die Arbeitsdatei wird in unserer Übung nicht entfernt. Vor dem ersten Commit gibt es keine frühere Commit-Version zum Wiederherstellen, sodass eine nicht bereitgestellte neue Datei wieder nicht mehr verfolgt wird.

Eine vorbereitete Ausgabe ist eine nützliche Analogie: Sie können Ihren Arbeitsentwurf nach der Erstellung einer Ausgabe überarbeiten und die vorbereitete Ausgabe dann lokal veröffentlichen, ohne den neueren Entwurf einzubeziehen. Beim Staging handelt es sich nicht um ein Live-Abonnement für spätere Bearbeitungen. Git's add reference dokumentiert diese Auswahl; die Commit-Referenz unterscheidet gewöhnliche Index-Commits von anderen Modi.

Wir verwenden no -a, explizite Commit-Pfad-Argumente, Amend, leeres Commit oder automatisches Stage-All. Der Index ist eine vollständige Beschreibung des nächsten Baums und nicht nur eine Liste geänderter Namen.

README-01 ist ebenfalls bereitgestellt und festgeschrieben. Nach D ist README sauber; index.html bleibt absichtlich nur im Arbeitsbaum geändert. Das Diagramm kann einen neuen Commit haben, während der Status nicht sauber ist.

Verwenden Sie UTF-8, LF und einen letzten Zeilenumbruch. Fügen Sie keine Markdown-Zäune in die gespeicherten Dateien ein. Es gibt noch keine package.json-, CSS-, JS- oder ausführbare Node-Suite. Diese kommen in Lektion 6 an.

README.md – README-01

# GitTree Features

A fictional landing page used to learn Git and GitTree.

All people and addresses in this repository are fictional.
No form submits information to a server.

index.html – HTML-01, vor dem Staging

<!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>
</head>
<body>
  <header class="site-header">
    <a href="#main">GitTree Features</a>
  </header>
  <main id="main">
    <section class="hero" aria-labelledby="hero-title">
      <p class="eyebrow">GitTree Learn demo project</p>
      <h1 id="hero-title">Understand every change.</h1>
      <p id="hero-copy">A clear view of Git history.</p>
    </section>
  </main>
  <footer><p>Built by a fictional team for GitTree Learn.</p></footer>
</body>
</html>

index.html – HTML-01-WORKING, erst nach dem Staging

Ersetzen Sie die gespeicherte Arbeitsdatei durch diesen vollständigen Text after, die frühere Version wurde in den Index aufgenommen:

<!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>
</head>
<body>
  <header class="site-header">
    <a href="#main">GitTree Features</a>
  </header>
  <main id="main">
    <section class="hero" aria-labelledby="hero-title">
      <p class="eyebrow">GitTree Learn demo project</p>
      <h1 id="hero-title">Understand every change.</h1>
      <p id="hero-copy">Choose one change, then check what Git saved.</p>
    </section>
  </main>
  <footer><p>Built by a fictional team for GitTree Learn.</p></footer>
</body>
</html>

Der einzige vorgesehene Ersatz ist die Hero-Copy-Unterstützungszeile. Ändern Sie nicht die Hauptüberschrift oder andere Bytes.

1. Erstellen und speichern Sie die beiden Anfangsdateien

1. Bestätigen Sie den Namen und den Hauptkontext des ursprünglichen Repositorys. Öffnen Sie Command Palette…, Command+Shift+P / Ctrl+Shift+P, geben Sie New File… ein und wählen Sie genau diesen Befehl aus (files.newFile). Ohne Ordnerargument beginnt es im Projektstammverzeichnis.
2. Setzen Sie in New File Path from the project folder auf README.md und wählen Sie dann Create. Erwarten Sie, dass die neue Arbeitsdatei im Dateiarbeitsbereich geöffnet wird. Die Schöpfung lehnt einen bestehenden Weg ab, anstatt ihn zu überschreiben.
3. Fokussieren Sie den bearbeitbaren Inhaltsbereich, fügen Sie den vollständigen README-01-Text ein und wählen Sie dann Save. Alternative: Command+S / Ctrl+S, während der Arbeitseditor den Fokus hat. Erwarten Sie, dass die Anzeige Unsaved changes nach dem tatsächlichen Speichererfolg erlischt.
4. Wiederholen Sie New File… → Pfad index.html → Create. Fügen Sie das vollständige HTML-01 ein, nicht die später funktionierende Variante. Speichern Sie und warten Sie, bis die Anzeige „Nicht gespeichert“ gelöscht wird.
5. Wählen Sie Back to Graph in der Dateisymbolleiste oder den Palettenbefehl Back to Graph (view.returnToGraph). Dann verwenden Sie die Palette Show Working Changes (wip.show). Erwarten Sie README.md und index.html unter Unstaged Files, nichts unter Staged Files.
6. Beachten Sie Stage Changes to Commit, wenn es sich um die primäre Composer-Schaltfläche handelt, während nichts bereitgestellt wird. Seine von der Quelle definierte Aktion inszeniert all funktionierende Änderungen; es bedeutet nicht bereits ein erfolgreiches Commit. Stattdessen verwenden wir bewusstes Staging pro Datei.

Das Speichern eines Editorpuffers ist kein Staging. Das Anzeigen einer Datei in einem Tab ist kein Beweis dafür, dass der letzte Puffer die Festplatte erreicht hat.

2. Bereiten Sie die Dateien sicher vor, entfernen Sie sie sicher und bereiten Sie dann beide Dateien vor

1. Verwenden Sie für README.md unter Unstaged Files die Zeilenaktion Stage File. Tastaturalternative: Wählen Sie nur diese Zeile aus, behalten Sie den Fokus in der nicht bereitgestellten Liste und drücken Sie S; Der Palettenbefehl lautet Stage (wip.stageSelected). Erwarten Sie README.md unter Staged Files.
2. Wählen Sie für diese README-Zeile unter „Staging-Dateien“ die Option Unstage File. Tastaturalternative: Wählen Sie nur diese aus, behalten Sie den Fokus in der bereitgestellten Liste und drücken Sie U; Palettenbefehl Unstage (wip.unstageSelected). Erwarten Sie, dass README.md zu den nicht bereitgestellten Dateien zurückkehrt. Der Arbeitsinhalt bleibt erhalten.
3. Bereitstellen Sie erneut README.md und anschließend index.html mit der Aktion Stage File. Erwarten Sie genau two bereitgestellte Dateipfade.
4. Klicken Sie auf jede gestaffelte Zeile, um deren vollständige Hinzufügung zu überprüfen. index.html muss weiterhin A clear view of Git history. enthalten. Inhalte nicht allein aus der Dateianzahl ableiten.

Die Einzelbuchstaben-Verknüpfungen beziehen sich auf ihre Listen und stellen keine Aufforderung dar, S/U in einen Editor oder eine Zusammenfassung einzugeben. Es wird kein Drag-and-Drop-Bereitstellungsverhalten angenommen.

3. Speichern Sie eine spätere Bearbeitung, ohne sie bereitzustellen

1. Öffnen Sie Show Files (files.focus), Command+Shift+E / Ctrl+Shift+E. Fokussieren Sie index.html im Dateibaum und drücken Sie Enter, um die Arbeitskopie zu öffnen. Alternative: Klicken Sie auf die Registerkarte „Vorhandene gespeicherte Arbeitsdatei“. Arbeiten Sie in der bearbeitbaren File-Ansicht, nicht in einem historischen Blob oder einem bereitgestellten Diff.
2. Ersetzen Sie den gesamten Inhalt durch HTML-01-WORKING oben. Speichern Sie über Save oder Befehl/Strg+S. Warten Sie auf den tatsächlichen Erfolg beim Speichern der Festplatte.
3. Zurück über Back to Graph, dann über Show Working Changes. index.html erscheint jetzt in both Listen. Klicken Sie auf die Zeile „Nicht bereitgestellte Dateien“: Das Diff zeigt die spätere Ersetzung der unterstützenden Zeile.
4. Klicken Sie auf die Zeile „Staging Files“: Der Zusatz „first-commit“ enthält immer noch die frühere unterstützende Zeile. Wählen Sie not „Stage-Datei“ für die neuere Arbeitsbearbeitung oder Stage All Changes jetzt. Das würde den Commit ändern, den Sie vorbereiten.

4. Schreiben Sie die Nachricht und übernehmen Sie den Index

1. Geben Sie im Feld Komponist Summary (Platzhalter Commit summary) genau feat: add the GitTree Features hero ein. Lassen Sie Description leer. Diese Zusammenfassung sagt, was sich geändert hat; Es verspricht keine fertige Website oder eine bestandene Testsuite.
2. Halten Sie Amend Previous Commit ausgeschaltet. Erweitern Sie Commit Options und stellen Sie sicher, dass Skip Hooks (--no-verify), Add Signed-off-by, Different Author, Push After Commit und Allow Empty Commit alle deaktiviert sind. Fügen Sie keine Co-Autoren hinzu und rufen Sie keine KI-Entwurfserstellung auf.
3. Sehen Sie sich die beiden Etappenpfade und die zuvor vorbereitete Heldenreihe noch einmal an. Wählen Sie Commit Changes to 2 Files. Tastaturalternative: Command+Enter / Ctrl+Enter, weitergeleitet über den Palettenbefehl Commit (commit.submit), erst nach Bestätigung des aktiven Repositorys und des Status „Ausstehend“.
4. Warten Sie auf das tatsächliche Ergebnis von Git. Ein erfolgreiches Ergebnis verweist auf einen gemessenen SHA; Kopieren Sie keinen erstellten SHA aus einem Diagramm. Erwarten Sie einen ersten Graph-Commit auf main. In diesem Fall der unveränderten Übermittlung wird der Nachrichtenentwurf nach Erfolg gelöscht.
5. Überprüfen Sie die Post-Commit-Listen: Es bleibt nichts im Staging; index.html verbleibt mit der späteren Zeile unter „Nicht bereitgestellte Dateien“. Klicken Sie not auf „Stage Changes to Commit“, um dieses beabsichtigte Ergebnis „abzuschließen“.

Die angezeigte Dateianzahl entspricht zwei bereitgestellten Pfaden, nicht drei Zeilen in zwei Listen. „Push After Commit“ ist eine separate Folgeauswahl; Es ist ausgeschaltet und es gibt keine Fernbedienung.

Führen Sie <course-parent>/gittree-features aus und ersetzen Sie den Platzhalter durch Ihr reserviertes tatsächliches übergeordnetes Element. Wenn Sie bereits eine App-Mutation durchgeführt haben, inspect its resulting state; Spielen Sie die entsprechende Mutation nicht erneut ab und gelangen Sie versehentlich über den Kontrollpunkt hinaus.

Gespeicherte Dateien vor dem Staging

git status --short

Beobachtet:

?? README.md
?? index.html

Versuche absichtlich ein normales Commit ohne bereitgestellten Inhalt:

git commit --quiet -m "feat: add the GitTree Features hero"

Beobachtete Standardausgabe mit Exit 1, kein Standardfehler:

On branch main

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	README.md
	index.html

nothing added to commit but untracked files present (use "git add" to track)

Es wurde kein Commit erstellt. Dieser negative Fall erklärt, warum die Auswahl von Dateien wichtig ist. Verwenden Sie kein leeres Commit, um es zu umgehen.

Native Stage/Unstage-Äquivalente

In einer separaten Wiedergabe desselben gespeicherten Dateistatus:

git add -- README.md
git rm --cached --quiet -- README.md

Beide Befehle waren stillschweigend erfolgreich. --cached ist wichtig: Es entfernt den neuen Eintrag aus dem Index, not the working file. Die überprüften README-Bytes blieben unverändert und der Kurzstatus zeigte erneut die beiden nicht verfolgten Dateien. Dies ist speziell ein Beispiel für eine nicht festgeschriebene neue Datei. Verallgemeinern Sie es nicht auf das Löschen verfolgter Projektdateien.

Bereiten Sie beides vor:

git add -- README.md index.html
git status --short
git diff --cached --stat

Beobachteter Status:

A  README.md
A  index.html

Beobachtete Zusammenfassung:

 README.md  |  6 ++++++
 index.html | 21 +++++++++++++++++++++
 2 files changed, 27 insertions(+)

Die Statistikzusammenfassung zählt Zeilen, nicht die Richtigkeit. Überprüfen Sie den tatsächlich bereitgestellten Inhalt, bevor Sie ihn festlegen.

Nach dem Speichern der späteren Arbeitsbearbeitung

git status --short
git diff -- index.html

Beobachteter Status:

A  README.md
AM index.html

Beobachteter Arbeitsunterschied:

diff --git a/index.html b/index.html
index 5470374..27f8718 100644
--- a/index.html
+++ b/index.html
@@ -13,7 +13,7 @@
     <section class="hero" aria-labelledby="hero-title">
       <p class="eyebrow">GitTree Learn demo project</p>
       <h1 id="hero-title">Understand every change.</h1>
-      <p id="hero-copy">A clear view of Git history.</p>
+      <p id="hero-copy">Choose one change, then check what Git saved.</p>
     </section>
   </main>
   <footer><p>Built by a fictional team for GitTree Learn.</p></footer>

Hierbei handelt es sich um gemessene Datei-Blob-Abkürzungen aus dem genauen LF-Inhalt, nicht um fiktive Commit-SHAs. Der Abstand und die Länge der Abkürzungen für Kurzstatus können je nach Formatierungskonfiguration variieren. Die beiden Vergleiche müssen gleich bleiben.

Lesen Sie die genaue vorbereitete Datei:

git show :index.html

Vollständige beobachtete Ausgabe:

<!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>
</head>
<body>
  <header class="site-header">
    <a href="#main">GitTree Features</a>
  </header>
  <main id="main">
    <section class="hero" aria-labelledby="hero-title">
      <p class="eyebrow">GitTree Learn demo project</p>
      <h1 id="hero-title">Understand every change.</h1>
      <p id="hero-copy">A clear view of Git history.</p>
    </section>
  </main>
  <footer><p>Built by a fictional team for GitTree Learn.</p></footer>
</body>
</html>

Festschreiben und überprüfen

Nur in der nativen Wiedergabe, ohne die spätere Bearbeitung erneut bereitzustellen:

git commit --quiet -m "feat: add the GitTree Features hero"

Beobachtet: keine Ausgabe, Beenden 0. Dieses Fixture hatte keine aktiven Hooks/Signaturen und nur die fiktive lokale Identität. Deaktivieren Sie nicht die Hooks/Signaturen eines echten Projekts, um den Erfolg des Tutorials zu erzwingen.

Überprüfen Sie entweder das native oder das tatsächliche App-Ergebnis:

git log -1 --format="%s%n%an <%ae>%n%cn <%ce>"
git rev-list --count HEAD
git ls-tree --name-only HEAD
git status --short
git diff --cached
git remote

Beobachtete Ausgaben in der Reihenfolge der ersten vier Befehle:

feat: add the GitTree Features hero
GitTree Demo <demo@example.com>
GitTree Demo <demo@example.com>
1
README.md
index.html
 M index.html

Die letzten beiden Befehle erzeugten jeweils no output and exited 0. Die Arbeitsbearbeitung bleibt bestehen; Es existiert keine Fernbedienung. Dies ist ein lokaler erster Commit, kein Upload.

Zur unabhängigen Inhaltsbestätigung hat git show HEAD:index.html den oben angezeigten vollständigen HTML-01-Text als vorbereitete Ausgabe zurückgegeben; git diff -- index.html zeigte immer noch die genaue Ersetzung der unterstützenden Zeile. Der Index stimmte für beide Pfade mit HEAD überein. Die neuere Datei ging nicht verloren.

Am Ende dieser Lektion weist main auf genau einen Commit mit der deklarierten Zusammenfassung und dem fiktiven Autor/Committer hin. HEAD und Index enthalten README-01 und HTML-01; Working index.html enthält HTML-01-WORKING. Status hat ein führendes Leerzeichen, dann M für index.html. Es gibt keine Fernbedienung.

„Bereinigen“ Sie die absichtliche Bearbeitung nicht, führen Sie keinen zweiten Commit durch, ändern Sie das Stammverzeichnis nicht und fügen Sie das optionale Übungsnotizbuch nicht hinzu, bevor Sie diesen Prüfpunkt an Lektion 6 übergeben. Jedes spätere Bereinigungsfortsetzungsnotizbuch gehört in eine separat aufbewahrte Variante, nicht in diesen ersten Commit mit zwei Dateien.

• Saving without staging: Festplattenbytes und ausgewählte Commit-Bytes unterscheiden sich.
• Staging again after the deliberate edit: gültiges Git-Verhalten, aber die neuere Zeile würde in den Commit eingehen und das Ergebnis dieser Lektion ändern.
• Counting all visible rows as staged files: ein Pfad kann bereitgestellte und nicht bereitgestellte Vergleiche haben.
• Using Stage All Changes as a final cleanup: würde die absichtlich weggelassene Bearbeitung auswählen.
• Enabling amend or automatic push: das sind verschiedene Vorgänge mit unterschiedlichem Umfang.
• Calling unstage Discard: unstage bearbeitet die Indexauswahl; Mit „Verwerfen“ können Arbeitsinhalte entfernt werden.

Wenn „Neue Datei“ einen vorhandenen Pfad ablehnt, brechen Sie den Vorgang ab und überprüfen Sie ihn. Überschreiben Sie keine unbekannten Inhalte. Wenn der Editor meldet, dass sich die Festplatte geändert hat, behalten Sie beide Versionen bei und verwenden Sie die Steuerelemente Review Changes, Reload from Disk oder Keep Editing entsprechend dem tatsächlichen Status. Wählen Sie nicht blind Overwrite with My Edits aus.

Wenn der Commit blockiert ist, weil nichts bereitgestellt wird, wählen Sie die gewünschten Dateien aus und überprüfen Sie sie. Wenn die Identität fehlt, überprüfen Sie die lokalen Einstellungen aus Lektion 4; Ein fehlgeschlagener Versuch kann Set up your Git identity mit einem expliziten Repository-Ziel anbieten. Dies rechtfertigt keinen globalen Identitätsschreibvorgang und das Speichern der Identität bedeutet nicht, dass der Commit automatisch erfolgreich war.

Wenn Git einen Commit ablehnt oder ein Hook fehlschlägt, lesen Sie Hook Output, sofern verfügbar. Der in der Quelle definierte Ablehnungstext lautet The commit was not created. Your message and staged changes are unchanged.. Korrigieren Sie die angegebene Ursache und überprüfen Sie den Index erneut, bevor Sie es erneut versuchen. Markieren Sie Skip Hooks nicht, nur um einen grünen Take zu erzeugen. Überprüfen Sie den tatsächlichen HEAD nach unsicheren Ergebnissen noch einmal, bevor Sie ihn erneut einreichen.

Wenn ein Commit mit unerwartetem Inhalt erstellt wurde, stoppen Sie den tatsächlichen SHA, den Arbeits-/Indexstatus und die Meldung und zeichnen Sie diese auf. Ändern Sie die Daten nicht sofort, setzen Sie sie zurück oder klicken Sie nicht auf „Verwerfen“. Wenn Sie die Konfiguration jetzt ändern, werden die Metadaten, die bereits in diesem Commit gespeichert sind, nicht geändert.

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

   Sie erstellen index.html und schließen den Vorgang „Speichern“ im Editor ab, ohne ihn bereitzustellen. Was hat das Sparen begründet?

   Wählen Sie eine Antwort.

   Der Puffer hat die Arbeitsdatei erreicht

   Auf main ist ein Commit vorhanden

   Git hat alle späteren Änderungen ausgewählt

   Antwort prüfen
2. Frage 2 von 6

   Frage 2 von 6

   Sie stellen die neue README-Datei bereit und entfernen sie dann vor dem ersten Commit. Welche Aussagen sind richtig?

   Wählen Sie jede zutreffende Antwort aus.

   git rm ohne --cached ist das nachweislich sichere Äquivalent

   Unstage File und Discard sind Synonyme

   Der gespeicherte Text verbleibt auf der Festplatte

   README kehrt in diesem Fixture zu „untracked“ zurück

   Antwort prüfen
3. Frage 3 von 6

   Frage 3 von 6Erforderlich

   Beide Dateien werden bereitgestellt, dann wird HTML-01-WORKING ohne erneutes Staging gespeichert. Welches Ergebnis ist nach dem gewöhnlichen Commit korrekt?

   Wählen Sie eine Antwort.

   Es werden zwei Commits erstellt, einer pro Datei

   Es wird immer die neueste Editorversion festgeschrieben

   Ein Commit enthält README-01 und HTML-01; Die Arbeitsbearbeitung bleibt bestehen

   Die Fernbedienung enthält jetzt den Helden

   Antwort prüfen
4. Frage 4 von 6

   Frage 4 von 6Erforderlich

   Stellen Sie index.html in einer separaten Wiedergabe erneut bereit, nachdem Sie die neuere Version gespeichert haben, und übertragen Sie dann beide Dateien. Was sagen Sie voraus?

   Wählen Sie eine Antwort.

   Neuere unterstützende Zeile im Commit, mit sauberem Status

   Drei festgeschriebene Dateien, da der HTML-Code zweimal vorkam

   Alte unterstützende Zeile, da beim Staging nur Dateien gezählt werden

   Globale Identitätsänderungen

   Antwort prüfen
5. Frage 5 von 6

   Frage 5 von 6

   Zwei Dateien sind nicht bereitgestellt und nichts ist bereitgestellt. Auf der Schaltfläche steht „Stage Changes to Commit“. Was macht es?

   Wählen Sie eine Antwort.

   Stellt zuerst alle aktuellen Arbeitsänderungen bereit

   Überträgt die Dateien sofort und ohne Überprüfung

   Verwirft Dateien, bis der Index sauber ist

   Antwort prüfen
6. Frage 6 von 6

   Frage 6 von 6Erforderlich

   Überprüfen Sie das fertige Original mit den genannten nativen Befehlen oder lesen Sie das vollständige Transkript, wenn keine Tools verfügbar sind. Welche Beobachtungen belegen gemeinsam das Ergebnis?

   Wählen Sie jede zutreffende Antwort aus.

   Leerer zwischengespeicherter Diff, Leerzeichen-M-Status für index.html, kein Remote

   HEAD und Index enthalten das frühere HTML; Arbeitsdatei ist neuer

   Zählen Sie 1, das genaue Thema und den fiktiven Autor/Committen

   Ein vorübergehender CI-Lauf

   Ein vollständig sauberer Zustand ist erforderlich

   Antwort prüfen

Nutzen Sie die Status-/Inhaltsabfragen des Artikels für Ihr fertiges Original. Erklären Sie, warum genau ein Commit und eine verbleibende funktionierende Änderung beide korrekt sind. Notieren Sie Ihre Vorhersage, bevor Sie die vorbereitete Datei lesen.

Stellen Sie für einen separate disposable replay only die später bearbeitete index.html bereit, bevor Sie sie festschreiben. Sagen Sie voraus, dass die neuere Zeile aufgezeichnet wird und der Status „sauber“ wird. Ändern Sie nicht das Original, um diese Alternative durchzuführen. Wenn noch keine Browserübung vorhanden ist, verwenden Sie die beiden Transkripte und erläutern Sie die unterschiedlichen Ergebnisse.

• Beim Speichern ändert sich die Arbeitsdatei; Beim Staging werden Inhalte für den nächsten gewöhnlichen Commit ausgewählt.
• Der erste Commit zeichnet den Index auf und erweitert den lokalen Hauptspeicher, ohne ihn zu pushen.
• Überprüfen Sie Inhalt, Identität und übrig gebliebene Arbeiten separat. ein schmutziges Ergebnis kann beabsichtigt sein.

• Vorhersagen, was Ihr nächstes Commit enthalten wird (Lektion 3)
• Erstellen Sie Ihr Kurs-Repository und unterscheiden Sie dann zwischen Klonen und Öffnen (Lektion 4)
• Laden Sie GitTree herunter

Bühne – تجهيز; unstage – إلغاء التجهيز; begehen – إيداع; Index – الفهرس; Arbeitsbaum – مجلد العمل; untracked – غير مُتتبَّع; Autor – المؤلف; Committer – المُودِع. „Verwerfen“ bedeutet „Verwerfen“ und ist nicht dasselbe wie „Unstage“.