From b50f8e43d0df868bede1a633760f38aca92543f6 Mon Sep 17 00:00:00 2001 From: dscho Date: Tue, 9 Jul 2024 04:33:02 +0000 Subject: [PATCH] book: update de Updated via the `update-book.yml` GitHub workflow. --- _sync_state/book-de.sha | 2 +- ...-Schritte-Was-ist-Versionsverwaltung?.html | 2 +- .../de/v2/Git-Branching-Remote-Branches.html | 2 +- content/book/de/v2/Git-Grundlagen-Taggen.html | 2 +- ...tandardbefehle-Plumbing-and-Porcelain.html | 34 ++-- ...ie-Referenzspezifikation-engl-Refspec.html | 44 ++--- .../book/de/v2/Git-Interna-Git-Objekte.html | 156 +++++++-------- .../de/v2/Git-Interna-Git-Referenzen.html | 66 +++---- ...it-Interna-Packdateien-engl-Packfiles.html | 46 ++--- .../v2/Git-Interna-Transfer-Protokolle.html | 72 +++---- ...na-Wartung-und-Datenwiederherstellung.html | 180 +++++++++--------- .../de/v2/Git-Interna-Zusammenfassung.html | 10 +- content/book/de/v2/_index.html | 2 +- ...erhalten.html => _globales_verhalten.html} | 2 +- 14 files changed, 310 insertions(+), 310 deletions(-) rename content/book/de/v2/ch00/{_globals_verhalten.html => _globales_verhalten.html} (71%) diff --git a/_sync_state/book-de.sha b/_sync_state/book-de.sha index e7174162bb..75ae509759 100644 --- a/_sync_state/book-de.sha +++ b/_sync_state/book-de.sha @@ -1 +1 @@ -90e884a3a1fe1dc84811ecf901f40abd8e0322a2 +70417a7a38a8b4e9c9b51fe5bafd3bac09fbd2ad diff --git a/content/book/de/v2/Erste-Schritte-Was-ist-Versionsverwaltung?.html b/content/book/de/v2/Erste-Schritte-Was-ist-Versionsverwaltung?.html index 1164adb7eb..f669f7ae8a 100644 --- a/content/book/de/v2/Erste-Schritte-Was-ist-Versionsverwaltung?.html +++ b/content/book/de/v2/Erste-Schritte-Was-ist-Versionsverwaltung?.html @@ -26,7 +26,7 @@

Was ist Versionsverwaltung?

-Was ist „Versionsverwaltung“, und warum sollten Sie sich dafür interessieren? +Was ist „Versionsverwaltung“, und warum solltest du dich dafür interessieren? Versionsverwaltung ist ein System, welches die Änderungen an einer oder einer Reihe von Dateien über die Zeit hinweg protokolliert, sodass man später auf eine bestimmte Version zurückgreifen kann. Die Dateien, die in den Beispielen in diesem Buch unter Versionsverwaltung gestellt werden, enthalten Quelltext von Software. Tatsächlich kann in der Praxis nahezu jede Art von Datei per Versionsverwaltung nachverfolgt werden.

diff --git a/content/book/de/v2/Git-Branching-Remote-Branches.html b/content/book/de/v2/Git-Branching-Remote-Branches.html index bde3e817ae..1daa92f063 100644 --- a/content/book/de/v2/Git-Branching-Remote-Branches.html +++ b/content/book/de/v2/Git-Branching-Remote-Branches.html @@ -26,7 +26,7 @@

Remote-Branches

Remote-Tracking-Branches sind Referenzen auf den Zustand von Remote-Branches. -Sie sind lokale Referenzen, die du nicht manuell ändern kannst. Sie werden automatisch für dich geändert, sobald Sie irgendeine Netzwerkkommunikation durchführen. +Sie sind lokale Referenzen, die du nicht manuell ändern kannst. Sie werden automatisch für dich geändert, sobald du irgendeine Netzwerkkommunikation durchführst. Betrachte sie als Lesezeichen, die daran erinnern, wo die Branches in deinem Remote-Repositorys das letzte Mal standen, als du dich mit ihnen verbunden hast.

diff --git a/content/book/de/v2/Git-Grundlagen-Taggen.html b/content/book/de/v2/Git-Grundlagen-Taggen.html index cb888d7948..3461c250b7 100644 --- a/content/book/de/v2/Git-Grundlagen-Taggen.html +++ b/content/book/de/v2/Git-Grundlagen-Taggen.html @@ -278,7 +278,7 @@

Tags teilen

git push pusht beide Arten von Tags

git push <remote> --tags wird sowohl Lightweight- als auch Annotated-Tags pushen. -Es gibt zur Zeit keine Möglichkeit, nur Lightweight-Tags zu pushen, aber wenn Sie git push <remote> --follow-tags verwenden, werden nur annotierte Tags an den Remote gepusht.

+Es gibt zur Zeit keine Möglichkeit, nur Lightweight-Tags zu pushen, aber wenn du git push <remote> --follow-tags verwendest, werden nur annotierte Tags an den Remote gepusht.

diff --git a/content/book/de/v2/Git-Interna-Basisbefehle-und-Standardbefehle-Plumbing-and-Porcelain.html b/content/book/de/v2/Git-Interna-Basisbefehle-und-Standardbefehle-Plumbing-and-Porcelain.html index 7737da28dc..9d6f0d21eb 100644 --- a/content/book/de/v2/Git-Interna-Basisbefehle-und-Standardbefehle-Plumbing-and-Porcelain.html +++ b/content/book/de/v2/Git-Interna-Basisbefehle-und-Standardbefehle-Plumbing-and-Porcelain.html @@ -17,13 +17,13 @@ title: Git - Basisbefehle und Standardbefehle (Plumbing and Porcelain) --- -

Sie sind möglicherweise von einem der vorherigen Kapitel direkt zu diesem Kapitel gesprungen. Oder aber Sie sind jetzt hier gelandet, nachdem Sie das gesamte Buch chronologisch bis zu diesem Punkt gelesen haben. Ganz egal, wir hier das Innenleben und die Implementierung von Git behandeln. +

Möglicherweise bist du von einem der vorherigen Kapitel direkt zu diesem Kapitel gesprungen. Oder aber du bist jetzt hier gelandet, nachdem du das gesamte Buch chronologisch bis zu diesem Punkt gelesen hast. Wie auch immer, wir werden hier das Innenleben und die Implementierung von Git behandeln. Wir finden, dass das Verstehen dieser Informationen von grundlegender Bedeutung ist, um zu verstehen, wie hilfreich und extrem leistungsfähig Git ist. Andere haben jedoch argumentiert, dass es für Anfänger verwirrend und unnötig komplex sein kann. -Daher haben wir diese Informationen zum letzten Kapitel des Buches gemacht, damit Sie sie früh oder später in Ihrem Lernprozess lesen können. -Wir überlassen es Ihnen, das zu entscheiden.

Jetzt wo sie hier sind, lassen sie uns anfangen. -Erstens, wenn es noch nicht klar ist, ist Git grundsätzlich ein inhaltsadressierbares Dateisystem mit einer aufgesetzten VCS-Benutzeroberfläche. -Sie werden in Kürze mehr darüber erfahren, was dies bedeutet.

In den Anfängen von Git (meist vor 1.5) war die Benutzeroberfläche sehr viel komplexer, da dieses Dateisystem mehr im Vordergrund stand als ein hochglänzendes VCS. -In den letzten Jahren wurde die Benutzeroberfläche weiterentwickelt, bis sie so aufgeräumt und benutzerfreundlich ist wie in vielen anderen Systemen auch. Die Vorurteile gegenüber der früheren Git-Benutzeroberfläche, die komplex und schwierig zu erlernen war, blieben jedoch erhalten

Die inhaltsadressierbare Dateisystemschicht ist erstaunlich abgefahren, deshalb werden wir es als Erstes in diesem Kapitel behandeln. Anschließend lernen Sie die Transportmechanismen und die Repository-Wartungsaufgaben kennen, mit denen Sie sich möglicherweise befassen müssen.

+Daher haben wir diese Informationen zum letzten Kapitel des Buches gemacht, damit du sie früher oder später in deinem Lernprozess lesen kannst. +Wir überlassen es dir, das zu entscheiden.

Jetzt wo du hier bist, lass uns anfangen. +Erstens, wenn es noch nicht klar ist, ist Git grundsätzlich ein inhalts-adressierbares Dateisystem mit einer aufgesetzten VCS-Benutzeroberfläche. +Du wirst in Kürze mehr darüber erfahren, was dies bedeutet.

In den Anfängen von Git (meist vor 1.5) war die Benutzerschnittstelle sehr viel komplexer, da dieses Dateisystem mehr im Vordergrund stand als ein hochglänzendes VCS. +In den letzten Jahren wurde die Benutzerschnittstelle weiterentwickelt, bis sie so aufgeräumt und benutzerfreundlich ist wie in vielen anderen Systemen auch. Die Vorurteile gegenüber der früheren Git-Benutzerschnittstelle, die komplex und schwierig zu erlernen war, blieben jedoch erhalten.

Die inhalts-adressierbare Dateisystemschicht ist erstaunlich abgefahren, deshalb werden wir es als Erstes in diesem Kapitel behandeln. Anschließend lernst du die Transportmechanismen und die Repository-Wartungsaufgaben kennen, mit denen du dich möglicherweise befassen musst.

Basisbefehle und Standardbefehle (Plumbing and Porcelain)

In diesem Buch wird in erster Linie beschrieben, wie Git mit etwa 30 Standardbefehlen wie checkout, branch, remote usw. verwendet wird. @@ -31,14 +31,14 @@

Basisbefehle und Standardbefehle (Plumbing and Porc Diese Befehle werden im Allgemeinen als Basisbefehle von Git bezeichnet, während die benutzerfreundlicheren Befehle als Standardbefehle bezeichnet werden.

-

Wie Sie bereits bemerkt haben, befassen sich die ersten neun Kapitel dieses Buches fast ausschließlich mit Standardbefehlen. -In diesem Kapitel werden Sie sich jedoch hauptsächlich mit den Basisbefehle der niedrigeren Ebene befassen. Diese ermöglichen Ihnen den Zugriff auf das Innenleben von Git und helfen Ihnen dabei zu demonstrieren, wie und warum Git das tut, was es tut. +

Wie du bereits bemerkt hast, befassen sich die ersten neun Kapitel dieses Buches fast ausschließlich mit Standardbefehlen. +In diesem Kapitel wirst du dich jedoch hauptsächlich mit den Basisbefehle der niedrigeren Ebene befassen. Diese ermöglichen dir den Zugriff auf das Innenleben von Git und helfen dir dabei zu demonstrieren, wie und warum Git das tut, was es tut. Viele dieser Befehle sollten nicht manuell in der Befehlszeile verwendet werden, sondern als Bausteine für neue Tools und benutzerdefinierte Skripts genutzt werden.

-

Wenn Sie git init in einem neuen oder vorhandenen Verzeichnis ausführen, erstellt Git das .git Verzeichnis, in dem sich fast alles befindet, was Git speichert und bearbeitet. -Wenn Sie Ihr Repository sichern oder klonen möchten, erhalten Sie beim Kopieren dieses einzelnen Verzeichnisses fast alles, was Sie benötigen. -Dieses gesamte Kapitel befasst sich im Wesentlichen mit dem, was Sie in diesem Verzeichnis sehen können. +

Wenn du git init in einem neuen oder vorhandenen Verzeichnis ausführst, erstellt Git das .git Verzeichnis, in dem sich fast alles befindet, was Git speichert und bearbeitet. +Wenn du dein Repository sichern oder klonen möchtest, erhältst du beim Kopieren dieses einzelnen Verzeichnisses fast alles, was du benötigst. +Dieses gesamte Kapitel befasst sich im Wesentlichen mit dem, was du in diesem Verzeichnis finden kannst. So sieht ein neu initialisiertes .git -Verzeichnis normalerweise aus:

@@ -54,15 +54,15 @@

Basisbefehle und Standardbefehle (Plumbing and Porc

-

Abhängig von Ihrer Git-Version sehen Sie dort möglicherweise zusätzlichen Inhalt, aber dies ist ein neu erstelltes git init Repository – das sehen sie standardmäßig. -Die description Datei wird nur vom GitWeb-Programm verwendet, machen Sie sich also keine Sorgen darum. -Die config Datei enthält Ihre projektspezifischen Konfigurationsoptionen, und das info Verzeichnis enthält eine globale Ausschlussdatei für ignorierte Muster, die Sie nicht in einer .gitignore Datei verfolgen möchten. -Das hooks Verzeichnis enthält Ihre client- oder serverseitigen Hook-Skripte, die ausführlich in }}">Git Hooks beschrieben werden.

+

Abhängig von deiner Git-Version siehst du dort möglicherweise zusätzlichen Inhalt, aber dies ist ein neu erstelltes git init Repository – das solltest du standardmäßig sehen. +Die description Datei wird nur vom GitWeb-Programm verwendet, du brauchst sie also nicht weiter zu beachten. +Die config Datei enthält deine projektspezifischen Konfigurationsoptionen, und das info Verzeichnis enthält eine globale Ausschlussdatei für ignorierte Muster, die du nicht in einer .gitignore Datei verfolgen möchtest. +Das hooks Verzeichnis enthält deine client- oder serverseitigen Hook-Skripte, die ausführlich in }}">Git Hooks beschrieben werden.

Dies hinterlässt vier wichtige Einträge: die HEAD – und (noch zu erstellenden) 'index` Dateien sowie die objects – und refs Verzeichnisse. Dies sind die Kernelemente von Git. -Das objects -Verzeichnis speichert den gesamten Inhalt für Ihre Datenbank, das refs Verzeichnis speichert Zeiger auf Commit-Objekte in diesen Daten (Branches, Tags, Remotes, usw.) und die HEAD Datei zeigt auf den Branch, den Sie gerade ausgecheckt haben. In der index Datei speichert Git Ihre Staging-Bereichsinformationen. -Sie werden sich nun jeden dieser Abschnitte genauer ansehen, um zu sehen, wie Git funktioniert.

+Das objects -Verzeichnis speichert den gesamten Inhalt für deine Datenbank, das refs Verzeichnis speichert Zeiger auf Commit-Objekte in diesen Daten (Branches, Tags, Remotes, usw.) und die HEAD Datei zeigt auf den Branch, den du gerade ausgecheckt hast. In der index Datei speichert Git deine Staging-Bereichsinformationen. +Du wirst dir nun jeden dieser Abschnitte genauer ansehen, um zu sehen, wie Git funktioniert.

\ No newline at end of file diff --git a/content/book/de/v2/Git-Interna-Die-Referenzspezifikation-engl-Refspec.html b/content/book/de/v2/Git-Interna-Die-Referenzspezifikation-engl-Refspec.html index cf393af37c..253621c814 100644 --- a/content/book/de/v2/Git-Interna-Die-Referenzspezifikation-engl-Refspec.html +++ b/content/book/de/v2/Git-Interna-Die-Referenzspezifikation-engl-Refspec.html @@ -20,7 +20,7 @@

Die Referenzspezifikation (engl. Refspec)

In diesem Buch haben wir simple Zuordnungen von remote Branches zu lokalen Referenzen verwendet, diese können jedoch komplexer sein. -Angenommen, Sie haben die letzten Abschnitte mitverfolgt und ein kleines lokales Git-Repository erstellt, und möchten nun eine remote hinzufügen:

+Angenommen, du hast die letzten Abschnitte mitverfolgt und ein kleines lokales Git-Repository erstellt, und möchtest nun einen remote hinzufügen:

@@ -28,7 +28,7 @@

Die Referenzspezifikation (engl. Refspec)

-

Durch Ausführen des obigen Befehls wird ein Abschnitt zur .git/config Datei Ihres Repositorys hinzugefügt. Es wird der Name des Remote-Repositorys (origin), die URL des Remote-Repositorys und die refspec angegeben sind, die zum Abrufen verwendet werden soll:

+

Durch Ausführen des obigen Befehls wird ein Abschnitt zur .git/config Datei deines Repositorys hinzugefügt. Es wird der Name des Remote-Repositorys (origin), die URL des Remote-Repositorys und die refspec angegeben sind, die zum Abrufen verwendet werden soll:

@@ -43,7 +43,7 @@

Die Referenzspezifikation (engl. Refspec)

In der Standardeinstellung, die automatisch von einem Befehl git remote add origin geschrieben wird, ruft Git alle Referenzen unter refs/heads/ auf dem Server ab und schreibt sie lokal in refs/remotes/origin/. -Wenn sich auf dem Server also ein master Branch befindet, können Sie auf das Log dieses Branches lokal zugreifen, indem Sie eine der folgenden Aktionen ausführen:

+Wenn sich auf dem Server also ein master Branch befindet, kannst du auf das Log dieses Branches lokal zugreifen, indem du eine der folgenden Aktionen ausführst:

@@ -56,7 +56,7 @@

Die Referenzspezifikation (engl. Refspec)

Sie sind alle gleichwertig, da Git sie zu refs/remotes/origin/master erweitert.

-

Wenn Git stattdessen jedes Mal nur den master Branch und nicht jeden anderen Branch auf dem Remote-Server pullen soll, können Sie die Abrufzeile so ändern, dass sie nur auf diesen Branch verweist:

+

Wenn Git stattdessen jedes Mal nur den master Branch und nicht jeden anderen Branch auf dem Remote-Server pullen soll, kannst du die Abrufzeile so ändern, dass sie nur auf diesen Branch verweist:

@@ -65,8 +65,8 @@

Die Referenzspezifikation (engl. Refspec)

Dies ist nur die Standard Refspec für git fetch für diesen Remote. -Wenn Sie einen einmaligen Abruf durchführen möchten, können Sie die spezifische Refspec auch in der Befehlszeile angeben. -Um den master Branch auf dem Remote lokal nach origin/mymaster zu pullen, können Sie Folgendes ausführen:

+Wenn du einen einmaligen Abruf durchführen möchtest, kannst du die spezifische Refspec auch in der Befehlszeile angeben. +Um den master Branch auf dem Remote lokal nach origin/mymaster zu pullen, kannst du Folgendes ausführen:

@@ -74,8 +74,8 @@

Die Referenzspezifikation (engl. Refspec)

-

Sie können auch mehrere Refspecs angeben. -In der Befehlszeile können Sie mehrere Branches wie folgt pullen:

+

Du kannst auch mehrere Refspecs angeben. +In der Befehlszeile kannst du mehrere Branches wie folgt pullen:

@@ -88,11 +88,11 @@

Die Referenzspezifikation (engl. Refspec)

In diesem Fall wurde der master Branch pull abgelehnt, da er nicht als Fast-Forward aufgeführt war. -Sie können dies überschreiben, indem Sie das + vor der Refspec angeben.

+Du kannst dies überschreiben, indem du das + vor der Refspec angibst.

-

Sie können auch mehrere Refspecs zum Abrufen in Ihrer Konfigurationsdatei angeben. -Wenn Sie immer die Branches master und experiment vom origin Remote abrufen möchten, fügen Sie zwei Zeilen hinzu:

+

Du kannst auch mehrere Refspecs zum Abrufen in deiner Konfigurationsdatei angeben. +Wenn du immer die Branches master und experiment vom origin Remote abrufen möchtest, füge zwei Zeilen hinzu:

@@ -103,7 +103,7 @@

Die Referenzspezifikation (engl. Refspec)

-

Seit Git 2.6.0 können Sie partielle Globs in Pattern verwenden, um mehrere Branches anzupassen, dann funktioniert das hier:

+

Seit Git 2.6.0 kannst du partielle Globs in Pattern verwenden, um mehrere Branches anzupassen, dann funktioniert das hier:

@@ -111,8 +111,8 @@

Die Referenzspezifikation (engl. Refspec)

-

Noch besser, Sie können Namespaces (oder Verzeichnisse) verwenden, um dasselbe mit mehr Struktur zu erreichen. -Wenn Sie ein QS-Team haben, das eine Reihe von Branches pusht, und Sie möchten nur den master Branch und einen der Branches des QS-Teams erhalten, dann können Sie einen Konfigurationsabschnitt wie diesen verwenden:

+

Noch besser, du kannst Namespaces (oder Verzeichnisse) verwenden, um dasselbe mit mehr Struktur zu erreichen. +Wenn du ein QS-Team hast, das eine Reihe von Branches pusht, und du möchtest nur den master Branch und einen der Branches des QS-Teams erhalten, dann kannst du einen Konfigurationsabschnitt wie diesen verwenden:

@@ -123,13 +123,13 @@

Die Referenzspezifikation (engl. Refspec)

-

Wenn Sie über einen komplexen Workflow-Prozess verfügen, bei dem QS-Team und Entwickler Branches pushen und Integrationsteams auf Remotebranches pushen bzw. daran zusammenarbeiten, können Sie sie auf diese Weise problemlos mit Namespaces versehen.

+

Wenn du über einen komplexen Workflow-Prozess verfügst, bei dem QS-Team und Entwickler Branches pushen und Integrationsteams auf Remotebranches pushen bzw. daran zusammenarbeiten, kannst du sie auf diese Weise problemlos mit Namespaces versehen.

Pushende Refspecs

-

Es ist schön, dass Sie auf diese Weise Referenzen mit Namespaces abrufen können, aber wie bringt das QS-Team seine Branches überhaupt an die erste Stelle eines Namespace qa/? -Sie erreichen dies, indem Sie Refspecs zum Pushen verwenden.

+

Es ist schön, dass du auf diese Weise Referenzen mit Namespaces abrufen kannst, aber wie bringt das QS-Team seine Branches überhaupt an die erste Stelle eines Namespace qa/? +Du erreichst dies, indem du Refspecs zum Pushen verwendest.

Wenn das QS-Team seinen master Branch auf qa/master auf dem Remote-Server verschieben möchte, kann folgendes ausgeführt werden:

@@ -161,8 +161,8 @@

Pushende Refspecs

-

Sie können die Refspec nicht zum Abrufen von einem Repository und zum Verschieben auf ein anderes Repository verwenden. -Ein Beispiel wie das geht finden Sie unter }}">Dein öffentliches GitHub-Repository aktuell halten.

+

Du kannst die Refspec nicht zum Abrufen von einem Repository und zum Verschieben auf ein anderes Repository verwenden. +Ein Beispiel wie das geht findest du unter }}">Dein öffentliches GitHub-Repository aktuell halten.

@@ -172,7 +172,7 @@

Pushende Refspecs

Löschende Referenzen

-

Sie können mit Refspec auch Verweise vom Remote-Server löschen, indem Sie Folgendes ausführen:

+

Du kannst mit Refspec auch Verweise vom Remote-Server löschen, indem du Folgendes ausführst:

@@ -180,10 +180,10 @@

Löschende Referenzen

-

Die Syntax der Refspezifikation lautet <src>:<dst>. Das Weglassen des <src> Teils bedeutet, im Grunde genommen, dass der topic Branch auf dem Remote leer bleibt, wodurch er gelöscht wird.

+

Die Syntax der Refspezifikation lautet <src>:<dst>. Das Weglassen des <src> Teils bedeutet im Grunde genommen, dass der topic Branch auf dem Remote leer bleibt, wodurch er gelöscht wird.

-

Oder Sie können die neuere Syntax verwenden (verfügbar seit Git v1.7.0):

+

Oder du kannst die neuere Syntax verwenden (verfügbar seit Git v1.7.0):

diff --git a/content/book/de/v2/Git-Interna-Git-Objekte.html b/content/book/de/v2/Git-Interna-Git-Objekte.html index b317b84844..9c60026d79 100644 --- a/content/book/de/v2/Git-Interna-Git-Objekte.html +++ b/content/book/de/v2/Git-Interna-Git-Objekte.html @@ -21,15 +21,15 @@

Git Objekte

Git ist ein inhalts-adressierbares Dateisystem. Toll. -Was bedeutet das? +Und was bedeutet das? Dies bedeutet, dass der Kern von Git ein einfacher Schlüssel-Wert-Datenspeicher ist. -Dies bedeutet, dass Sie jede Art von Inhalt in ein Git-Repository einfügen können. Git gibt Ihnen einen eindeutigen Schlüssel zurück, mit dem Sie den Inhalt später abrufen können.

+Dies bedeutet, dass du jede Art von Inhalt in ein Git-Repository einfügen kannst. Git gibt dir einen eindeutigen Schlüssel zurück, mit dem du den Inhalt später abrufen kannst.

-

Schauen wir uns als Beispiel den Installationsbefehl git hash-object an, der einige Daten aufnimmt, sie in Ihrem .git/objects Verzeichnis (der object database) speichert und Ihnen den eindeutigen Schlüssel zurückgibt, der nun auf dieses Datenobjekt verweist.

+

Schauen wir uns als Beispiel den Installationsbefehl git hash-object an, der einige Daten aufnimmt, sie in deinem .git/objects Verzeichnis (der object database) speichert und dir den eindeutigen Schlüssel zurückgibt, der nun auf dieses Datenobjekt verweist.

-

Zunächst initialisieren Sie ein neues Git-Repository und stellen sicher, dass sich (vorhersehbar) nichts im objects Verzeichnis befindet:

+

Zunächst initialisierst du ein neues Git-Repository und stellst sicher, dass sich (wie erwartet) nichts im objects Verzeichnis befindet:

@@ -45,7 +45,7 @@

Git Objekte

Git hat das Verzeichnis objects initialisiert und darin die Unterverzeichnisse pack und info erstellt, aber es gibt darin keine regulären Dateien. -Jetzt erstellen wir mit git hash-object ein neues Datenobjekt und speichern es manuell in Ihrer neuen Git-Datenbank:

+Jetzt erstellen wir mit git hash-object ein neues Datenobjekt und speichern es manuell in deiner neuen Git-Datenbank:

@@ -54,14 +54,14 @@

Git Objekte

-

In seiner einfachsten Form würde git hash-object den Inhalt, den Sie ihm übergeben haben, nehmen und würde lediglich den eindeutigen Schlüssel zurückgeben, der zum Speichern in Ihrer Git-Datenbank verwendet werden soll. +

In seiner einfachsten Form würde git hash-object den Inhalt, den du ihm übergeben hast, nehmen und würde lediglich den eindeutigen Schlüssel zurückgeben, der zum Speichern in deiner Git-Datenbank verwendet werden soll. Die Option -w weist dann den Befehl an, den Schlüssel nicht einfach zurückzugeben, sondern das Objekt in die Datenbank zu schreiben. Schließlich weist die Option --stdin git hash-object an, den zu verarbeitenden Inhalt von stdin abzurufen. Andernfalls würde der Befehl ein Dateinamenargument am Ende des Befehls erwarten, das den zu verwendenden Inhalt enthält.

Die Ausgabe des obigen Befehls ist ein Prüfsummen-Hash mit 40 Zeichen. -Dies ist der SHA-1-Hash – eine Prüfsumme des Inhalts, den Sie speichern, sowie eine Kopfzeile, über die Sie in Kürze mehr erfahren werden. -Jetzt können Sie sehen, wie Git Ihre Daten gespeichert hat:

+Dies ist der SHA-1-Hash – eine Prüfsumme des Inhalts, den du speicherst, sowie eine Kopfzeile, über die du in Kürze mehr erfahren wirst. +Jetzt kannst du sehen, wie Git deine Daten gespeichert hat:

@@ -70,14 +70,14 @@

Git Objekte

-

Wenn Sie Ihr Verzeichnis objects erneut untersuchen, können Sie feststellen, dass es jetzt eine Datei für diesen neuen Inhalt enthält. +

Wenn du dein Verzeichnis objects erneut untersuchst, kannst du feststellen, dass es jetzt eine Datei für diesen neuen Inhalt enthält. Auf diese Weise speichert Git den Inhalt initial — als einzelne Datei pro Inhaltselement, benannt mit der SHA-1-Prüfsumme des Inhalts und seiner Kopfzeile. Das Unterverzeichnis wird mit den ersten 2 Zeichen des SHA-1 benannt, und der Dateiname enthält die verbleibenden 38 Zeichen.

-

Sobald Sie Inhalt in Ihrer Objektdatenbank haben, können Sie diesen Inhalt mit dem Befehl git cat-file untersuchen. +

Sobald du Inhalt in deiner Objektdatenbank hast, kannst du diesen Inhalt mit dem Befehl git cat-file untersuchen. Dieser Befehl ist eine Art Schweizer Taschenmesser für die Inspektion von Git-Objekten. -Wenn Sie -p an cat-file übergeben, wird der Befehl angewiesen, zuerst den Inhaltstyp zu ermitteln und ihn dann entsprechend anzuzeigen:

+Wenn du -p an cat-file übergibst, wird der Befehl angewiesen, zuerst den Inhaltstyp zu ermitteln und ihn dann entsprechend anzuzeigen:

@@ -86,10 +86,10 @@

Git Objekte

-

Jetzt können Sie Inhalte zu Git hinzufügen und wieder herausziehen. -Sie können dies auch mit Inhalten in Dateien tun. -Sie können beispielsweise eine einfache Versionskontrolle für eine Datei durchführen. -Erstellen Sie zunächst eine neue Datei und speichern Sie deren Inhalt in Ihrer Datenbank:

+

Jetzt kannst du Inhalte zu Git hinzufügen und wieder herausziehen. +Du kannst dies auch mit Inhalten in Dateien tun. +Du kannst beispielsweise eine einfache Versionskontrolle für eine Datei durchführen. +Erstelle zunächst eine neue Datei und speichere deren Inhalt in deiner Datenbank:

@@ -99,7 +99,7 @@

Git Objekte

-

Schreiben Sie dann neuen Inhalt in die Datei und speichern Sie ihn erneut:

+

Schreibe dann neuen Inhalt in die Datei und speichere ihn erneut:

@@ -109,7 +109,7 @@

Git Objekte

-

Ihre Objektdatenbank enthält nun beide Versionen dieser neuen Datei (sowie den ersten Inhalt, den Sie dort gespeichert haben):

+

Deine Objektdatenbank enthält nun beide Versionen dieser neuen Datei (sowie den ersten Inhalt, den du dort gespeichert hast):

@@ -120,7 +120,7 @@

Git Objekte

-

Zu diesem Zeitpunkt können Sie Ihre lokale Kopie dieser test.txt Datei löschen und dann mit Git entweder die erste gespeicherte Version aus der Objektdatenbank abrufen:

+

Zu diesem Zeitpunkt kannst du deine lokale Kopie dieser test.txt Datei löschen und dann mit Git entweder die erste gespeicherte Version aus der Objektdatenbank abrufen:

@@ -140,9 +140,9 @@

Git Objekte

-

Es ist jedoch nicht sinnvoll, sich den SHA-1-Schlüssel für jede Version Ihrer Datei zu merken. Außerdem speichern Sie den Dateinamen nicht in Ihrem System, sondern nur den Inhalt. +

Es ist jedoch nicht sinnvoll, sich den SHA-1-Schlüssel für jede Version deiner Datei zu merken. Außerdem speicherst du den Dateinamen nicht in deinem System, sondern nur den Inhalt. Dieser Objekttyp wird als blob bezeichnet. -Git kann Ihnen den Objekttyp jedes Objekts in Git mitteilen, wenn sie den SHA-1-Schlüssel mit git cat-file -t angegeben:

+Git kann dir den Objekttyp jedes Objekts in Git mitteilen, wenn du den SHA-1-Schlüssel mit git cat-file -t angibst:

@@ -153,11 +153,11 @@

Git Objekte

Baum Objekte

-

Die nächste Art von Git-Objekte, die wir untersuchen, ist der baum, der das Problem des Speicherns des Dateinamens löst und es Ihnen auch ermöglicht, eine Gruppe von Dateien zusammen zu speichern. +

Die nächste Art von Git-Objekte, die wir untersuchen, ist der baum, der das Problem des Speicherns des Dateinamens löst und es dir auch ermöglicht, eine Gruppe von Dateien zusammen zu speichern. Git speichert Inhalte auf ähnliche Weise wie ein UNIX-Dateisystem, jedoch etwas vereinfacht. Der gesamte Inhalt wird als Baum- und Blob-Objekte gespeichert, wobei Bäume UNIX-Verzeichniseinträgen entsprechen und Blobs mehr oder weniger Inodes oder Dateiinhalten entsprechen. Ein einzelnes Baumobjekt enthält einen oder mehrere Einträge, von denen jeder der SHA-1-Hash eines Blobs oder Teilbaums mit dem zugehörigen Modus, Typ und Dateinamen ist. -Angenommen sie haben ein Projekt, in dem der aktuellste Baum folgendermaßen aussieht:

+Angenommen du hast ein Projekt, in dem der aktuellste Baum folgendermaßen aussieht:

@@ -168,8 +168,8 @@

Baum Objekte

-

Die master^{tree} Syntax gibt das Baumobjekt an, auf das durch das letzte Commit in Ihrem master Branch verwiesen wird. -Beachten Sie, dass das Unterverzeichnis lib kein Blob ist, sondern ein Zeiger auf einen anderen Baum:

+

Die master^{tree} Syntax gibt das Baumobjekt an, auf das durch das letzte Commit in deinem master Branch verwiesen wird. +Beachte, dass das Unterverzeichnis lib kein Blob ist, sondern ein Zeiger auf einen anderen Baum:

@@ -185,14 +185,14 @@

Baum Objekte

-

Je nachdem, welche Shell Sie verwenden, können bei der Verwendung der master^{tree} Syntax Fehler auftreten.

+

Je nachdem, welche Shell du verwendest, können bei der Verwendung der master^{tree} Syntax Fehler auftreten.

-

In CMD unter Windows wird das Zeichen ^ für das Escapezeichen verwendet, daher müssen Sie es verdoppeln, um dies zu vermeiden: git cat-file -p master^^{tree}. +

In CMD unter Windows wird das Zeichen ^ für das Escapezeichen verwendet, daher musst du es verdoppeln, um dies zu vermeiden: git cat-file -p master^^{tree}. Bei Verwendung von PowerShell müssen Parameter mit {} Zeichen in Anführungszeichen gesetzt werden, um eine fehlerhafte Syntaxanalyse des Parameters zu vermeiden: git cat-file -p 'master^{tree}'.

-

Wenn Sie ZSH verwenden, wird das Zeichen ^ zum Verschieben verwendet, daher müssen Sie den gesamten Ausdruck in Anführungszeichen setzen: git cat-file -p "master^{tree}".

+

Wenn du ZSH verwendest, wird das Zeichen ^ zum Verschieben verwendet, daher musst du den gesamten Ausdruck in Anführungszeichen setzen: git cat-file -p "master^{tree}".

@@ -208,13 +208,13 @@

Baum Objekte

Abbildung 173. Einfache Version des Git-Datenmodells
-

Sie können ziemlich einfach Ihren eigenen Baum erstellen. -Git erstellt normalerweise einen Baum, indem es den Status Ihres Staging-Bereichs oder Index übernimmt und eine Reihe von Baumobjekten daraus schreibt. -Um ein Baumobjekt zu erstellen, müssen Sie zunächst einen Index einrichten, indem Sie einige Dateien bereitstellen. -Um einen Index mit einem einzigen Eintrag zu erstellen — der ersten Version Ihrer test.txt Datei — können Sie den Basisbefehl git update-index verwenden. -Mit diesem Befehl fügen Sie die frühere Version der Datei test.txt künstlich einem neuen Staging-Bereich hinzu. -Sie müssen die Option --add übergeben, da die Datei in Ihrem Staging-Bereich noch nicht vorhanden ist (Sie haben noch nicht einmal einen Staging-Bereich eingerichtet). --cacheinfo müssen sie angeben, weil die hinzugefügte Datei sich nicht in Ihrem Verzeichnis, sondern in Ihrer Datenbank befindet. -Dann geben Sie den Modus, SHA-1 und Dateinamen an:

+

Du kannst ziemlich einfach deinen eigenen Baum erstellen. +Git erstellt normalerweise einen Baum, indem es den Status deines Staging-Bereichs oder Index übernimmt und eine Reihe von Baumobjekten daraus schreibt. +Um ein Baumobjekt zu erstellen, musst du zunächst einen Index einrichten, indem du einige Dateien bereitstellst. +Um einen Index mit einem einzigen Eintrag zu erstellen — der ersten Version Deiner test.txt Datei — kannst du den Basisbefehl git update-index verwenden. +Mit diesem Befehl fügst du die frühere Version der Datei test.txt künstlich einem neuen Staging-Bereich hinzu. +Du musst die Option --add übergeben, da die Datei in deinem Staging-Bereich noch nicht vorhanden ist (Du hast noch nicht einmal einen Staging-Bereich eingerichtet). --cacheinfo musst du angeben, weil die hinzugefügte Datei sich nicht in deinem Verzeichnis, sondern in deiner Datenbank befindet. +Dann gibst du den Modus, SHA-1 und Dateinamen an:

@@ -223,12 +223,12 @@

Baum Objekte

-

In diesem Fall geben Sie den Modus 100644 an, was bedeutet, dass es sich um eine normale Datei handelt. +

In diesem Fall gibst du den Modus 100644 an, was bedeutet, dass es sich um eine normale Datei handelt. Andere Optionen sind 100755, was bedeutet, dass es sich um eine ausführbare Datei handelt und 120000, was einen symbolischen Link angibt. Der Modus stammt aus normalen UNIX-Modi, ist jedoch viel weniger flexibel — diese drei Modi sind die einzigen, die für Dateien (Blobs) in Git gültig sind (obwohl andere Modi für Verzeichnisse und Submodule verwendet werden).

-

Jetzt können Sie git write-tree verwenden, um den Staging-Bereich in ein Baumobjekt zu schreiben. +

Jetzt kannst du git write-tree verwenden, um den Staging-Bereich in ein Baumobjekt zu schreiben. Es ist keine Option -w erforderlich. Durch Aufrufen dieses Befehls wird automatisch ein Baumobjekt aus dem Status des Index erstellt, wenn dieser Baum noch nicht vorhanden ist:

@@ -240,7 +240,7 @@

Baum Objekte

-

Sie können auch überprüfen, ob es sich um ein Baumobjekt handelt, indem Sie denselben Befehl git cat-file verwenden, den Sie zuvor gesehen haben:

+

Du kannst auch überprüfen, ob es sich um ein Baumobjekt handelt, indem du denselben Befehl git cat-file verwendest, den du zuvor gesehen hast:

@@ -249,7 +249,7 @@

Baum Objekte

-

Sie erstellen jetzt einen neuen Baum mit der zweiten Version von test.txt und einer neuen Datei:

+

Du erstellst jetzt einen neuen Baum mit der zweiten Version von test.txt und einer neuen Datei:

@@ -260,8 +260,8 @@

Baum Objekte

-

Ihr Staging-Bereich enthält jetzt die neue Version von test.txt sowie die neue Datei new.txt. -Schreiben Sie diesen Baum aus (zeichnen Sie den Status des Staging-Bereichs oder des Index für ein Baumobjekt auf) und sehen Sie, wie er aussieht:

+

Dein Staging-Bereich enthält jetzt die neue Version von test.txt sowie die neue Datei new.txt. +Schreibe diesen Baum aus (zeichne den Status des Staging-Bereichs oder des Index für ein Baumobjekt auf) und schau dir an, wie er aussieht:

@@ -273,10 +273,10 @@

Baum Objekte

-

Beachten Sie, dass dieser Baum beide Dateieinträge enthält und dass der SHA-1 von test.txt der SHA-1 „Version 2“ von früher (1f7a7a) entspricht. -Aus Spaß fügen Sie diesem den ersten Baum als Unterverzeichnis hinzu. -Sie können Bäume in Ihren Staging-Bereich einlesen, indem Sie git read-tree aufrufen. -In diesem Fall können Sie einen vorhandenen Baum als Teilbaum in Ihren Staging-Bereich einlesen, indem Sie die Option --prefix mit diesem Befehl verwenden:

+

Beachte, dass dieser Baum beide Dateieinträge enthält und dass der SHA-1 von test.txt der SHA-1 „Version 2“ von früher (1f7a7a) entspricht. +Zum rumprobieren füge diesem den ersten Baum als Unterverzeichnis hinzu. +Du kannst Bäume in deinem Staging-Bereich einlesen, indem du git read-tree aufrufst. +In diesem Fall kannst du einen vorhandenen Baum als Teilbaum in deinem Staging-Bereich einlesen, indem du die Option --prefix mit diesem Befehl verwendest:

@@ -290,26 +290,26 @@

Baum Objekte

-

Wenn Sie aus dem soeben erstellten Baum ein Arbeitsverzeichnis erstellen, erhalten Sie die beiden Dateien in der obersten Ebene des Arbeitsverzeichnisses und ein Unterverzeichnis mit dem Namen bak, das die erste Version der Datei test.txt enthält. -Sie können sich die Daten, die Git für diese Strukturen enthält, so vorstellen:

+

Wenn du aus dem soeben erstellten Baum ein Arbeitsverzeichnis erstellst, erhältst du die beiden Dateien in der obersten Ebene des Arbeitsverzeichnisses und ein Unterverzeichnis mit dem Namen bak, das die erste Version der Datei test.txt enthält. +Du kannst dir die Daten, die Git für diese Strukturen enthält, so vorstellen:

-}}" alt="Die Inhaltsstruktur Ihrer aktuellen Git-Daten"> +}}" alt="Die Inhaltsstruktur deiner aktuellen Git-Daten">
-
Abbildung 174. Die Inhaltsstruktur Ihrer aktuellen Git-Daten
+
Abbildung 174. Die Inhaltsstruktur deiner aktuellen Git-Daten

Commit Objekte

-

Wenn Sie alle oben genannten Schritte ausgeführt haben, verfügen Sie nun über drei Bäume, die die verschiedenen Schnappschüsse Ihres Projekts darstellen, die Sie verfolgen möchten. Das bisherige Problem bleibt jedoch bestehen: Sie müssen sich alle drei SHA-1-Werte merken, um die Schnappschüsse abzurufen. -Sie haben auch keine Informationen darüber, wer die Schnappschüsse gespeichert hat, wann sie gespeichert wurden oder warum sie gespeichert wurden. -Dies sind die grundlegenden Informationen, die das Commit Objekt für Sie speichert.

+

Wenn du alle oben genannten Schritte ausgeführt hast, verfügst du nun über drei Bäume, die die verschiedenen Schnappschüsse deines Projekts darstellen, die du verfolgen möchtest. Das bisherige Problem bleibt jedoch bestehen: Du müsst dir alle drei SHA-1-Werte merken, um die Schnappschüsse abzurufen. +Du hast auch keine Informationen darüber, wer die Schnappschüsse gespeichert hat, wann sie gespeichert wurden oder warum sie gespeichert wurden. +Dies sind die grundlegenden Informationen, die das Commit Objekt für dich speichert.

-

Um ein Commit Objekt zu erstellen, rufen Sie commit-tree auf und geben einen einzelnen Baum SHA-1 an. Außerdem geben sie an welche Commit Objekte die direkten Vorgänger sind (falls überhaupt welche vorhanden sind). -Beginnen Sie mit dem ersten Baum, den Sie geschrieben haben:

+

Um ein Commit Objekt zu erstellen, rufe commit-tree auf und gib einen einzelnen Baum SHA-1 an. Gib außerdem an welche Commit Objekte die direkten Vorgänger sind (falls überhaupt welche vorhanden sind). +Beginne mit dem ersten Baum, den du geschrieben hast:

@@ -325,16 +325,16 @@

Commit Objekte

-

Sie werden vermutlich einen anderen Hash-Wert erhalten, da die Erstellungszeit und die Autorendaten unterschiedlich sind. +

Du wirst vermutlich einen anderen Hash-Wert erhalten, da die Erstellungszeit und die Autorendaten unterschiedlich sind. Darüber hinaus kann zwar prinzipiell jedes Commit-Objekt genau reproduziert werden. Allerdings könnten aufgrund der technischen Details beim Erstellen dieses Buches die abgedruckten Commit-Hashes im Vergleich zu den entsprechenden Commits abweichen. -Ersetzen Sie die Commit- und Tag-Hashes durch Ihre eigenen Prüfsummen in diesem Kapitel.

+Ersetze die Commit- und Tag-Hashes durch deine eigenen Prüfsummen in diesem Kapitel.

-

Nun können Sie sich Ihr neues Commit-Objekt mit git cat-file ansehen:

+

Nun können du dir deine neues Commit-Objekt mit git cat-file ansehen:

@@ -347,10 +347,10 @@

Commit Objekte

-

Das Format für ein Commit Objekt ist einfach: Es gibt den Baum der obersten Ebene für den Snapshot des Projekts zu diesem Zeitpunkt an; Das übergeordnete Objekt, falls vorhanden, (das oben beschriebene Commit Objekt hat keine übergeordneten Objekte); die Autoren-/Committer-Informationen (genutzt werden Ihre Konfigurationseinstellungen user.name und user.email sowie einen Zeitstempel); eine leere Zeile und dann die Commit-Nachricht.

+

Das Format für ein Commit Objekt ist einfach: Es gibt den Baum der obersten Ebene für den Snapshot des Projekts zu diesem Zeitpunkt an; Das übergeordnete Objekt, falls vorhanden, (das oben beschriebene Commit Objekt hat keine übergeordneten Objekte); die Autoren-/Committer-Informationen (genutzt werden deine Konfigurationseinstellungen user.name und user.email sowie einen Zeitstempel); eine leere Zeile und dann die Commit-Nachricht.

-

Als Nächstes schreiben Sie die beiden anderen Commit Objekte, die jeweils auf das Commit verweisen, welches direkt davor erfolgte:

+

Als Nächstes schreibe die beiden anderen Commit Objekte, die jeweils auf das Commit verweisen, welches direkt davor erfolgte:

@@ -361,8 +361,8 @@

Commit Objekte

-

Jedes der drei Commit-Objekte verweist auf einen der drei von Ihnen erstellten Snapshot-Bäume. -Seltsamerweise haben Sie jetzt einen echten Git-Verlauf, den Sie mit dem Befehl git log anzeigen können, wenn Sie ihn beim letzten Commit SHA-1 ausführen:

+

Jedes der drei Commit-Objekte verweist auf einen der drei von dir erstellten Snapshot-Bäume. +Seltsamerweise hast du jetzt einen echten Git-Verlauf, den du mit dem Befehl git log anzeigen kannst, wenn du ihn beim letzten Commit SHA-1 ausführst:

@@ -398,9 +398,9 @@

Commit Objekte

Wundervoll. -Sie haben gerade Basisbefehle der niedrigen Ebene ausgeführt, um einen Git-Verlauf zu erstellen, ohne einen der Standardbefehle zu verwenden. -Dies ist im Wesentlichen das, was Git tut, wenn Sie die Befehle git add und git commit ausführen — es speichert Blobs für die geänderten Dateien, aktualisiert den Index, schreibt Bäume und schreibt Commit-Objekte, die auf Bäume der oberste Ebene verweisen und die Commits, die unmittelbar vor ihnen aufgetreten sind. -Diese drei Haupt-Git-Objekte — der Blob, der Baum und das Commit – werden anfänglich als separate Dateien in Ihrem .git/objects Verzeichnis gespeichert. +Du hast gerade Basisbefehle der niedrigen Ebene ausgeführt, um einen Git-Verlauf zu erstellen, ohne einen der Standardbefehle zu verwenden. +Dies ist im Wesentlichen das, was Git tut, wenn du die Befehle git add und git commit ausführst — es speichert Blobs für die geänderten Dateien, aktualisiert den Index, schreibt Bäume und schreibt Commit-Objekte, die auf Bäume der oberste Ebene verweisen und die Commits, die unmittelbar vor ihnen aufgetreten sind. +Diese drei Haupt-Git-Objekte — der Blob, der Baum und das Commit – werden anfänglich als separate Dateien in deinem .git/objects Verzeichnis gespeichert. Hier sind jetzt alle Objekte im Beispielverzeichnis, kommentiert mit dem, was sie speichern:

@@ -419,24 +419,24 @@

Commit Objekte

-

Wenn Sie allen internen Zeigern folgen, erhalten Sie eine Objektgrafik in etwa wie folgt:

+

Wenn du allen internen Zeigern folgst, erhältst du eine Objektgrafik in etwa wie folgt:

-}}" alt="Alle erreichbaren Objekte in Ihrem Git-Verzeichnis"> +}}" alt="Alle erreichbaren Objekte in deinem Git-Verzeichnis">
-
Abbildung 175. Alle erreichbaren Objekte in Ihrem Git-Verzeichnis
+
Abbildung 175. Alle erreichbaren Objekte in deinem Git-Verzeichnis

Objektspeicher

-

Wir haben bereits erwähnt, dass für jedes Objekt, das Sie in Ihre Git-Objektdatenbank übernehmen, ein Header gespeichert ist. +

Wir haben bereits erwähnt, dass für jedes Objekt, das du in deine Git-Objektdatenbank übernimmst, ein Header gespeichert ist. Nehmen wir uns eine Minute Zeit, um zu sehen, wie Git seine Objekte speichert. -Sie werden sehen, wie Sie ein Blob-Objekt — in diesem Fall die Zeichenfolge „what is up, doc?“ – interaktiv in der Ruby-Skriptsprache speichern.

+Du wirst sehen, wie du ein Blob-Objekt — in diesem Fall die Zeichenfolge „what is up, doc?“ – interaktiv in der Ruby-Skriptsprache speicherst.

-

Sie können den interaktiven Ruby-Modus mit dem Befehl irb starten:

+

Du kannst den interaktiven Ruby-Modus mit dem Befehl irb starten:

@@ -457,7 +457,7 @@

Objektspeicher

Git verkettet den Header und den ursprünglichen Inhalt und berechnet dann die SHA-1-Prüfsumme dieses neuen Inhalts. -Sie können den SHA-1-Wert einer Zeichenfolge in Ruby berechnen, indem Sie die SHA1-Digest-Bibliothek mit dem Befehl require hinzufügen und dann Digest::SHA1.hexdigest() mit der Zeichenfolge aufrufen:

+Du kannst den SHA-1-Wert einer Zeichenfolge in Ruby berechnen, indem du die SHA1-Digest-Bibliothek mit dem Befehl require hinzufügst und dann Digest::SHA1.hexdigest() mit der Zeichenfolge aufrufst:

@@ -480,8 +480,8 @@

Objektspeicher

-

Git komprimiert den neuen Inhalt mit zlib, was Sie in Ruby mit der zlib-Bibliothek tun können. -Zuerst müssen Sie die Bibliothek hinzufügen und dann Zlib::Deflate.deflate() auf den Inhalt ausführen:

+

Git komprimiert den neuen Inhalt mit zlib, was du in Ruby mit der zlib-Bibliothek tun kannst. +Zuerst musst du die Bibliothek hinzufügen und dann Zlib::Deflate.deflate() auf den Inhalt ausführen:

@@ -492,10 +492,10 @@

Objektspeicher

-

Schließlich schreiben Sie Ihren zlib-entpackten Inhalt auf ein Objekt auf der Festplatte. -Sie bestimmen den Pfad des Objekts, das Sie ausschreiben möchten (die ersten beiden Zeichen des SHA-1-Werts sind der Name des Unterverzeichnisses und die letzten 38 Zeichen der Dateiname in diesem Verzeichnis). -In Ruby können Sie die Funktion FileUtils.mkdir_p() verwenden, um das Unterverzeichnis zu erstellen, falls es nicht vorhanden ist. -Öffnen Sie dann die Datei mit File.open() und schreiben Sie den zuvor mit zlib komprimierten Inhalt mit einem write() -Aufruf auf das resultierende Dateihandle in die Datei:

+

Schließlich schreibst du deinen zlib-entpackten Inhalt auf ein Objekt auf der Festplatte. +Du bestimmst den Pfad des Objekts, das du ausschreiben möchtest (die ersten beiden Zeichen des SHA-1-Werts sind der Name des Unterverzeichnisses und die letzten 38 Zeichen der Dateiname in diesem Verzeichnis). +In Ruby kannst du die Funktion FileUtils.mkdir_p() verwenden, um das Unterverzeichnis zu erstellen, falls es nicht vorhanden ist. +Öffne dann die Datei mit File.open() und schreibe den zuvor mit zlib komprimierten Inhalt mit einem write() -Aufruf auf das resultierende Dateihandle in die Datei:

@@ -510,7 +510,7 @@

Objektspeicher

-

Lassen Sie uns den Inhalt des Objekts mit git cat-file überprüfen:

+

Lass uns den Inhalt des Objekts mit git cat-file überprüfen:

@@ -521,7 +521,7 @@

Objektspeicher

-

Das war’s – Sie haben ein gültiges Git-Blob-Objekt erstellt.

+

Das war’s – Du hast ein gültiges Git-Blob-Objekt erstellt.

Alle Git-Objekte werden auf dieselbe Weise gespeichert, nur mit unterschiedlichen Typen. Anstelle des String-Blobs beginnt der Header mit commit oder tree. diff --git a/content/book/de/v2/Git-Interna-Git-Referenzen.html b/content/book/de/v2/Git-Interna-Git-Referenzen.html index dff6c450d7..a0c9b26827 100644 --- a/content/book/de/v2/Git-Interna-Git-Referenzen.html +++ b/content/book/de/v2/Git-Interna-Git-Referenzen.html @@ -19,11 +19,11 @@ ---

Git Referenzen

-

Wenn Sie den Verlauf Ihres Repositorys sehen möchten, der über Commit erreichbar ist, z. B. 1a410e, können Sie so etwas wie git log 1a410e ausführen, um diesen Verlauf anzuzeigen. Dennoch müssen Sie sich weiterhin daran erinnern, dass 1a410e der Commit ist den Sie als Ausgangspunkt für diese Historie verwenden möchten. -Es wäre aber einfacher, wenn Sie eine Datei hätten, in der Sie diesen SHA-1-Wert unter einem einfachen Namen speichern könnten, sodass Sie diesen einfachen Namen anstelle des unformatierten SHA-1-Werts verwenden könnten.

+

Wenn du den Verlauf deines Repositorys sehen möchtest, der über Commit erreichbar ist, z. B. 1a410e, kannst du so etwas wie git log 1a410e ausführen, um diesen Verlauf anzuzeigen. Dennoch musst du sich weiterhin daran erinnern, dass 1a410e der Commit ist den du als Ausgangspunkt für diese Historie verwenden möchtest. +Es wäre aber einfacher, wenn du eine Datei hättest, in der du diesen SHA-1-Wert unter einem einfachen Namen speichern kannst, sodass du diesen einfachen Namen anstelle des unformatierten SHA-1-Werts verwenden könntest.

-

In Git werden diese einfachen Namen „Referenzen“ oder „Refs“ genannt. Sie finden die Dateien, die diese SHA-1-Werte enthalten, im Verzeichnis .git/refs. +

In Git werden diese einfachen Namen „Referenzen“ oder „Refs“ genannt. Du findest die Dateien, die diese SHA-1-Werte enthalten, im Verzeichnis .git/refs. Im aktuellen Projekt enthält dieses Verzeichnis keine Dateien, es enthält eine einfache Struktur:

@@ -36,7 +36,7 @@

Git Referenzen

-

Um eine neue Referenz zu erstellen, die Ihnen hilft, sich zu erinnern, wo sich Ihr letztes Commit befindet, können Sie einfach folgende machen:

+

Um eine neue Referenz zu erstellen, die dir hilft, dich zu erinnern, wo sich dein letzter Commit befindet, kannst du einfach folgendes machen:

@@ -44,7 +44,7 @@

Git Referenzen

-

Jetzt können Sie die soeben erstellte Kopfreferenz anstelle des SHA-1-Werts in Ihren Git-Befehlen verwenden:

+

Jetzt kannst du die soeben erstellte Kopfreferenz anstelle des SHA-1-Werts in deinem Git-Befehlen verwenden:

@@ -55,7 +55,7 @@

Git Referenzen

-

Es wird nicht empfohlen, die Referenzdateien direkt zu bearbeiten. Stattdessen bietet Git den sichereren Befehl git update-ref, um dies zu tun, wenn Sie eine Referenz aktualisieren möchten:

+

Es wird nicht empfohlen, die Referenzdateien direkt zu bearbeiten. Stattdessen bietet Git den sichereren Befehl git update-ref, um dies zu tun, wenn du eine Referenz aktualisieren möchtest:

@@ -64,7 +64,7 @@

Git Referenzen

Das ist im Grunde genommen ein Branch in Git: ein einfacher Zeiger oder ein Verweis auf den Kopf einer Arbeitslinie. -So erstellen Sie eine Verzweigung beim zweiten Commit:

+So erstellst du eine Verzweigung beim zweiten Commit:

@@ -72,7 +72,7 @@

Git Referenzen

-

Ihr Branch enthält nur Arbeiten von diesem Commit an abwärts:

+

Dein Branch enthält nur Arbeiten von diesem Commit an abwärts:

@@ -82,7 +82,7 @@

Git Referenzen

-

Nun sieht Ihre Git-Datenbank konzeptionell ungefähr so aus:

+

Nun sieht deine Git-Datenbank konzeptionell ungefähr so aus:

@@ -91,24 +91,24 @@

Git Referenzen

Abbildung 176. Git-Verzeichnisobjekte mit Branch Head Referenzen
-

Wenn Sie Befehle wie git branch <branch> ausführen, führt Git grundsätzlich den Befehl update-ref aus, um den SHA-1 des letzten Commits des Branches, in dem Sie sich befinden, in die neue Referenz einzufügen, die Sie erstellen möchten.

+

Wenn du Befehle wie git branch <branch> ausführst, führt Git grundsätzlich den Befehl update-ref aus, um den SHA-1 des letzten Commits des Branches, in dem du sich befindest, in die neue Referenz einzufügen, die du erstellen möchtest.

HEAD

-

Die Frage ist nun, wenn Sie git branch <branch> ausführen, woher kennt Git den SHA-1 des letzten Commits? +

Die Frage ist nun, wenn du git branch <branch> ausführst, woher kennt Git den SHA-1 des letzten Commits? Die Antwort ist die HEAD-Datei.

-

Normalerweise ist die HEAD-Datei ein symbolischer Verweis auf den Branch, in dem Sie sich gerade befinden. +

Normalerweise ist die HEAD-Datei ein symbolischer Verweis auf den Branch, in dem du dich gerade befindest. Mit symbolischer Referenz meinen wir, dass sie im Gegensatz zu einer normalen Referenz einen Zeiger auf eine andere Referenz enthält.

In einigen seltenen Fällen kann die HEAD-Datei jedoch den SHA-1-Wert eines Git-Objekts enthalten. -Dies geschieht beim Auschecken eines Tags, Commits oder eines Remote-Branches, wodurch Ihr Repository in den Status "detached HEAD" versetzt wird.

+Dies geschieht beim Auschecken eines Tags, Commits oder eines Remote-Branches, wodurch dein Repository in den Status "detached HEAD" versetzt wird.

-

Wenn Sie sich die Datei ansehen, sehen Sie normalerweise Folgendes:

+

Wenn du dir die Datei ansiehst, siehst du normalerweise Folgendes:

@@ -117,7 +117,7 @@

HEAD

-

Wenn Sie git checkout test ausführen, aktualisiert Git die Datei folgendermaßen:

+

Wenn du git checkout test ausführst, aktualisiert Git die Datei folgendermaßen:

@@ -126,11 +126,11 @@

HEAD

-

Wenn Sie git commit ausführen, wird das Commitobjekt erstellt, wobei das übergeordnete Objekt dieses Commitobjekts als der SHA-1-Wert angegeben wird, auf den die Referenz in HEAD verweist.

+

Wenn du git commit ausführst, wird das Commitobjekt erstellt, wobei das übergeordnete Objekt dieses Commitobjekts als der SHA-1-Wert angegeben wird, auf den die Referenz in HEAD verweist.

-

Sie können diese Datei auch manuell bearbeiten, es gibt jedoch wieder einen sichereren Befehl: git symbolic-ref. -Sie können den Wert Ihres HEAD über diesen Befehl lesen:

+

Du kannst diese Datei auch manuell bearbeiten, es gibt jedoch wieder einen sichereren Befehl: git symbolic-ref. +Du kannst den Wert deines HEAD über diesen Befehl lesen:

@@ -139,7 +139,7 @@

HEAD

-

Sie können den Wert von HEAD auch mit demselben Befehl festlegen:

+

Du kannst den Wert von HEAD auch mit demselben Befehl festlegen:

@@ -149,7 +149,7 @@

HEAD

-

Sie können keine symbolische Referenz außerhalb des Refs-Stils festlegen:

+

Du kannst keine symbolische Referenz außerhalb des Refs-Stils festlegen:

@@ -164,11 +164,11 @@

Tags

Wir haben gerade die drei Hauptobjekttypen von Git (blobs, trees und commits) besprochen, aber es gibt einen vierten. Das tag-Objekt ähnelt stark einem Commitobjekt — es enthält einen Tagger, ein Datum, eine Nachricht und einen Zeiger. Der Hauptunterschied besteht darin, dass ein Tag-Objekt im Allgemeinen eher auf ein Commit als auf einen Baum verweist. -Es ist wie eine Branchreferenz, aber es bewegt sich nie — es zeigt immer auf das gleiche Commit, gibt ihm aber einen lesbareren Namen.

+Es ist wie eine Branchreferenz, aber es bewegt sich nie — es zeigt immer auf den gleichen Commit, gibt ihm aber einen lesbareren Namen.

Wie in }}">Git Grundlagen beschrieben, gibt es zwei Arten von Tags: Annotierte- und Leichtgewichtige-Tags. -Sie können einen leichtgewichtigen Tag erstellen, indem Sie Folgendes ausführen:

+Du kannst einen leichtgewichtigen Tag erstellen, indem du Folgendes ausführst:

@@ -178,8 +178,8 @@

Tags

Das ist alles, was ein leichtgewichtiges Tag ist — eine Referenz, die sich nie bewegt. Ein annotiertes Tag ist jedoch komplexer. -Wenn Sie ein annotiertes Tag erstellen, erstellt Git ein Tag-Objekt und schreibt dann einen Verweis, um darauf zu zeigen, anstatt direkt auf das Commit. -Sie können dies sehen, indem Sie ein annotiertes Tag (mit der Option -a) erstellen:

+Wenn du ein annotiertes Tag erstellst, erstellt Git ein Tag-Objekt und schreibt dann einen Verweis, um darauf zu zeigen, anstatt direkt auf den Commit. +Du kannst dies sehen, indem du ein annotiertes Tag (mit der Option -a) erstellst:

@@ -196,7 +196,7 @@

Tags

-

Führen Sie nun git cat-file -p für diesen SHA-1-Wert aus:

+

Führe nun git cat-file -p für diesen SHA-1-Wert aus:

@@ -210,10 +210,10 @@

Tags

-

Beachten Sie, dass der Objekteintrag auf den Commit SHA-1-Wert verweist, den Sie getagged haben. -Beachten Sie auch, dass es nicht auf ein Commit verweisen muss. Sie können jedes Git-Objekt taggen. +

Du kannst sehen, dass der Objekteintrag auf den Commit SHA-1-Wert verweist, den du getagged hast. +Beachte auch, dass es nicht auf ein Commit verweisen muss. Du kannst jedes Git-Objekt taggen. Beispielsweise hat der Betreuer im Git-Quellcode seinen öffentlichen GPG-Schlüssel als Blob-Objekt hinzugefügt und dann mit Tags versehen. -Sie können den öffentlichen Schlüssel anzeigen, indem Sie diesen in einem Klon des Git-Repositorys ausführen:

+Du kannst den öffentlichen Schlüssel anzeigen, indem du diesen in einem Klon des Git-Repositorys ausführst:

@@ -227,9 +227,9 @@

Tags

Remotes

-

Der dritte Referenztyp, den Sie sehen, ist eine Remotereferenz. -Wenn Sie ein Remote hinzufügen und darauf pushen, speichert Git den Wert, den Sie zuletzt an diesen Remote gesendet haben, für jeden Branch im Verzeichnis refs/remotes. -Zum Beispiel können Sie eine Remote mit dem Namen origin hinzufügen und Ihren master -Branch darauf pushen:

+

Der dritte Referenztyp, den du siehst, ist eine Remotereferenz. +Wenn du ein Remote hinzufügst und darauf pushst, speichert Git den Wert, den du zuletzt an diesen Remote gesendet hast, für jeden Branch im Verzeichnis refs/remotes. +Zum Beispiel kannst du eine Remote mit dem Namen origin hinzufügen und deinen master -Branch darauf pushen:

@@ -244,7 +244,7 @@

Remotes

-

Anschließend können Sie in der Datei refs/remotes/origin/master sehen, in welcher master Branch auf dem origin Remote Sie das letzte Mal mit dem Server kommuniziert haben:

+

Anschließend kannst du in der Datei refs/remotes/origin/master sehen, in welchen master Branch auf dem origin Remote du das letzte Mal mit dem Server kommuniziert hast:

@@ -254,7 +254,7 @@

Remotes

Remote Referenzen unterscheiden sich von Branches (refs/heads Referenzen) hauptsächlich darin, dass sie als schreibgeschützt gelten. -Sie können git checkout darauf ausführen, aber HEAD wird nicht symbolisch darauf referenzieren, so dass Sie es niemals mit einem commit Befehl aktualisieren können. +Du kannst git checkout darauf ausführen, aber HEAD wird nicht symbolisch darauf referenzieren, so dass du es niemals mit einem commit Befehl aktualisieren kannst. Git verwaltet sie als Lesezeichen für den letzten bekannten Status, in dem sich diese Branches auf diesen Servern befinden.

diff --git a/content/book/de/v2/Git-Interna-Packdateien-engl-Packfiles.html b/content/book/de/v2/Git-Interna-Packdateien-engl-Packfiles.html index c06f0b3bd5..a2401ee2d3 100644 --- a/content/book/de/v2/Git-Interna-Packdateien-engl-Packfiles.html +++ b/content/book/de/v2/Git-Interna-Packdateien-engl-Packfiles.html @@ -19,7 +19,7 @@ ---

Packdateien (engl. Packfiles)

-

Wenn Sie alle Anweisungen im Beispiel aus dem vorherigen Abschnitt befolgt haben, sollten Sie jetzt ein Test-Git-Repository mit 11 Objekten haben – vier Blobs, drei Bäumen, drei Commits und einem Tag:

+

Wenn du alle Anweisungen im Beispiel aus dem vorherigen Abschnitt befolgt hast, solltest du jetzt ein Test-Git-Repository mit 11 Objekten haben – vier Blobs, drei Bäumen, drei Commits und einem Tag:

@@ -39,7 +39,7 @@

Packdateien (engl. Packfiles)

Git komprimiert den Inhalt dieser Dateien mit zlib. Alle diese Dateien zusammen belegen nur 925 Byte. -Jetzt fügen Sie dem Repository einige größere Inhalte hinzu, um eine interessante Funktion von Git zu demonstrieren. +Füge jetzt dem Repository einige größere Inhalte hinzu, um eine interessante Funktion von Git zu demonstrieren. Zur Veranschaulichung fügen wir die Datei repo.rb aus der Grit-Bibliothek hinzu. Hierbei handelt es sich um eine 22-KB-Quellcodedatei:

@@ -56,7 +56,7 @@

Packdateien (engl. Packfiles)

-

Wenn Sie sich den resultierenden Baum ansehen, sehen Sie den SHA-1-Wert, der für Ihr neues repo.rb-Blob-Objekt berechnet wurde:

+

Wenn du dir den resultierenden Baum ansiehst, siehst du den SHA-1-Wert, der für dein neues repo.rb-Blob-Objekt berechnet wurde:

@@ -67,7 +67,7 @@

Packdateien (engl. Packfiles)

-

Sie können dann git cat-file verwenden, um zu sehen, wie groß das Objekt ist:

+

Du kannst dann git cat-file verwenden, um zu sehen, wie groß das Objekt ist:

@@ -76,7 +76,7 @@

Packdateien (engl. Packfiles)

-

Ändern Sie nun diese Datei ein wenig und sehen Sie, was passiert:

+

Ändere nun diese Datei ein wenig und schauen wir, was passiert:

@@ -87,7 +87,7 @@

Packdateien (engl. Packfiles)

-

Überprüfen Sie den von diesem letzten Commit erstellten Baum. Dabei werden Sie etwas Interessantes sehen:

+

Überprüfe den von diesem letzten Commit erstellten Baum. Dabei wirst du etwas Interessantes sehen:

@@ -98,7 +98,7 @@

Packdateien (engl. Packfiles)

-

Der Blob ist jetzt ein anderer Blob. Das bedeutet, dass Git, obwohl Sie nur eine einzelne Zeile am Ende einer Datei mit 400 Zeilen hinzugefügt haben, diesen neuen Inhalt als ein komplett neues Objekt gespeichert hat:

+

Der Blob ist jetzt ein anderer Blob. Das bedeutet, dass Git, obwohl du nur eine einzelne Zeile am Ende einer Datei mit 400 Zeilen hinzugefügt hast, diesen neuen Inhalt als ein komplett neues Objekt gespeichert hat:

@@ -107,15 +107,15 @@

Packdateien (engl. Packfiles)

-

Sie haben jetzt zwei nahezu identische 22-KB-Objekte auf Ihrer Festplatte (jedes auf ca. 7 KB komprimiert). +

Du hast jetzt zwei nahezu identische 22-KB-Objekte auf deiner Festplatte (jedes auf ca. 7 KB komprimiert). Wäre es nicht schön, wenn Git eines davon vollständig speichern könnte, aber dann das zweite Objekt nur als Delta zwischen dem ersten und dem anderen?

Wie sich herausstellen wird, geht das. Das ursprüngliche Format, in dem Git Objekte auf der Festplatte speichert, wird als „loses“ Objektformat bezeichnet. Allerdings packt Git gelegentlich mehrere dieser Objekte in eine einzige Binärdatei namens „packfile“, um Platz zu sparen und effizienter zu sein. -Git tut dies, wenn Sie zu viele lose Objekte haben, wenn Sie den Befehl git gc manuell ausführen oder wenn Sie einen Push an einen Remote-Server senden. -Um zu sehen, was passiert, können Sie Git manuell auffordern, die Objekte zu packen, indem Sie den Befehl git gc aufrufen:

+Git tut dies, wenn du zu viele lose Objekte hast, wenn du den Befehl git gc manuell ausführst oder wenn du einen Push an einen Remote-Server sendest. +Um zu sehen, was passiert, kannst du Git manuell auffordern, die Objekte zu packen, indem du den Befehl git gc aufrufst:

@@ -128,7 +128,7 @@

Packdateien (engl. Packfiles)

-

Wenn Sie in Ihr objects Verzeichnis schauen, werden Sie feststellen, dass die meisten Ihrer Objekte verschwunden sind und ein paar neue Dateien auftauchen:

+

Wenn du in dein objects Verzeichnis schaust, wirst du feststellen, dass die meisten deiner Objekte verschwunden sind und ein paar neue Dateien auftauchen:

@@ -141,21 +141,21 @@

Packdateien (engl. Packfiles)

-

Die verbleibenden Objekte sind die Blobs, auf die von keinem Commit referenziert werden. In diesem Fall die Blobs „what is up, doc?“ Und „test content“, die Sie zuvor erstellt haben. -Da Sie sie nie zu Commits hinzugefügt haben, gelten sie als unreferenziert und sind nicht in Ihrem neuen Packfile gepackt.

+

Die verbleibenden Objekte sind die Blobs, auf die von keinem Commit referenziert werden. In diesem Fall die Blobs „what is up, doc?“ Und „test content“, die du zuvor erstellt hast. +Da du sie nie zu Commits hinzugefügt hast, gelten sie als unreferenziert und sind nicht in deinem neuen Packfile gepackt.

-

Die anderen Dateien sind Ihr neues packfile und ein Index. -Das packfile ist eine einzelne Datei, die den Inhalt aller Objekte enthält, die aus Ihrem Dateisystem entfernt wurden. -Der Index ist eine Datei, die Offsets in diesem packfile enthält, sodass Sie schnell nach einem bestimmten Objekt suchen können. +

Die anderen Dateien sind dein neues packfile und ein Index. +Das packfile ist eine einzelne Datei, die den Inhalt aller Objekte enthält, die aus deinem Dateisystem entfernt wurden. +Der Index ist eine Datei, die Offsets in diesem packfile enthält, sodass du schnell nach einem bestimmten Objekt suchen kannst. Ein weiterer Vorteil ist, dass, obwohl die Objekte auf der Festplatte vor dem Ausführen des Befehls gc insgesamt etwa 15 KB groß waren, die neue Paketdatei nur 7 KB groß ist. -Sie haben die Festplattennutzung halbiert, indem Sie Ihre Objekte gepackt haben.

+Du hast die Festplattennutzung halbiert, indem du deine Objekte gepackt hast.

Wie macht Git das? Wenn Git Objekte packt, sucht es nach Dateien mit ähnlichen Namen und Größen und speichert nur die Deltas von einer Version der Datei zur nächsten. -Sie können im packfile schauen und sehen, was Git getan hat, um Platz zu sparen. -Mit dem Befehl git verify-pack können Sie sehen, was gepackt wurde:

+Du kannst im packfile schauen und sehen, was Git getan hat, um Platz zu sparen. +Mit dem Befehl git verify-pack kannst du sehen, was gepackt wurde:

@@ -187,12 +187,12 @@

Packdateien (engl. Packfiles)

-

Hier verweist der Blob 033b4, der, wenn Sie sich erinnern, die erste Version Ihrer repo.rb Datei war, auf den Blob b042a, der die zweite Version der Datei war. -Die dritte Spalte in der Ausgabe ist die Größe des Objekts im Paket. Sie können also sehen, dass b042a 22 KB der Datei belegt, 033b4 jedoch nur 9 Byte. -Interessant ist auch, dass die zweite Version der Datei als Ganzes gespeichert wird, während die Originalversion als Delta gespeichert wird. Dies liegt daran, dass Sie mit größter Wahrscheinlichkeit einen schnelleren Zugriff auf die neueste Version der Datei benötigen.

+

Hier verweist der Blob 033b4, der, wie du dich erinnerst, die erste Version deiner repo.rb Datei war, auf den Blob b042a, der die zweite Version der Datei war. +Die dritte Spalte in der Ausgabe ist die Größe des Objekts im Paket. Du kannst also sehen, dass b042a 22 KB der Datei belegt, 033b4 jedoch nur 9 Byte. +Interessant ist auch, dass die zweite Version der Datei als Ganzes gespeichert wird, während die Originalversion als Delta gespeichert wird. Dies liegt daran, dass du mit größter Wahrscheinlichkeit einen schnelleren Zugriff auf die neueste Version der Datei benötigst.

Das Schöne daran ist, dass es jederzeit umgepackt werden kann. -Git packt Ihre Datenbank gelegentlich automatisch neu und versucht dabei immer, mehr Speicherplatz zu sparen. Sie können das Packen jedoch auch jederzeit manuell durchführen, indem Sie git gc manuell ausführen.

+Git packt deine Datenbank gelegentlich automatisch neu und versucht dabei immer, mehr Speicherplatz zu sparen. Du kannst das Packen jedoch auch jederzeit manuell durchführen, indem du git gc manuell ausführst.

\ No newline at end of file diff --git a/content/book/de/v2/Git-Interna-Transfer-Protokolle.html b/content/book/de/v2/Git-Interna-Transfer-Protokolle.html index d8125152df..f9e05cc412 100644 --- a/content/book/de/v2/Git-Interna-Transfer-Protokolle.html +++ b/content/book/de/v2/Git-Interna-Transfer-Protokolle.html @@ -25,7 +25,7 @@

Transfer Protokolle

Das dumme Protokoll

-

Wenn Sie ein Repository einrichten, das schreibgeschützt über HTTP bereitgestellt wird, wird wahrscheinlich das dumme Protokoll verwendet. +

Wenn du ein Repository einrichtest, das schreibgeschützt über HTTP bereitgestellt wird, wird wahrscheinlich das dumme Protokoll verwendet. Dieses Protokoll wird als „dumm“ bezeichnet, da es während des Transportvorgangs keinen Git-spezifischen Code auf der Serverseite erfordert. Der Abrufprozess besteht aus einer Reihe von HTTP GET Abfragen, bei denen der Client das Layout des Git-Repositorys auf dem Server übernehmen kann.

@@ -54,7 +54,7 @@

Das dumme Protokoll

Das erste, was dieser Befehl tut, ist das pullen der Datei info/refs. -Diese Datei wird mit dem Befehl update-server-info geschrieben. Aus diesem Grund müssen Sie diesen als post-receive Hook aktivieren, damit der HTTP-Transport ordnungsgemäß funktioniert:

+Diese Datei wird mit dem Befehl update-server-info geschrieben. Aus diesem Grund musst du diesen als post-receive Hook aktivieren, damit der HTTP-Transport ordnungsgemäß funktioniert:

@@ -63,8 +63,8 @@

Das dumme Protokoll

-

Jetzt haben Sie eine Liste der remote Referenzen und der SHA-1s. -Als Nächstes suchen Sie nach der HEAD-Referenz, damit Sie wissen, was Sie abschließend überprüfen müssen:

+

Jetzt hast du eine Liste der remote Referenzen und der SHA-1s. +Als Nächstes suchst du nach der HEAD-Referenz, damit du weißt, was du abschließend überprüfen musst:

@@ -73,9 +73,9 @@

Das dumme Protokoll

-

Sie müssen den 'master'-Branch auschecken, wenn Sie den Vorgang abgeschlossen haben. -Jetzt können Sie mit dem laufenden Prozess beginnen. -Da Ihr Ausgangspunkt das Commit-Objekt ca82a6 ist, das Sie in der Datei info/refs gesehen haben, rufen Sie zunächst Folgendes ab:

+

Du musst den 'master'-Branch auschecken, wenn du den Vorgang abgeschlossen hast. +Jetzt kannst du mit dem laufenden Prozess beginnen. +Da dein Ausgangspunkt das Commit-Objekt ca82a6 ist, das du in der Datei info/refs gesehen hast, rufst du zunächst Folgendes ab:

@@ -84,8 +84,8 @@

Das dumme Protokoll

-

Sie erhalten ein Objekt zurück – das Objekt befindet sich in losem Format auf dem Server und Sie haben es über einen statischen HTTP-GET-Aufruf abgerufen. -Sie können es zlib-dekomprimieren, den Header entfernen und den Commit-Inhalt anzeigen:

+

Du erhältst ein Objekt zurück – das Objekt befindet sich in losem Format auf dem Server und du hast es über einen statischen HTTP-GET-Aufruf abgerufen. +Du kannst es zlib-dekomprimieren, den Header entfernen und den Commit-Inhalt anzeigen:

@@ -99,7 +99,7 @@

Das dumme Protokoll

-

Als nächstes müssen Sie zwei weitere Objekte abrufen – cfda3b, das ist der Inhaltsbaum, auf den das gerade abgerufene Commit verweist; und 085bb3, welches das übergeordnete Commit ist:

+

Als nächstes musst du zwei weitere Objekte abrufen – cfda3b, das ist der Inhaltsbaum, auf den das gerade abgerufene Commit verweist; und 085bb3, welches das übergeordnete Commit ist:

@@ -108,8 +108,8 @@

Das dumme Protokoll

-

Damit haben Sie Ihr nächstes Commit-Objekt. -Holen Sie sich nun das Baumobjekt:

+

Damit hast du dein nächstes Commit-Objekt. +Hole dir nun das Baumobjekt:

@@ -118,8 +118,8 @@

Das dumme Protokoll

-

Hoppla – es sieht so aus, als ob das Baum-Objekt auf dem Server nicht im losen Format vorliegt, sodass Sie eine 404-Antwort erhalten. -Dafür gibt es mehrere Gründe: Das Objekt befindet sich möglicherweise in einem alternativen Repository oder in einem packfile Paketdatei in diesem Repository. +

Hoppla – es sieht so aus, als ob das Baum-Objekt auf dem Server nicht im losen Format vorliegt, sodass du eine 404-Antwort erhältst. +Dafür gibt es mehrere Gründe: Das Objekt befindet sich möglicherweise in einem alternativen Repository oder in einemr Paketdatei (engl. packfile) in diesem Repository. Git sucht zuerst nach allen gelisteten Alternativen:

@@ -129,9 +129,9 @@

Das dumme Protokoll

-

Wenn dies mit einer Liste alternativer URLs zurückgibt, sucht Git dort nach losen Dateien und packfiles. Dies ist ein nützlicher Mechanismus für Projekte, die sich gegenseitig forken, um Objekte auf der Festplatte zu teilen. -Da in diesem Fall jedoch keine Alternativen aufgeführt sind, muss sich Ihr Objekt in einem packfile befinden. -Um zu sehen, welche packfiles auf diesem Server verfügbar sind, müssen Sie die Datei objects/info/packs abrufen, die eine Liste dieser Dateien enthält (dies wird ebenfalls mittels update-server-info generiert):

+

Falls dies eine Liste alternativer URLs zurückgibt, sucht Git dort nach losen Dateien und packfiles. Dies ist ein nützlicher Mechanismus für Projekte, die sich gegenseitig forken, um Objekte auf der Festplatte zu teilen. +Da in diesem Fall jedoch keine Alternativen aufgeführt sind, muss sich dein Objekt in einem packfile befinden. +Um zu sehen, welche packfiles auf diesem Server verfügbar sind, musst du die Datei objects/info/packs abrufen, die eine Liste dieser Dateien enthält (dies wird ebenfalls mittels update-server-info generiert):

@@ -140,8 +140,8 @@

Das dumme Protokoll

-

Es gibt nur ein packfile auf dem Server, sodass sich Ihr Objekt offensichtlich dort befindet. Überprüfen Sie jedoch den Index, um dies auch sicherzustellen. -Dies ist ebenfalls nützlich, wenn sich mehrere packfiles auf dem Server befinden. Sie können so prüfen, welches packfile das gewünschte Objekt enthält:

+

Es gibt nur ein packfile auf dem Server, sodass sich dein Objekt offensichtlich dort befindet. Überprüfe jedoch den Index, um dies auch sicherzustellen. +Dies ist ebenfalls nützlich, wenn sich mehrere packfiles auf dem Server befinden. Du kannst so prüfen, welches packfile das gewünschte Objekt enthält:

@@ -150,8 +150,8 @@

Das dumme Protokoll

-

Nachdem Sie nun den packfile-Index haben, können Sie sehen, ob sich Ihr Objekt darin befindet. Da Index listet die SHA-1-Werte der in dem packfile enthaltenen Objekte und die Offsets zu diesen Objekten. -Ihr Objekt ist vorhanden, also holen sie sich das komplette packfile:

+

Nachdem du nun den packfile-Index hast, kannst du sehen, ob sich dein Objekt darin befindet. Der Index listet die SHA-1-Werte der in dem packfile enthaltenen Objekte und die Offsets zu diesen Objekten. +Dein Objekt ist vorhanden, also holen dir das ganze packfile:

@@ -160,9 +160,9 @@

Das dumme Protokoll

-

Nun haben Sie Ihr Baumobjekt und gehen Ihre Commits weiter durch. -Sie befinden sich alle in dem gerade heruntergeladenen packfile, sodass Sie keine weiteren Anfragen an Ihren Server stellen müssen. -Git checkt eine Arbeitskopie des master Branches aus, auf die in der HEAD-Referenz verwiesen wurde, die Sie zu Beginn heruntergeladen haben.

+

Nun hast du dein Baumobjekt und kannst deine Commits weiter durchgehen. +Sie befinden sich alle in dem gerade heruntergeladenen packfile, sodass du keine weiteren Anfragen an deinen Server stellen musst. +Git checkt eine Arbeitskopie des master Branches aus, auf die in der HEAD-Referenz verwiesen wurde, die du zu Beginn heruntergeladen hast.

@@ -182,8 +182,8 @@

Daten hochladen

SSH
-

Angenommen, Sie führen in Ihrem Projekt git push origin master aus, und origin ist als URL definiert, die das SSH-Protokoll verwendet. -Git startet den send-pack Prozess, der eine Verbindung über SSH zu Ihrem Server aufbaut. +

Angenommen, du führst in deinem Projekt git push origin master aus, und origin ist als URL definiert, die das SSH-Protokoll verwendet. +Git startet den send-pack Prozess, der eine Verbindung über SSH zu deinem Server aufbaut. Es wird versucht, einen Befehl auf dem Remote-Server über einen SSH-Aufruf auszuführen, der in etwa so aussieht:

@@ -203,13 +203,13 @@
SSH

Die Daten werden in Paketen (eng. chunks) übertragen. Jeder Chunk beginnt mit einem 4-stelligen Hex-Wert, der angibt, wie lang der Chunk ist (einschließlich der 4 Bytes der Gesamtlänge). Die Pakete enthalten in der Regel eine einzige Zeile mit Daten und einen abschließenden Zeilenvorschub. -Ihr erster Chunk beginnt mit 00a5, also hexadezimal für 165, womit das Paket 165 Bytes lang ist. +Dein erster Chunk beginnt mit 00a5, also hexadezimal für 165, womit das Paket 165 Bytes lang ist. Der nächste Chunk ist 0000, d.h. der Server ist mit seiner Referenzliste fertig.

-

Jetzt, da der Server-Status bekannt ist, bestimmt Ihr send-pack Prozess, welche Commits er hat, die der Server nicht hat. +

Jetzt, da der Server-Status bekannt ist, bestimmt dein send-pack Prozess, welche Commits er hat, die der Server nicht hat. Für jede Referenz, die durch diesen Push aktualisiert wird, teilt der send-pack Prozess dem receive-pack Prozess diese Informationen mit. -Wenn Sie beispielsweise den master Branch aktualisieren und einen experiment Branch hinzufügen, sieht die Antwort von send-pack möglicherweise so aus:

+Wenn du beispielsweise den master Branch aktualisieren und einen experiment Branch hinzufügst, sieht die Antwort von send-pack möglicherweise so aus:

@@ -221,10 +221,10 @@
SSH
-

Git sendet eine Zeile für jede Referenz, die Sie aktualisieren, mit der Länge der Zeile, dem alten SHA-1, dem neuen SHA-1 und der Referenz, die aktualisiert wird. +

Git sendet eine Zeile für jede Referenz, die du aktualisierst, mit der Länge der Zeile, dem alten SHA-1, dem neuen SHA-1 und der Referenz, die aktualisiert wird. Die erste Zeile enthält auch die Funktionen des Clients. -Der SHA-1-Wert aller Nullen bedeutet, dass zuvor nichts vorhanden war, da Sie die experiment-Referenz hinzufügen. -Wenn Sie eine Referenz löschen, sehen Sie das Gegenteil: Alle Nullen auf der rechten Seite.

+Der SHA-1-Wert aller Nullen bedeutet, dass zuvor nichts vorhanden war, da du die experiment-Referenz hinzufügst. +Wenn du eine Referenz löschst, siehst du das Gegenteil: Alle Nullen auf der rechten Seite.

Als nächstes sendet der Client ein packfile mit allen Objekten, die der Server noch nicht hat. @@ -266,7 +266,7 @@

HTTP(S)
Der Server zeigt dann mit seiner HTTP-Antwort Erfolg oder Fehler an.

-

Denken Sie daran, dass das HTTP-Protokoll diese Daten möglicherweise zusätzlich in einen „chunked transfer“ Code verpackt.

+

Denke daran, dass das HTTP-Protokoll diese Daten möglicherweise zusätzlich in einen „chunked transfer“ Code verpackt.

@@ -274,13 +274,13 @@
HTTP(S)

Daten herunterladen

-Wenn Sie Daten herunterladen, sind die Prozesse fetch-pack und upload-pack beteiligt. +Wenn du Daten herunterlädst, sind die Prozesse fetch-pack und upload-pack beteiligt. Der Client initiiert einen fetch-Pack Prozess, der eine Verbindung zu einem upload-pack Prozess auf der Remote-Seite herstellt, um auszuhandeln, welche Daten nach übertragen werden sollen.

SSH
-

Wenn Sie den Abruf über SSH ausführen, führt fetch-pack in etwa Folgendes aus:

+

Wenn du den Abruf über SSH ausführst, führt fetch-pack in etwa Folgendes aus:

@@ -359,7 +359,7 @@

Zusammenfassung der Protokolle

Dieser Abschnitt enthält eine sehr grundlegende Übersicht über die Transfer Protokolle. Das Protokoll enthält viele andere Funktionen, wie z.B. multi_ack oder side-band, die jedoch nicht in diesem Buch behandelt werden. -Wir haben versucht, Ihnen ein Gefühl für das allgemeine Hin und Her zwischen Client und Server zu vermitteln. Wenn Sie mehr Informationen diesbezüglich benötigen, sollten Sie sich den Git-Quellcode ansehen.

+Wir haben versucht, dir ein Gefühl für das allgemeine Hin und Her zwischen Client und Server zu vermitteln. Wenn du mehr Informationen diesbezüglich benötigst, solltest du dir den Git-Quellcode ansehen.

\ No newline at end of file diff --git a/content/book/de/v2/Git-Interna-Wartung-und-Datenwiederherstellung.html b/content/book/de/v2/Git-Interna-Wartung-und-Datenwiederherstellung.html index 2e077e1827..a6a3ceed90 100644 --- a/content/book/de/v2/Git-Interna-Wartung-und-Datenwiederherstellung.html +++ b/content/book/de/v2/Git-Interna-Wartung-und-Datenwiederherstellung.html @@ -19,7 +19,7 @@ ---

Wartung und Datenwiederherstellung

-

Möglicherweise müssen sie hin und wieder Bereinigungen durchführen. Bspw. müssen sie ein Repository komprimieren, ein importiertes Repository bereinigen oder verlorene Arbeit wiederherstellen. +

Möglicherweise musst du hin und wieder Bereinigungen durchführen. Bspw. musst du ein Repository komprimieren, ein importiertes Repository bereinigen oder verlorene Arbeit wiederherstellen. In diesem Abschnitt werden einige dieser Szenarien behandelt.

@@ -31,7 +31,7 @@

Wartung

Das „gc“ steht für Garbage Collect und der Befehl führt eine Reihe von Aktionen aus: Er sammelt alle losen Objekte und legt sie in Packfiles ab. Er fasst Packfiles zu einem großen Packfile zusammen. Außerdem entfernt er Objekte, die nicht von einem Commit erreichbar und ein paar Monate alt sind.

-

Sie können auto gc folgendermaßen manuell ausführen:

+

Du kannst auto gc folgendermaßen manuell ausführen:

@@ -40,12 +40,12 @@

Wartung

Auch dies tut im Allgemeinen nichts. -Sie müssen ungefähr 7.000 lose Objekte oder mehr als 50 Packfiles haben, damit Git einen echten gc-Befehl ausführt. -Sie können diese Grenzwerte mit den Konfigurationseinstellungen gc.auto und gc.autopacklimit ändern.

+Du musst ungefähr 7.000 lose Objekte oder mehr als 50 Packfiles haben, damit Git einen echten gc-Befehl ausführt. +Du kannst diese Grenzwerte mit den Konfigurationseinstellungen gc.auto und gc.autopacklimit ändern.

-

Die andere Aktion, die gc durchführt, ist Ihre Referenzen in eine einzige Datei zu packen. -Angenommen, Ihr Repository enthält die folgenden Branches und Tags:

+

Die andere Aktion, die gc durchführt, ist deine Referenzen in eine einzige Datei zu packen. +Angenommen, dein Repository enthält die folgenden Branches und Tags:

@@ -57,7 +57,7 @@

Wartung

-

Wenn Sie git gc ausführen, befinden sich diese Dateien nicht mehr im Verzeichnis refs. +

Wenn du git gc ausführst, befinden sich diese Dateien nicht mehr im Verzeichnis refs. Git verschiebt sie aus Gründen der Effizienz in eine Datei mit dem Namen .git/packed-refs, die so aussieht:

@@ -72,25 +72,25 @@

Wartung

-

Wenn Sie eine Referenz aktualisieren, bearbeitet Git diese Datei nicht, sondern schreibt eine neue Datei in refs/heads. +

Wenn du eine Referenz aktualisierst, bearbeitet Git diese Datei nicht, sondern schreibt eine neue Datei in refs/heads. Um das passende SHA-1 für eine angegebene Referenz zu erhalten, prüft Git diese Referenz im refs Verzeichnis und prüft dann die packed-refs Datei als Fallback. -Wenn Sie jedoch keine Referenz im refs Verzeichnis finden können, befindet sich diese wahrscheinlich in Ihrer packed-refs Datei.

+Wenn du jedoch keine Referenz im refs Verzeichnis finden kannst, befindet sich diese wahrscheinlich in deiner packed-refs Datei.

-

Beachten Sie die letzte Zeile der Datei, die mit einem ^ beginnt. -Dies bedeutet, dass das darüberliegende Tag ein annotiertes Tag ist und dass diese Zeile das Commit ist, auf das das annotierte Tag verweist.

+

Beachte die letzte Zeile der Datei, die mit einem ^ beginnt. +Dies bedeutet, dass das darüber liegende Tag ein annotiertes Tag ist und dass diese Zeile das Commit ist, auf das das annotierte Tag verweist.

Datenwiederherstellung

-

Es wird der Punkt auf Ihrer Git-Reise kommen, an dem Sie versehentlich einen oder mehrere Commits verlieren. -Im Allgemeinen geschieht dies, weil Sie einen Branch mittels force Option löschen und es sich herausstellt, dass Sie den Branch doch noch benötigten. Oder aber es passiert, dass Sie einen Branch hart zurückgesetzt haben und noch benötigte Commits verworfen haben. -Was können sie tun, um ihre Commits zurückzuerhalten?

+

Es wird der Punkt auf deiner Git-Reise kommen, an dem du versehentlich einen oder mehrere Commits verlierst. +Im Allgemeinen geschieht dies, weil du einen Branch mittels force Option löschst und es sich herausstellt, dass du den Branch doch noch benötigt hast. Oder aber es passiert, dass du einen Branch hart zurückgesetzt hast und noch benötigte Commits verworfen hast. +Was kannst du tun, um deine Commits zurückzuerhalten?

-

In diesem Beispiel wird der master Branch in Ihrem Test-Repository auf einen älteren Commit zurückgesetzt und die verlorenen Commits wiederhergestellt. -Lassen Sie uns zunächst überprüfen, wo sich Ihr Repository zu diesem Zeitpunkt befindet:

+

In diesem Beispiel wird der master Branch in deinem Test-Repository auf einen älteren Commit zurückgesetzt und die verlorenen Commits wiederhergestellt. +Lass uns zunächst überprüfen, wo sich dein Repository zu diesem Zeitpunkt befindet:

@@ -103,7 +103,7 @@

Datenwiederherstellung

-

Verschieben Sie nun den 'master'-Branch zurück zum mittleren Commit:

+

Verschiebe nun den 'master'-Branch zurück zum mittleren Commit:

@@ -116,16 +116,16 @@

Datenwiederherstellung

-

Sie haben die beiden obersten Commits verloren. Sie haben jetzt keinen Branch, von dem aus diese Commits erreichbar sind. -Sie müssen das letzte Commit-SHA-1 finden und anschließend einen Branch hinzufügen, der darauf verweist. -Der Trick ist, das letzte Commit SHA-1 zu finden. Leider ist es nicht so, als hätten Sie es auswendig gelernt, oder?

+

Du hast die beiden obersten Commits verloren. Du hast jetzt keinen Branch, von dem aus diese Commits erreichbar ist. +Du musst das letzte Commit-SHA-1 finden und anschließend einen Branch hinzufügen, der darauf verweist. +Der Trick ist, das letzte Commit SHA-1 zu finden. Leider ist es nicht so, als hättest du es auswendig gelernt, oder?

Oft ist der schnellste Weg die Nutzung eines Tools namens git reflog. -Während sie arbeiten, zeichnet Git lautlos im Hintergrund auf, was ihr HEAD ist und worauf es zeigt. -Jedes Mal, wenn Sie Branches commiten oder ändern, wird das Reflog aktualisiert. -Das reflog wird auch durch den Befehl git update-ref aktualisiert. Dies ist ein weiterer Grund, warum Sie diesen Befehl verwenden sollten, anstatt nur den SHA-1-Wert in Ihre ref-Dateien zu schreiben, wie in }}">Git Referenzen beschrieben. -Sie können jederzeit sehen, wo Sie waren, indem Sie git reflog ausführen:

+Während du arbeitest, zeichnet Git lautlos im Hintergrund auf, was dein HEAD ist und worauf es zeigt. +Jedes Mal, wenn du Branches commitest oder änderst, wird das Reflog aktualisiert. +Das reflog wird auch durch den Befehl git update-ref aktualisiert. Dies ist ein weiterer Grund, warum du diesen Befehl verwenden solltest, anstatt nur den SHA-1-Wert in deine ref-Dateien zu schreiben, wie in }}">Git Referenzen beschrieben. +Du kannst jederzeit sehen, wo du warst, indem du git reflog ausführst:

@@ -137,7 +137,7 @@

Datenwiederherstellung

Hier sehen wir die beiden Commits, die wir ausgecheckt haben, jedoch gibt es hier nicht viele Informationen. -Um die gleichen Informationen auf eine viel nützlichere Weise anzuzeigen, können wir git log -g ausführen, wodurch Sie eine normale Logausgabe für Ihr Reflog erhalten.

+Um die gleichen Informationen auf eine viel nützlichere Weise anzuzeigen, können wir git log -g ausführen, wodurch du eine normale Logausgabe für dein Reflog erhältst.

@@ -160,8 +160,8 @@

Datenwiederherstellung

-

Es sieht so aus, als ob Sie das unterste Commit verloren haben. Sie können es also wiederherstellen, indem Sie bei diesem Commit einen neuen Branch erstellen. -Beispielsweise können Sie einen Branch mit dem Namen recover-branch bei diesem Commit (ab1afef) starten:

+

Es sieht so aus, als ob du das unterste Commit verloren hast. Du kannst es also wiederherstellen, indem du bei diesem Commit einen neuen Branch erstellst. +Beispielsweise kannst du einen Branch mit dem Namen recover-branch bei diesem Commit (ab1afef) starten:

@@ -175,8 +175,8 @@

Datenwiederherstellung

-

Sehr gut - jetzt haben Sie einen Branch namens recover-branch, in dem sich früher Ihr master Branch befand, wodurch die ersten beiden Commits wieder erreichbar sind. -Angenommen, Ihr Verlust war aus irgendeinem Grund nicht im Reflog - Sie können dies simulieren, indem Sie recover-branch entfernen und das Reflog löschen. +

Sehr gut - jetzt hast du einen Branch namens recover-branch, in dem sich früher dein master Branch befand, wodurch die ersten beiden Commits wieder erreichbar sind. +Angenommen, dein Verlust war aus irgendeinem Grund nicht im Reflog - du kannst dies simulieren, indem du recover-branch entfernst und das Reflog löschst. Jetzt sind die ersten beiden Commits nicht mehr erreichbar:

@@ -186,10 +186,10 @@

Datenwiederherstellung

-

Da sich die Reflog-Daten im Verzeichnis .git/logs/ befinden, haben Sie praktisch kein Reflog. -Wie können Sie dieses Commit zu diesem Zeitpunkt wiederherstellen? -Eine Möglichkeit ist die Verwendung des Hilfsprogramms git fsck, mit dem Ihre Datenbank auf Integrität überprüft wird. -Wenn Sie es mit der Option --full ausführen, werden alle Objekte angezeigt, auf die kein anderes Objekt zeigt:

+

Da sich die Reflog-Daten im Verzeichnis .git/logs/ befinden, hast du praktisch kein Reflog. +Wie kannst du dieses Commit zu diesem Zeitpunkt wiederherstellen? +Eine Möglichkeit ist die Verwendung des Hilfsprogramms git fsck, mit dem deine Datenbank auf Integrität überprüft wird. +Wenn du es mit der Option --full ausführst, werden alle Objekte angezeigt, auf die kein anderes Objekt zeigt:

@@ -203,8 +203,8 @@

Datenwiederherstellung

-

In diesem Fall können Sie Ihr fehlendes Commit nach dem String „Dangling Commit“ sehen. -Sie können es auf die gleiche Weise wiederherstellen, indem Sie einen Branch hinzufügen, der auf diesen SHA-1 verweist.

+

In diesem Fall kannst du deinen fehlenden Commit nach dem String „Dangling Commit“ sehen. +Du kannst es auf die gleiche Weise wiederherstellen, indem du einen Branch hinzufügst, der auf diesen SHA-1 verweist.

@@ -212,22 +212,22 @@

Objekte löschen

Es gibt viele großartige Dinge an Git. Eine Funktion, die jedoch Probleme verursachen kann, ist die Tatsache, dass ein Git-Klon den gesamten Verlauf des Projekts herunterlädt, einschließlich jeder Version jeder Datei. Dies ist in Ordnung, wenn das Ganze Quellcode ist. Git ist stark darin, diese Daten effizient zu komprimieren. -Wenn jedoch zu einem beliebigen Zeitpunkt im Verlauf Ihres Projekts eine einzelne große Datei hinzugefügt wird, muss jeder Klon für alle Zeiten diese große Datei herunterladen, auch wenn sie beim nächsten Commit aus dem Projekt entfernt wurde. +Wenn jedoch zu einem beliebigen Zeitpunkt im Verlauf deines Projekts eine einzelne große Datei hinzugefügt wird, muss jeder Klon für alle Zeiten diese große Datei herunterladen, auch wenn sie beim nächsten Commit aus dem Projekt entfernt wurde. Weil sie von der Historie aus erreichbar ist, wird sie immer da sein.

-

Dies kann ein großes Problem sein, wenn Sie Subversion- oder Perforce-Repositorys nach Git konvertieren. -Da Sie in diesen Systemen nicht den gesamten Verlauf herunterladen, hat dieses Model des Hinzufügens nur wenige Konsequenzen. -Wenn Sie einen Import von einem anderen System durchgeführt haben oder auf andere Weise feststellen, dass Ihr Repository viel größer ist, als es sein sollte, können Sie große Objekte folgendermaßen finden und entfernen.

+

Dies kann ein großes Problem sein, wenn du Subversion- oder Perforce-Repositorys nach Git konvertierst. +Da du in diesen Systemen nicht den gesamten Verlauf herunterlädst, hat dieses Model des Hinzufügens nur wenige Konsequenzen. +Wenn du einen Import von einem anderen System durchgeführt hast oder auf andere Weise feststellst, dass dein Repository viel größer ist, als es sein sollte, kannst du große Objekte folgendermaßen finden und entfernen.

-

Seien Sie gewarnt: Diese Technik wirkt sich zerstörerisch auf Ihren Commit-Verlauf aus. -Es schreibt jedes Commitobjekt neu, seit dem frühesten Baum, den Sie ändern müssen, um einen Verweis auf eine große Datei zu entfernen. -Wenn Sie dies unmittelbar nach einem Import tun, bevor jemand damit begonnen hat, sich auf das Commit zu stützen, ist alles in Ordnung. Andernfalls müssen Sie alle Mitwirkenden benachrichtigen, dass sie ihre Arbeit auf Ihre neuen Commits rebasen müssen.

+

Seie gewarnt: Diese Technik wirkt sich zerstörerisch auf deinen Commit-Verlauf aus. +Es schreibt jedes Commitobjekt neu, seit dem frühesten Baum, den du ändern musst, um einen Verweis auf eine große Datei zu entfernen. +Wenn du dies unmittelbar nach einem Import tust, bevor jemand damit begonnen hat, sich aufs Committen zu stützen, ist alles in Ordnung. Andernfalls musst du alle Mitwirkenden benachrichtigen, dass sie ihre Arbeit auf deinen neuen Commits rebasen müssen.

-

Zur Veranschaulichung fügen Sie Ihrem Test-Repository eine große Datei hinzu, entfernen Sie sie beim nächsten Commit. Anschließend suchen Sie sie und entfernen sie dauerhaft aus dem Repository. -Fügen Sie Ihrer Historie zunächst ein großes Objekt hinzu:

+

Zur Veranschaulichung füge deinem Test-Repository eine große Datei hinzu und entferne sie beim nächsten Commit. Anschließend suchst du sie und entfernst sie dauerhaft aus dem Repository. +Füge deiner Historie zunächst ein großes Objekt hinzu:

@@ -240,7 +240,7 @@

Objekte löschen

-

Hoppla - Sie wollten Ihrem Projekt keinen riesigen Tarball hinzufügen. +

Hoppla - du wolltest deinem Projekt keinen riesigen Tarball hinzufügen. Besser wäre, es loszuwerden:

@@ -254,7 +254,7 @@

Objekte löschen

-

Nun wenden sie gc auf Ihre Datenbank an und sehen sie, wie viel Speicherplatz Sie verwenden:

+

Wende nun gc auf deine Datenbank an und prüfe, wie viel Speicherplatz du verwendest:

@@ -267,7 +267,7 @@

Objekte löschen

-

Sie können den Befehl count-objects ausführen, um schnell zu sehen, wie viel Speicherplatz Sie verwenden:

+

Du kannst den Befehl count-objects ausführen, um schnell zu sehen, wie viel Speicherplatz du verwendest:

@@ -283,17 +283,17 @@

Objekte löschen

-

Der size-pack Eintrag gibt die Größe Ihrer Packdateien in Kilobyte an. Somit verwenden Sie fast 5 MB an Speicherplatz. -Vor dem letzten Commit haben Sie einen Wert von ungefähr 2 KB belegt. Wenn Sie die Datei aus dem vorherigen Commit entfernen, würde sie offensichtlich nicht aus Ihrem Verlauf entfernt. -Jedes Mal, wenn jemand dieses Repository klont, muss er 5 MB klonen, um dieses winzige Projekt zu erhalten, da Sie versehentlich eine große Datei hinzugefügt haben. -Lass sie es uns loswerden.

+

Der size-pack Eintrag gibt die Größe deiner Packdateien in Kilobyte an. Somit verwendest du fast 5 MB an Speicherplatz. +Vor dem letzten Commit hast du einen Wert von ungefähr 2 KB belegt. Wenn du die Datei aus dem vorherigen Commit entfernst, wird sie offensichtlich nicht aus deinem Verlauf entfernt. +Jedes Mal, wenn jemand dieses Repository klont, muss er 5 MB klonen, um dieses winzige Projekt zu erhalten, da du versehentlich eine große Datei hinzugefügt hast. +Besser wir werden sie los.

-

Als erstes müssen wir es finden. -In diesem Fall wissen Sie bereits, um welche Datei es sich handelt. -Angenommen, Sie wissen es nicht. Wie würden Sie feststellen, welche Datei oder welche Dateien so viel Speicherplatz beanspruchen? -Wenn Sie git gc ausführen, befinden sich alle Objekte in einer Packdatei. Sie können die großen Objekte identifizieren, indem Sie einen anderen Installationsbefehl namens git verify-pack ausführen und die Ausgabe nach dem dritte Feld sortieren, das die Dateigröße ist. -Sie können es auch über den Befehl tail pipen, da Sie nur an den letzten, großen Dateien interessiert sind:

+

Als erstes müssen wir sie finden. +In diesem Fall weißt du bereits, um welche Datei es sich handelt. +Angenommen, du weißt es nicht. Wie würdest du feststellen, welche Datei oder welche Dateien so viel Speicherplatz beanspruchen? +Wenn du git gc ausführst, befinden sich alle Objekte in einer Packdatei. Du kannst die großen Objekte identifizieren, indem du einen anderen Installationsbefehl namens git verify-pack ausführst und die Ausgabe nach dem dritte Feld sortierst, das die Dateigröße ist. +Du kannst es auch über den Befehl tail pipen, da du nur an den letzten, großen Dateien interessiert bist:

@@ -307,9 +307,9 @@

Objekte löschen

Das große Objekt befindet sich unten: 5 MB. -Um herauszufinden, um welche Datei es sich handelt, verwenden Sie den Befehl rev-list, den Sie kurz in }}">Ein bestimmtes Commit-Message-Format erzwingen verwendet haben. -Wenn Sie --objects an rev-list übergeben, werden alle festgeschriebenen SHA-1s und auch die BLOB-SHA-1s mit den ihnen zugeordneten Dateipfaden aufgelistet. -Sie können dies verwenden, um den Namen Ihres Blobs zu finden:

+Um herauszufinden, um welche Datei es sich handelt, verwende den Befehl rev-list, den du schonmal in }}">Ein bestimmtes Commit-Message-Format erzwingen verwendet hast. +Wenn du --objects an rev-list übergibst, werden alle festgeschriebenen SHA-1s und auch die BLOB-SHA-1s mit den ihnen zugeordneten Dateipfaden aufgelistet. +Du kannst dies verwenden, um den Namen deines Blobs zu finden:

@@ -318,8 +318,8 @@

Objekte löschen

-

Jetzt müssen Sie diese Datei von allen Bäumen in Ihrer Historie entfernen. -Sie können leicht sehen, welche Commits diese Datei geändert haben:

+

Jetzt musst du diese Datei von allen Bäumen in deiner Historie entfernen. +Du kannst leicht sehen, welche Commits diese Datei geändert haben:

@@ -329,8 +329,8 @@

Objekte löschen

-

Sie müssen alle Commits hinter 7b30847 neu schreiben, um diese Datei vollständig aus Ihrem Git-Verlauf zu entfernen. -Verwenden Sie dazu filter-branch, den Sie in }}">Den Verlauf umschreiben verwendet haben:

+

Du musst alle Commits hinter 7b30847 neu schreiben, um diese Datei vollständig aus deinem Git-Verlauf zu entfernen. +Verwende dazu filter-branch, den du in }}">Den Verlauf umschreiben verwendet hast:

@@ -342,20 +342,20 @@

Objekte löschen

-

Die Option --index-filter ähnelt der Option --tree-filter, die in }}">Den Verlauf umschreiben verwendet wurde. Jedoch ändern sie jedes Mal Ihren Staging-Bereich oder Index anstatt daß sie einen Befehl zum Modifizieren von ausgecheckten Dateien auf ihrer Platte übergeben.

+

Die Option --index-filter ähnelt der Option --tree-filter, die in }}">Den Verlauf umschreiben verwendet wurde. Jedoch ändern sie jedes Mal deinen Staging-Bereich oder Index anstatt daß sie einen Befehl zum Modifizieren von ausgecheckten Dateien auf deine Platte übergibt.

-

Anstatt eine bestimmte Datei mit etwas wie rm file zu entfernen, müssen Sie sie mit git rm --cached entfernen - Sie müssen sie aus dem Index entfernen, nicht von der Festplatte. +

Anstatt eine bestimmte Datei mit etwas wie rm file zu entfernen, musst du sie mit git rm --cached entfernen - du musst sie aus dem Index entfernen, nicht von der Festplatte. Der Grund dafür ist die Geschwindigkeit - da Git nicht jede Revision auf der Festplatte auschecken muss, bevor der Filter ausgeführt wird, kann der Prozess sehr viel schneller sein. -Sie können die gleiche Aufgabe mit --tree-filter ausführen, wenn Sie möchten. +Du kannst die gleiche Aufgabe mit --tree-filter ausführen, wenn du möchtest. Die Option --ignore-unmatch für git rm weist an, dass keine Fehler auftreten, wenn das zu entfernende Muster nicht vorhanden ist. -Schließlich fordern Sie filter-branch auf, Ihre Historie erst ab dem Commit 7b30847 neu zu schreiben, da Sie wissen, wo dieses Problem begann. +Schließlich forderst du filter-branch auf, deine Historie erst ab dem Commit 7b30847 neu zu schreiben, da du weißt, wo dieses Problem begann. Andernfalls wird es von vorne beginnen und unnötig länger dauern.

-

Ihr Verlauf enthält nun keinen Verweis mehr auf diese Datei. -Ihr Reflog und eine neue Gruppe von Refs, die Git hinzugefügt hat, als Sie den filter-branch unter .git/refs/original ausgeführt haben, enthält jedoch weiterhin Verweise, sodass Sie sie entfernen und die Datenbank neu packen müssen. -Sie müssen alles loswerden, das einen Zeiger auf diese alten Commits enthält, bevor Sie neu packen:

+

Dein Verlauf enthält nun keinen Verweis mehr auf diese Datei. +Dein Reflog und eine neue Gruppe von Refs, die Git hinzugefügt hat, als du den filter-branch unter .git/refs/original ausgeführt hast, enthält jedoch weiterhin Verweise, sodass du sie entfernen und die Datenbank neu packen musst. +Du musst alles loswerden, das einen Zeiger auf diese alten Commits enthält, bevor du neu packst:

@@ -370,7 +370,7 @@

Objekte löschen

-

Mal sehen, wie viel Platz Sie gespart haben.

+

Mal sehen, wie viel Platz du gespart hast.

@@ -387,8 +387,8 @@

Objekte löschen

Die Größe des gepackten Repositorys beträgt nur noch 8 KB, was viel besser als 5 MB ist. -Sie können anhand der Größe erkennen, dass sich das große Objekt noch in Ihren losen Objekten befindet, sodass es nicht verschwunden ist. Es wird jedoch nicht auf einen Push oder nachfolgenden Klon übertragen, was wichtig ist. -Wenn Sie es wirklich wollten, können Sie das Objekt vollständig entfernen, indem Sie git prune mit der Option --expire ausführen:

+Du kannst anhand der Größe erkennen, dass sich das große Objekt noch in deinem losen Objekten befindet, sodass es nicht verschwunden ist. Es wird jedoch nicht auf einen Push oder nachfolgenden Klon übertragen, was wichtig ist. +Wenn du es wirklich willst, kannst du das Objekt vollständig entfernen, indem du git prune mit der Option --expire ausführst:

@@ -409,22 +409,22 @@

Objekte löschen

Git läuft immer in einer bash Shell und verwendet eine Reihe von Shell-Umgebungsvariablen, über die man steuern kann, wie es sich verhält. -Gelegentlich ist es hilfreich zu wissen, welche diese sind und wie Sie Git dazu bringen können, sich so zu verhalten, wie Sie es möchten. +Gelegentlich ist es hilfreich zu wissen, welche diese sind und wie du Git dazu bringen kannst, sich so zu verhalten, wie du es möchtest. Dies ist keine vollständige Liste aller Umgebungsvariablen auf die Git achtet, aber wir werden die nützlichsten behandeln.

-

Globals Verhalten

+

Globales Verhalten

Einige der generellen Eigenschaften von Git als Computerprogramm hängen von Umgebungsvariablen ab.

GIT_EXEC_PATH bestimmt, wo Git nach seinen Unterprogrammen sucht (wie git-commit, git-diff und andere). - Sie können die aktuelle Einstellung überprüfen, indem Sie git --exec-path ausführen.

+ Du kannst die aktuelle Einstellung überprüfen, indem du git --exec-path ausführst.

HOME wird normalerweise nicht als anpassbar angesehen (zu viele andere Dinge hängen davon ab), aber hier sucht Git nach der globalen Konfigurationsdatei. - Wenn Sie eine wirklich portable Git-Installation mit globaler Konfiguration wünschen, können Sie HOME im portablen Git Shell-Profil überschreiben.

+ Wenn du eine wirklich portable Git-Installation mit globaler Konfiguration wünschst, kannst du HOME im portablen Git Shell-Profil überschreiben.

PREFIX ist ähnlich, jedoch für die systemweite Konfiguration. @@ -432,7 +432,7 @@

Globals Verhalten

GIT_CONFIG_NOSYSTEM, falls gesetzt, deaktiviert die Verwendung der systemweiten Konfigurationsdatei. - Dies ist nützlich, wenn Ihre Systemkonfiguration Ihre Befehle beeinträchtigt, Sie jedoch keinen Zugriff haben, um diese zu ändern oder zu entfernen.

+ Dies ist nützlich, wenn deine Systemkonfiguration deine Befehle beeinträchtigt, du jedoch keinen Zugriff hast, um diese zu ändern oder zu entfernen.

GIT_PAGER steuert das Programm, mit dem mehrseitige Ausgaben in der Befehlszeile angezeigt werden. @@ -454,11 +454,11 @@

Speicherort des Repositorys

GIT_CEILING_DIRECTORIES steuert das Verhalten bei der Suche nach einem .git Verzeichnis. -Wenn Sie auf Verzeichnisse zugreifen, die nur langsam geladen werden können (z.B. auf einem Bandlaufwerk oder über eine langsame Netzwerkverbindung), möchten Sie möglicherweise, dass Git den Versuch vorzeitig abbricht, insbesondere wenn Git in der Kommandozeile aufgerufen wird.

+Wenn du auf Verzeichnisse zugreifst, die nur langsam geladen werden können (z.B. auf einem Bandlaufwerk oder über eine langsame Netzwerkverbindung), möchtest du möglicherweise, dass Git den Versuch vorzeitig abbricht, insbesondere wenn Git in der Kommandozeile aufgerufen wird.

GIT_WORK_TREE ist der Speicherort des Stammverzeichnisses eines Arbeitsverzeichnisses für ein non-bare Repository. -Wenn --git-dir oder GIT_DIR angegeben ist, jedoch nicht --work-tree, GIT_WORK_TREE oder core.worktree, wird das aktuelle Arbeitsverzeichnis als oberste Ebene Ihres Arbeitsbaums betrachtet.

+Wenn --git-dir oder GIT_DIR angegeben ist, jedoch nicht --work-tree, GIT_WORK_TREE oder core.worktree, wird das aktuelle Arbeitsverzeichnis als oberste Ebene deines Arbeitsbaums betrachtet.

GIT_INDEX_FILE ist der Pfad zur Indexdatei (nur für non-bare Repositorys).

@@ -468,19 +468,19 @@

Speicherort des Repositorys

GIT_ALTERNATE_OBJECT_DIRECTORIES ist eine durch Doppelpunkte getrennte Liste (also im Format /dir/one:/dir/two:… `), die Git mitteilt, wo nach Objekten gesucht werden soll, wenn sie sich nicht in GIT_OBJECT_DIRECTORY` befinden. -Wenn Sie viele Projekte mit großen Dateien haben, die genau den gleichen Inhalt haben, können Sie damit vermeiden, dass zu viele Kopien davon gespeichert werden.

+Wenn du viele Projekte mit großen Dateien hast, die genau den gleichen Inhalt haben, kannst du damit vermeiden, dass zu viele Kopien davon gespeichert werden.

Pfadspezifikation (engl. Pathspec)

-

„Pathspec“ bezieht sich darauf, wie Sie Pfade in Git angeben, einschließlich der Verwendung von Platzhaltern. +

„Pathspec“ bezieht sich darauf, wie du Pfade in Git angibst, einschließlich der Verwendung von Platzhaltern. Diese werden in der Datei .gitignore aber auch in der Befehlszeile (git add *.c) verwendet.

GIT_GLOB_PATHSPECS und GIT_NOGLOB_PATHSPECS steuern das Standardverhalten von Platzhaltern in Pfadangaben. Wenn GIT_GLOB_PATHSPECS auf 1 gesetzt ist, werden Platzhalterzeichen als Platzhalter verwendet (dies ist die Standardeinstellung). Wenn GIT_NOGLOB_PATHSPECS auf 1 gesetzt ist, stimmen Platzhalterzeichen nur mit sich selbst überein. Dies bedeutet, dass .c nur mit einer Datei namens „ .c“ übereinstimmt und nicht mit einer Datei, deren Name mit .c endet. -Sie können dies in Einzelfällen überschreiben, indem Sie die Pfadangabe mit :(glob) oder :(literal) beginnen, wie in :(glob)*.c.

+Du kannst dies in Einzelfällen überschreiben, indem du die Pfadangabe mit :(glob) oder :(literal) beginnst, wie in :(glob)*.c.

GIT_LITERAL_PATHSPECS deaktiviert beide oben genannten Verhaltensweisen. Es können keine Platzhalterzeichen verwendet werden, und die Präfixe zum Überschreiben sind ebenfalls deaktiviert.

@@ -525,7 +525,7 @@

Netzwerk

GIT_SSL_NO_VERIFY weist Git an, SSL-Zertifikate nicht zu verifizieren. -Dies kann manchmal erforderlich sein, wenn Sie ein selbstsigniertes Zertifikat verwenden, um Git-Repositorys über HTTPS bereitzustellen, oder wenn Sie gerade einen Git-Server einrichten, aber noch kein vollständiges Zertifikat installiert haben.

+Dies kann manchmal erforderlich sein, wenn du ein selbstsigniertes Zertifikat verwendest, um Git-Repositorys über HTTPS bereitzustellen, oder wenn du gerade einen Git-Server einrichtest, aber noch kein vollständiges Zertifikat installiert hast.

Wenn die Datenrate einer HTTP-Operation unter GIT_HTTP_LOW_SPEED_LIMIT Bytes pro Sekunde und länger als GIT_HTTP_LOW_SPEED_TIME Sekunden anhält, bricht Git diese Operation ab. @@ -583,8 +583,8 @@

Vergleichen und Zusammenführen

Debugging

-

Möchten Sie wirklich wissen, was in Git abgeht? -In Git ist eine umfangreiche Sammlung von Traces eingebettet, alles was Sie tun müssen, ist sie einzuschalten. +

Möchtest du wirklich wissen, was in Git abgeht? +In Git ist eine umfangreiche Sammlung von Traces eingebettet. Alles was du tun musst, ist sie einzuschalten. Die möglichen Werte dieser Variablen lauten wie folgt:

@@ -689,16 +689,16 @@

Sonstiges

GIT_SSH, falls angegeben, ist ein Programm, das anstelle von ssh aufgerufen wird, um eine Verbindung zu einem SSH-Host herzustellen. Es wird folgendermaßen aufgerufen: $GIT_SSH [username@]host [-p <port>] <befehl>. -Beachten Sie, dass dies nicht der einfachste Weg ist, um zu konfigurieren, wie ssh aufgerufen wird. Es werden keine zusätzlichen Befehlszeilenparameter unterstützt, daher müssen Sie ein Wrapper-Skript schreiben und GIT_SSH so einstellen, dass es darauf verweist. +Beachte, dass dies nicht der einfachste Weg ist, um zu konfigurieren, wie ssh aufgerufen wird. Es werden keine zusätzlichen Befehlszeilenparameter unterstützt, daher musst du ein Wrapper-Skript schreiben und GIT_SSH so einstellen, dass es darauf verweist. Es ist wahrscheinlich einfacher, dafür einfach die Datei ~/.ssh/config zu verwenden.

GIT_ASKPASS dient zur Überschreibung des Konfigurationswertes core.askpass. -Dies ist das Programm, das immer dann aufgerufen wird, wenn Git den Benutzer nach Anmeldeinformationen fragen muss, wobei eine Eingabeaufforderung als Befehlszeilenargument erwartet wird und die eine Antwort auf stdout zurückgeben soll. Weitere Informationen zu diesem Subsystem finden Sie unter }}">Anmeldeinformationen speichern.

+Dies ist das Programm, das immer dann aufgerufen wird, wenn Git den Benutzer nach Anmeldeinformationen fragen muss, wobei eine Eingabeaufforderung als Befehlszeilenargument erwartet wird und die eine Antwort auf stdout zurückgeben soll. Weitere Informationen zu diesem Subsystem findest du unter }}">Anmeldeinformationen speichern.

GIT_NAMESPACE steuert den Zugriff auf namenspaced refs und entspricht dem Flag --namespace. -Dies ist vor allem auf der Serverseite nützlich, wo Sie möglicherweise mehrere Forks eines einzelnen Repositorys in einem Repository speichern möchten, wobei nur die Refs getrennt bleiben.

+Dies ist vor allem auf der Serverseite nützlich, wo du möglicherweise mehrere Forks eines einzelnen Repositorys in einem Repository speichern möchtest, wobei nur die Refs getrennt bleiben.

GIT_FLUSH kann verwendet werden, um Git zu zwingen, nicht gepuffertes I/O zu verwenden, wenn inkrementell in stdout geschrieben wird. @@ -706,7 +706,7 @@

Sonstiges

Der Standardwert (falls diese Variable nicht festgelegt ist) ist die Auswahl eines geeigneten Pufferschemas abhängig von Aktivität und Ausgabemodus.

-

Mit GIT_REFLOG_ACTION können Sie den beschreibenden Text angeben, der in das Reflog geschrieben wird. +

Mit GIT_REFLOG_ACTION kannst du den beschreibenden Text angeben, der in das Reflog geschrieben wird. Hier ein Beispiel:

diff --git a/content/book/de/v2/Git-Interna-Zusammenfassung.html b/content/book/de/v2/Git-Interna-Zusammenfassung.html index 5cc58daf0c..6f94f667f1 100644 --- a/content/book/de/v2/Git-Interna-Zusammenfassung.html +++ b/content/book/de/v2/Git-Interna-Zusammenfassung.html @@ -19,12 +19,12 @@ ---

Zusammenfassung

-

Zu diesem Zeitpunkt sollten Sie ein ziemlich gutes Verständnis dafür haben, was Git im Hintergrund macht und bis zu einem gewissen Grad auch, wie es implementiert ist. -Dieses Kapitel hat eine Reihe von Basisbefehlen behandelt – Befehle, die niedriger und einfacher sind als die Porzellanbefehle, die Sie im Rest des Buches kennengelernt haben. -Wenn Sie verstehen, wie Git auf einer niedrigeren Ebene funktioniert, sollten Sie leichter verstehen, warum es das tut, was es tut. Sie könnten nun Ihre eigenen Tools und Hilfsskripten schreiben, damit Ihr spezifischer Workflow für Sie funktioniert.

+

Zu diesem Zeitpunkt solltest du ein ziemlich gutes Verständnis dafür haben, was Git im Hintergrund macht und bis zu einem gewissen Grad auch, wie es implementiert ist. +Dieses Kapitel hat eine Reihe von Basisbefehlen behandelt – Befehle, mehr Low-Level sind als die Standardbefehle, die du im Rest des Buches kennengelernt hast. +Wenn du verstehst, wie Git auf einer niedrigeren Ebene funktioniert, solltest du leichter verstehen, warum es das tut, was es tut. Du kannst nun deine eigenen Tools und Hilfsskripten schreiben, damit dein spezifischer Workflow für dich funktioniert.

-

Git als inhaltsadressierbares Dateisystem ist ein sehr leistungsfähiges Tool, das Sie problemlos als mehr als nur ein einfaches VCS verwenden können. -Wir hoffen, dass Sie Ihr neu gewonnenes Wissen über Git-Interna nutzen können, um Ihre eigene coole Anwendung dieser Technologie zu implementieren und sich auf fortgeschrittenere Weise mit Git vertraut zu machen.

+

Git als inhalts-adressierbares Dateisystem ist ein sehr leistungsfähiges Tool, das du problemlos als mehr als nur ein einfaches VCS verwenden kannst. +Wir hoffen, dass du dein neu gewonnenes Wissen über Git-Interna nutzen kannst, um deine eigene coole Anwendung dieser Technologie zu implementieren und dich auf fortgeschrittenere Weise mit Git vertraut zu machen.

\ No newline at end of file diff --git a/content/book/de/v2/_index.html b/content/book/de/v2/_index.html index fc9a11e903..2b9116a79a 100644 --- a/content/book/de/v2/_index.html +++ b/content/book/de/v2/_index.html @@ -7,7 +7,7 @@ language_code: de front_page: true repository_url: https://github.com/progit/progit2-de - sha: 90e884a3a1fe1dc84811ecf901f40abd8e0322a2 + sha: 70417a7a38a8b4e9c9b51fe5bafd3bac09fbd2ad page_title: Git - Book url: "/book/de/v2.html" aliases: diff --git a/content/book/de/v2/ch00/_globals_verhalten.html b/content/book/de/v2/ch00/_globales_verhalten.html similarity index 71% rename from content/book/de/v2/ch00/_globals_verhalten.html rename to content/book/de/v2/ch00/_globales_verhalten.html index 22a6411763..6366aef9c9 100644 --- a/content/book/de/v2/ch00/_globals_verhalten.html +++ b/content/book/de/v2/ch00/_globales_verhalten.html @@ -1,3 +1,3 @@ --- -redirect_to: "book/de/v2/Git-Interna-Wartung-und-Datenwiederherstellung#_globals_verhalten" +redirect_to: "book/de/v2/Git-Interna-Wartung-und-Datenwiederherstellung#_globales_verhalten" ---