From 346a5a5fb0ca9f7e719f371a11fe3100158831b1 Mon Sep 17 00:00:00 2001 From: Oscar Santiago Date: Thu, 14 Sep 2023 17:15:00 +0200 Subject: [PATCH 1/3] kapitel zwei review --- book/02-git-basics/sections/aliases.asc | 6 +- .../sections/getting-a-repository.asc | 8 +-- .../sections/recording-changes.asc | 10 ++-- book/02-git-basics/sections/remotes.asc | 46 +++++++-------- book/02-git-basics/sections/tagging.asc | 28 +++++----- book/02-git-basics/sections/undoing.asc | 56 +++++++++---------- .../sections/viewing-history.asc | 38 ++++++------- ch02-git-basics-chapter.asc | 6 +- 8 files changed, 99 insertions(+), 99 deletions(-) diff --git a/book/02-git-basics/sections/aliases.asc b/book/02-git-basics/sections/aliases.asc index 9a1b60a1..46c14291 100644 --- a/book/02-git-basics/sections/aliases.asc +++ b/book/02-git-basics/sections/aliases.asc @@ -5,8 +5,8 @@ Bevor wir dieses Kapitel über Basic Git abschließen, gibt es noch einen kurzen Tipp, der Ihre Arbeit mit Git einfacher, leichter und verständlicher machen kann: Aliase. Der Klarheit halber werden wir sie nirgendwo anders in diesem Buch verwenden, aber wenn Sie Git in Zukunft regelmäßig verwenden, dann sind Aliase etwas, das Sie kennen sollten. -Git schließt nicht automatisch auf Ihren Befehl, wenn Sie ihn nur teilweise eingeben. -Wenn Sie nicht den gesamten Text von jedem der Git-Befehle eingeben möchten, können Sie mit Hilfe von `git config` einfach ein Alias für jeden Befehl einrichten.(((Git Befehle, config))) +Git erkennt nicht automatisch Ihren Befehl, wenn Sie ihn nur teilweise eingeben. +Wenn Sie nicht den gesamten Text jedes Git-Befehls eingeben möchten, können Sie mit Hilfe von `git config` einfach ein Alias für jeden Befehl einrichten.(((Git Befehle, config))) Hier sind ein paar Beispiele, die Sie einrichten sollten: [source,console] @@ -62,7 +62,7 @@ Wie Sie feststellen können, ersetzt Git einfach den neuen Befehl durch den Alia Vielleicht möchten Sie jedoch eher einen externen Befehl als einen Git-Subbefehl ausführen. In diesem Fall starten Sie den Befehl mit einem Ausrufezeichen (`!`). Das ist hilfreich, wenn Sie Ihre eigenen Tools schreiben, die mit einem Git-Repository arbeiten. -Wir können dies demonstrieren, indem wir `git visual` mit `gitk` aliasieren: +Wir können dies demonstrieren, indem wir `git visual` mit `gitk` aliasen: [source,console] ---- diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index cb889186..48a8c2bb 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -56,11 +56,11 @@ Im Moment ist nur wichtig, dass Sie verstehen, dass Sie jetzt ein Git-Repository [[_git_cloning]] ==== Ein existierendes Repository klonen -Wenn Sie eine Kopie eines existierenden Git-Repositorys anlegen wollen – um beispielsweise an einem Projekt mitzuarbeiten – können Sie den Befehl `git clone` verwenden. +Wenn Sie eine Kopie eines existierenden Git-Repositories anlegen wollen – um beispielsweise an einem Projekt mitzuarbeiten – können Sie den Befehl `git clone` verwenden. Wenn Sie bereits Erfahrung mit einem anderen VCS-System, wie Subversion, gesammelt haben, fällt Ihnen bestimmt sofort auf, dass der Befehl „clone“ und nicht etwa „checkout“ lautet. Das ist ein wichtiger Unterschied, den Sie unbedingt verstehen sollten. Anstatt nur eine einfache Arbeitskopie vom Projekt zu erzeugen, lädt Git nahezu alle Daten, die der Server bereithält, auf den lokalen Rechner. Jede Version von jeder Datei der Projekt-Historie wird automatisch heruntergeladen, wenn Sie `git clone` ausführen. -Wenn Ihre Serverfestplatte beschädigt wird, können Sie nahezu jeden der Klone auf irgendeinem Client verwenden, um den Server wieder in den Zustand zurückzusetzen, in dem er sich zum Zeitpunkt des Klonens befand. (Sie werden vielleicht einige serverseitige Hooks und dergleichen verlieren, aber alle versionierten Daten wären vorhanden – siehe Kapitel 4, <>, für weitere Details.) +Wenn Ihre Serverfestplatte beschädigt wird, können Sie nahezu jeden der Klone auf irgendeinem Client verwenden, um den Server wieder in den Zustand zurückzusetzen, in dem er sich zum Zeitpunkt des Klonens befand. (Sie werden vielleicht einige serverseitige Hooks und dergleichen verlieren, aber alle versionierte Daten wären vorhanden – siehe Kapitel 4, <>, für weitere Details.) Sie können ein Repository mit dem Befehl `git clone [url]` klonen.(((Git Befehle, clone))) Um beispielsweise das Repository der verlinkbaren Git-Bibliothek `libgit2` zu klonen, führen Sie den folgenden Befehl aus: @@ -70,7 +70,7 @@ Um beispielsweise das Repository der verlinkbaren Git-Bibliothek `libgit2` zu kl $ git clone https://github.com/libgit2/libgit2 ---- -Git legt dann ein Verzeichnis `libgit2` an, initialisiert in diesem ein `.git` Verzeichnis, lädt alle Daten des Repositorys herunter und checkt eine Arbeitskopie der aktuellsten Version aus. +Git legt dann ein Verzeichnis `libgit2` an, initialisiert in diesem ein `.git` Verzeichnis, lädt alle Daten des Repositories herunter und checkt eine Arbeitskopie der aktuellsten Version aus. Wenn Sie in das neue `libgit2` Verzeichnis wechseln, finden Sie dort die Projektdateien und können gleich damit arbeiten. Wenn Sie das Repository in ein Verzeichnis mit einem anderen Namen als `libgit2` klonen möchten, können Sie das wie folgt durchführen: @@ -84,4 +84,4 @@ Dieser Befehl tut das Gleiche wie der vorhergehende, aber das Zielverzeichnis la Git unterstützt eine Reihe unterschiedlicher Übertragungsprotokolle. Das vorhergehende Beispiel verwendet das `https://` Protokoll, aber Ihnen können auch die Angaben `git://` oder `user@server:path/to/repo.git` begegnen, welches das SSH-Transfer-Protokoll verwendet. -Kapitel 4, <>, stellt alle verfügbaren Optionen vor, die der Server für den Zugriff auf Ihr Git-Repository hat und die Vor- und Nachteile der einzelnen Optionen, die man einrichten kann. +Kapitel 4, <>, stellt alle verfügbaren Optionen vor, die der Server für den Zugriff auf Ihr Git-Repository hat und die Vor- und Nachteile der möglichen Optionen. diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 954de3fa..c92614f7 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -1,7 +1,7 @@ === Änderungen nachverfolgen und im Repository speichern -An dieser Stelle sollten Sie ein _originalgetreues_ Git-Repository auf Ihrem lokalen Computer und eine Checkout- oder Arbeitskopie aller seiner Dateien vor sich haben. -Normalerweise werden Sie damit beginnen wollen, Änderungen vorzunehmen und Schnappschüsse dieser Änderungen in Ihr Repository zu übertragen, wenn das Projekt so weit fortgeschritten ist, dass Sie es sichern möchten. +An dieser Stelle sollten Sie ein _angemessenes_ Git-Repository auf Ihrem lokalen Computer und eine Checkout- oder Arbeitskopie aller seiner Dateien vor sich haben. +Normalerweise werden Sie damit beginnen wollen, Änderungen vorzunehmen und Schnappschüsse dieser Änderungen in Ihr Repository zu committen, wenn das Projekt so weit fortgeschritten ist, dass Sie es sichern möchten. Denken Sie daran, dass sich jede Datei in Ihrem Arbeitsverzeichnis in einem von zwei Zuständen befinden kann: _tracked_ oder _untracked_ – Änderungen an der Datei werden verfolgt (engl. _tracked_) oder eben nicht (engl. _untracked_). Tracked Dateien sind Dateien, die im letzten Snapshot enthalten sind. Genauso wie alle neuen Dateien in der Staging-Area. Sie können entweder unverändert, modifiziert oder für den nächsten Commit vorgemerkt (staged) sein. @@ -20,7 +20,7 @@ image::images/lifecycle.png[Der Status Ihrer Dateien im Überblick] ==== Zustand von Dateien prüfen Das wichtigste Hilfsmittel, um den Zustand zu überprüfen, in dem sich Ihre Dateien gerade befinden, ist der Befehl `git status`.(((Git Befehle, status))) -Wenn Sie diesen Befehl unmittelbar nach dem Klonen eines Repositorys ausführen, sollte er in etwa folgende Ausgabe liefern: +Wenn Sie diesen Befehl unmittelbar nach dem Klonen eines Repositories ausführen, sollte er in etwa folgende Ausgabe liefern: [source,console] ---- @@ -42,7 +42,7 @@ GitHub änderte Mitte 2020 den Standard-Branch-Namen von `master` in `main`, und Daher werden Sie möglicherweise feststellen, dass der Standard-Branch-Name in einigen neu erstellten Repositories `main` und nicht `master` ist. Außerdem kann der Standard-Branch-Name geändert werden (wie Sie in <> gesehen haben), sodass Sie möglicherweise einen anderen Namen für den Standard-Branch vorfinden. -Git selbst verwendet jedoch immer noch `master` als Standard, also werden wir auch es im gesamten Buch verwenden. +Git selbst verwendet jedoch immer noch `master` als Standard, also werden wir es auch im gesamten Buch verwenden. ==== Nehmen wir einmal an, Sie fügen eine neue Datei mit dem Namen `README` zu Ihrem Projekt hinzu. @@ -582,7 +582,7 @@ Oder Sie können Folgendes ausführen: $ git rm \*~ ---- -Dieses Kommando entfernt alle Dateien, deren Name mit einer `~` endet. +Dieses Kommando entfernt alle Dateien, deren Name mit `~` endet. [[_git_mv]] ==== Dateien verschieben diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index a6321c7d..743eb3af 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -1,15 +1,15 @@ [[_remote_repos]] === Mit Remotes arbeiten -Um an jedem Git-Projekt mitarbeiten zu können, müssen Sie wissen, wie Sie Ihre Remote-Repositorys verwalten können. -Remote-Repositorys sind Versionen Ihres Projekts, die im Internet oder im Netzwerk irgendwo gehostet werden. +Um an Git-Projekte mitarbeiten zu können, müssen Sie wissen, wie Sie Remote-Repositories verwalten können. +Remote-Repositories sind Versionen Ihres Projekts, die im Internet oder im Netzwerk irgendwo gehostet werden. Sie können mehrere einrichten, von denen jedes in der Regel entweder schreibgeschützt oder beschreibbar für Sie ist. -Die Zusammenarbeit mit anderen erfordert die Verwaltung dieser Remote-Repositorys sowie das Pushing und Pulling von Daten zu und von den Repositorys, wenn Sie Ihre Arbeit teilen möchten. -Die Verwaltung von Remote-Repositorys umfasst das Wissen, wie man entfernte Repositorys hinzufügt, nicht mehr gültige Remotes entfernt, verschiedene Remote-Branches verwaltet, sie als versioniert oder nicht versioniert definiert und vieles mehr. +Die Zusammenarbeit mit anderen erfordert die Verwaltung dieser Remote-Repositories sowie das Pushing und Pulling von Daten zu und von den Repositories, wenn Sie Ihre Arbeit teilen möchten. +Die Verwaltung von Remote-Repositories umfasst das Wissen, wie man entfernte Repositories hinzufügt, nicht mehr gültige Remotes entfernt, verschiedene Remote-Branches verwaltet, sie als versioniert oder nicht versioniert definiert und vieles mehr. In diesem Abschnitt werden wir einige dieser Remote-Management-Fertigkeiten erörtern. [NOTE] -.Remote-Repositorys können auch auf Ihrem lokalen Rechner liegen. +.Remote-Repositories können auch auf Ihrem lokalen Rechner liegen. ==== Es ist durchaus möglich, dass Sie mit einem „entfernten“ Repository arbeiten können, das sich tatsächlich auf demselben Host befindet auf dem Sie gerade arbeiten. Das Wort „remote“ bedeutet nicht unbedingt, dass sich das Repository an einem anderen Ort im Netzwerk oder Internet befindet, sondern nur, dass es an einem anderen Ort liegt. @@ -36,7 +36,7 @@ $ git remote origin ---- -Sie können zusätzlich auch `-v` angeben, das Ihnen die URLs anzeigt, die Git für den Kurznamen gespeichert hat, der beim Lesen und Schreiben auf diesem Remote verwendet werden soll: +Sie können zusätzlich auch `-v` angeben, das Ihnen die URLs anzeigt, die Git für den Kurznamen gespeichert hat, um beim Lesen und Schreiben auf diesen Remote zuzugreifen: [source,console] ---- @@ -72,7 +72,7 @@ Beachten Sie, dass diese Remotes eine Vielzahl von Protokollen verwenden; wir we ==== Hinzufügen von Remote-Repositorys Wir haben bereits erwähnt und einige Beispiele gezeigt, wie der Befehl `git clone` stillschweigend den Remote `origin` für Sie hinzufügt. -So können Sie explizit einen neuen Remote hinzufügen.(((Git Befehle, remote))) +Im Folgendem beschreiben wir, wie Sie einen neuen Remote hinzufügen können.(((Git Befehle, remote))) Um ein neues Remote-Git-Repository als Kurzname hinzuzufügen, auf das Sie leicht verweisen können, führen Sie `git remote add ` aus: [source,console] @@ -87,8 +87,8 @@ pb https://github.com/paulboone/ticgit (fetch) pb https://github.com/paulboone/ticgit (push) ---- -Jetzt können Sie die Zeichenfolge `pb` auf der Kommandozeile anstelle der gesamten URL verwenden. -Wenn Sie beispielsweise alle Informationen abrufen möchten, die Paul hat, die aber noch nicht in Ihrem Repository enthalten sind, können Sie `git fetch pb` ausführen: +Nun können Sie die Zeichenfolge `pb` auf der Kommandozeile anstelle der gesamten URL verwenden. +Wenn Sie beispielsweise alle Informationen fetchen möchten, die Paul hat, die aber noch nicht in Ihrem Repository enthalten sind, können Sie `git fetch pb` ausführen: [source,console] ---- @@ -115,17 +115,17 @@ Wie Sie gerade gesehen haben, können Sie Daten aus Ihren Remote-Projekten abruf $ git fetch ---- -Der Befehl geht an das Remote-Projekt und zieht (engl. pull) alle Daten von diesem Remote-Projekt runter, die Sie noch nicht haben. +Der Befehl geht an das Remote-Projekt und zieht (engl. pull) alle Daten von diesem Remote-Projekt, die Sie noch nicht haben. Danach sollten Sie Referenzen auf alle Branches von diesem Remote haben, die Sie jederzeit einbinden oder inspizieren können. Wenn Sie ein Repository klonen, fügt der Befehl dieses entfernte Repository automatisch unter dem Namen „origin“ hinzu. -So holt `git fetch origin` alle neuen Inhalte, die seit dem Klonen (oder dem letzten Abholen) auf diesen Server verschoben wurden. -Es ist jedoch wichtig zu beachten, dass der Befehl `git fetch` nur die Daten in Ihr lokales Repository herunterlädt – er mischt (engl. merged) sie nicht automatisch mit Ihrer Arbeit zusammen oder ändert das, woran Sie gerade arbeiten. +So holt `git fetch origin` alle Änderungen, die seit dem Klonen (oder dem letzten Abholen) auf diesen Server abgelegt (engl. pushed) wurden. +Es ist jedoch wichtig zu beachten, dass der Befehl `git fetch` nur die Daten in Ihr lokales Repository herunterlädt – er merged sie nicht automatisch mit Ihrer Arbeit zusammen oder ändert das, woran Sie gerade arbeiten. Sie müssen das Ganze manuell mit Ihrer Arbeit zusammenführen, wenn Sie fertig sind. Wenn Ihr aktueller Branch so eingerichtet ist, dass er einen entfernten Branch verfolgt (engl. tracking), können Sie den Befehl `git pull` verwenden, um diesen entfernten Branch automatisch zu holen und dann mit Ihrem aktuellen Branch zusammenzuführen (siehe den nächsten Abschnitt und <> für weitere Informationen).(((Git Befehle, pull))) Das könnte ein einfacherer oder komfortablerer Workflow für Sie sein. Standardmäßig richtet der Befehl `git clone` Ihren lokalen `master` Branch automatisch so ein, dass er den entfernten `master` Branch (oder wie auch immer der Standard-Branch genannt wird) auf dem Server versioniert von dem Sie ihn geklont haben. -Wenn Sie `git pull` ausführen, werden normalerweise Daten von dem Server abgerufen, von dem Sie ursprünglich geklont haben, und es wird automatisch versucht in den Code zu mergen, an dem Sie gerade arbeiten. +Wenn Sie `git pull` ausführen, werden normalerweise Daten von dem Server abgerufen, von dem Sie ursprünglich geklont haben. Anschliessend wird automatisch versucht diese Daten in ihren Code zu mergen. [NOTE] ==== @@ -142,9 +142,9 @@ Wenn Sie mit dem Pullen einen Rebase machen wollen: [[_pushing_remotes]] ==== Zu Ihren Remotes Pushen -Wenn Sie Ihr Projekt an einem bestimmten Punkt haben, den Sie teilen möchten, müssen Sie es zum Upstream verschieben (engl. pushen). -Der Befehl dafür ist einfach: `git push `.(((Git Befehle, push))) -Wenn Sie Ihren `master` Branch auf Ihren `origin` Server verschieben möchten (nochmals, das Klonen richtet im Regelfall beide dieser Namen automatisch für Sie ein), dann können Sie diesen Befehl auch nutzen, um alle Commits, die Sie durchgeführt haben, auf den Server zu übertragen: +Wenn Sie Ihr Projekt an einem Punkt haben, den Sie teilen möchten, können Sie es zum Upstream verschieben (engl. pushen). +Der Befehl dafür lautet: `git push `.(((Git Befehle, push))) +Wenn Sie Ihren `master` Branch auf Ihren `origin` Server verschieben möchten (Zur Erinnerung: das Klonen richtet im Regelfall diese beiden Namen automatisch für Sie ein), dann können Sie diesen Befehl auch nutzen, um alle Commits, die Sie durchgeführt haben, auf den Server zu übertragen: [source,console] ---- @@ -160,7 +160,7 @@ Siehe Kapitel 3 <> mit ausf ==== Inspizieren eines Remotes Wenn Sie mehr Informationen über einen bestimmten Remote sehen möchten, können Sie den Befehl `git remote show ` verwenden.(((Git Befehle, remote))) -Wenn Sie diesen Befehl mit einem spezifischen Kurznamen ausführen, wie z.B. `origin`, erhalten Sie eine ähnliche Meldung: +Wenn Sie diesen Befehl mit einem remote Kurznamen ausführen, wie z.B. `origin`, erhalten Sie bspw. folgende Meldung: [source,console] ---- @@ -178,12 +178,12 @@ $ git remote show origin master pushes to master (up to date) ---- -Er listet die URL für das Remote-Repository sowie die Informationen zu den Tracking-Branchen auf. -Der Befehl teilt Ihnen hilfreich mit, dass, wenn Sie sich im Master-Zweig befinden und `git pull` ausführen, der `master` Branch des remotes nach dem abrufen (engl. fetched) automatisch mit dem lokalen Branch gemerged wird. +Er listet die URL für das Remote-Repository sowie die Informationen zu den Tracking-Branches auf. +Der Befehl teilt Ihnen mit, dass, wenn Sie sich im Master-Zweig befinden und `git pull` ausführen, der `master` Branch des remotes nach dem abrufen (engl. fetched) automatisch mit dem lokalen Branch gemerged wird. Er listet auch alle Remote-Referenzen auf, die er abgerufen hat. -Das ist nur ein einfaches Beispiel, auf das Sie vermutlich treffen werden. -Wenn Sie Git hingegen intensiver verwenden, können Sie viel mehr Informationen aus `git remote show` herauslesen: +Das ist nur ein einfaches Beispiel, auf das Sie möglicherweise treffen werden. +Wenn Sie Git hingegen intensiver verwenden, können die `git remote show` Ausgabe wesentlich umfangreicher sein: [source,console] ---- @@ -210,7 +210,7 @@ $ git remote show origin ---- Dieser Befehl zeigt an, zu welchem Zweig automatisch gepusht wird, wenn Sie `git push` ausführen, während Sie sich in bestimmten Branches befinden. -Er zeigt Ihnen auch, welche entfernten Branches auf dem Server sind, die Sie noch nicht haben, welche entfernten Branches Sie haben, die aber vom Server entfernt wurden und die lokalen Branches, die automatisch mit Ihrem Remote-Tracking-Branch zusammengeführt (gemergt) werden können, wenn Sie `git pull` ausführen. +Er zeigt Ihnen auch, welche entfernten Branches auf dem Server vorhanden sind, die Sie noch nicht haben, welche entfernten Branches Sie haben, die aber vom Server gelöscht wurden und die lokalen Branches, die automatisch mit Ihrem Remote-Tracking-Branch zusammengeführt (gemergt) werden können, wenn Sie `git pull` ausführen. ==== Umbenennen und Entfernen von Remotes @@ -226,7 +226,7 @@ paul ---- Es ist zu beachten, dass dadurch auch alle Ihre Remote-Tracking-Branchnamen geändert werden. -Was früher mit `pb/master` angesprochen wurde, ist jetzt `paul/master`. +Was vorher unter `pb/master` referenziert wurde, ist jetzt unter `paul/master` zu finden. Wenn Sie einen Remote aus irgendwelchen Gründen entfernen möchten – Sie haben den Server verschoben oder verwenden einen bestimmten Mirror nicht länger oder ein Beitragender ist nicht mehr dabei – dann können Sie entweder `git remote remove` oder `git remote rm` verwenden: diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 7bf66e7a..2124229c 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -54,7 +54,7 @@ Git unterstützt zwei Arten von Tags: _lightweight_ (d.h. nicht-annotiert) und _ Ein nicht-annotiertes Tag ist sehr ähnlich eines Branches, der sich nicht ändert – es ist nur ein Zeiger auf einen bestimmten Commit. Annotierte Tags werden dagegen als vollständige Objekte in der Git-Datenbank gespeichert. -Sie werden mit einer Prüfsumme versehen, enthalten den Tagger-Namen, die E-Mail-Adresse und das Datum, haben eine Tagging-Meldung und können mit GNU Privacy Guard (GPG) signiert und überprüft werden. +Sie werden mit einer Prüfsumme versehen, enthalten den Tagger-Namen, die E-Mail-Adresse und das Datum, haben eine Tagging-Nachricht und können mit GNU Privacy Guard (GPG) signiert und überprüft werden. Es wird allgemein empfohlen, dass Sie annotierte Tags erstellen, damit Sie all diese Informationen erhalten können; aber wenn Sie ein temporäres Tag wünschen oder aus irgendwelchen Gründen die anderen Informationen nicht speichern wollen, sind auch nicht-annotierte Tags möglich. [[_annotated_tags]] @@ -73,10 +73,10 @@ v1.3 v1.4 ---- -Ein `-m` spezifiziert eine Tagging-Meldung, die mit dem Tag gespeichert wird. -Wenn Sie keine Meldung für ein annotiertes Tag angeben, startet Git Ihren Editor, damit Sie diese eingeben können. +Ein `-m` spezifiziert eine Tagging-Nachricht, die mit dem Tag gespeichert wird. +Wenn Sie keine Nachricht für ein annotiertes Tag angeben, startet Git Ihren Editor, damit Sie diese eingeben können. -Sie können die Tag-Daten zusammen mit dem Commit einsehen, der mit dem Befehl `git show` getaggt wurde: +Sie können die Tag-Daten zusammen mit dem getaggten Commit sehen, indem Sie den Befehl `git show` verwenden: [source,console] ---- @@ -94,7 +94,7 @@ Date: Mon Mar 17 21:52:11 2008 -0700 Change version number ---- -Es werden die Tagger-Informationen, das Datum, an dem der Commit getaggt wurde, und die Annotationsmeldung angezeigt, gefolgt von den Commit-Informationen. +Es werden die Tagger-Informationen, das Datum, an dem der Commit getaggt wurde, und die Annotationsnachricht angezeigt, gefolgt von den Commit-Informationen. ==== Lightweight Tags @@ -129,7 +129,7 @@ Date: Mon Mar 17 21:52:11 2008 -0700 ==== Nachträgliches Tagging -Sie können auch Commits markieren, wenn Sie sich bereits an einem anderen Punkt befinden. +Sie können auch ältere Commits markieren. Angenommen, Ihr Commit-Verlauf sieht so aus: [source,console] @@ -147,7 +147,7 @@ a6b4c97498bd301d84096da251c98a07c7723e65 Create write support 8a5cbc430f1a9c3d00faaeffd07798508422908a Update readme ---- -Nehmen wir an, Sie haben vergessen, das Projekt mit v1.2 zu markieren, das bei dem Commit von „Update rakefile“ vorlag. +Nehmen wir an, Sie haben vergessen, das Projekt mit v1.2 beim Commit von „Update rakefile“ zu taggen. Sie können ihn nachträglich hinzufügen. Um diesen Commit zu markieren, geben Sie am Ende des Befehls die Commit-Prüfsumme (oder einen Teil davon) an: @@ -156,7 +156,7 @@ Um diesen Commit zu markieren, geben Sie am Ende des Befehls die Commit-Prüfsum $ git tag -a v1.2 9fceb02 ---- -Sie sehen, dass Sie den Commit markiert haben:(((Git Befehle, tag))) +Sie sehen, dass Sie den Commit getaggt haben:(((Git Befehle, tag))) [source,console] ---- @@ -183,10 +183,10 @@ Date: Sun Apr 27 20:43:35 2008 -0700 ---- [[_sharing_tags]] -==== Tags freigeben +==== Tags teilen Normalerweise überträgt der Befehl `git push` keine Tags an den Remote-Server.(((Git Befehle, push))) -Sie müssen Tags explizit auf einen freigegebenen Server verschieben, nachdem Sie sie erstellt haben. +Sie müssen Tags explizit auf einen Server verschieben, nachdem Sie sie erstellt haben. Dieser Prozess funktioniert genauso wie das Freigeben von Remote-Branches – Sie müssen dazu `git push origin ` ausführen. [source,console] @@ -201,7 +201,7 @@ To git@github.com:schacon/simplegit.git * [new tag] v1.5 -> v1.5 ---- -Wenn Sie eine Menge Tags haben, die Sie auf einmal pushen wollen, können Sie auch die Option `--tags` mit dem Befehl `git push` verwenden. +Wenn Sie viele Tags haben, die Sie auf einmal pushen wollen, können Sie auch die Option `--tags` mit dem Befehl `git push` verwenden. Dadurch werden alle Ihre Tags auf den Remote-Server übertragen, die sich noch nicht auf dem Server befinden. [source,console] @@ -247,7 +247,7 @@ To /git@github.com:schacon/simplegit.git - [deleted] v1.4-lw ---- -Die Lösung, das oben Gezeigte zu interpretieren, besteht darin, es als Nullwert zu lesen, bevor der Doppelpunkt auf den Remote-Tag-Namen verschoben wird, wodurch es effektiv gelöscht wird. +Die Erklärung des obigen Befehls: als Nullwert zu lesen, bevor der Doppelpunkt auf den Remote-Tag-Name gepushed wird, wodurch dieser gelöscht wird. Der zweite, intuitivere Weg, ein Remote-Tag zu löschen, ist mit: @@ -288,7 +288,7 @@ HEAD is now at df3f601... Add atlas.json and cover image ---- Wenn Sie im Zustand „losgelöster HEAD“ Änderungen vornehmen und dann einen Commit erstellen, bleibt der Tag gleich, aber Ihr neuer Commit gehört zu keinem Branch und ist unzugänglich, außer mit dem genauen Commit-Hash. -Wenn Sie also Änderungen vornehmen müssen – z.B. wenn Sie einen Fehler in einer älteren Version beheben – sollten Sie im Regelfall einen Branch erstellen: +Wenn Sie also Änderungen vornehmen müssen – z.B. wenn Sie einen Fehler in einer älteren Version beheben – sollten einen Branch erstellen: [source,console] ---- @@ -296,4 +296,4 @@ $ git checkout -b version2 v2.0.0 Switched to a new branch 'version2' ---- -Wenn Sie das tun und einen Commit erstellen, wird sich Ihr Zweig `version2` leicht von Ihrem Tag `v2.0.0` unterscheiden, da er mit Ihren neuen Änderungen fortschreitet, seien Sie also vorsichtig. +Wenn Sie das tun und einen Commit erstellen, wird sich Ihr Branch `version2` leicht von Ihrem Tag `v2.0.0` unterscheiden, da er mit Ihren neuen Änderungen fortschreitet, seien Sie also vorsichtig. diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index 38baaa33..6e3748bd 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -1,13 +1,13 @@ [[_undoing]] === Ungewollte Änderungen rückgängig machen -Zu jeder Zeit können Sie eine Änderung rückgängig machen. -Hier werden wir einige grundlegende Werkzeuge besprechen, die zum Widerrufen von gemachten Änderungen dienen. -Seien Sie vorsichtig, denn man kann nicht immer alle diese Annullierungen rückgängig machen. -Das ist einer der wenigen Bereiche in Git, in denen Sie etwas Arbeit verlieren könnten, wenn Sie etwas falsch machen. +Es kommt sicherlich irgendwann der Zeitpunkt, an dem Sie eine Änderung rückgängig (engl. undo) machen wollen. +Wir werden hier einige grundlegende Werkzeuge besprechen, mit denen sie genau das tun können. +Seien Sie vorsichtig, man kann diese Aktionen nicht immer rückgängig machen. +Das ist einer der wenigen Bereiche in Git, in denen Sie ihre Arbeit verlieren könnten, wenn Sie etwas falsch machen. -Eines der häufigsten Undos tritt auf, wenn Sie zu früh committen und möglicherweise vergessen haben, einige Dateien hinzuzufügen, oder wenn Sie Ihre Commit-Nachricht durcheinander bringen. -Wenn Sie den Commit erneut ausführen möchten, nehmen Sie die zusätzlichen Änderungen vor, die Sie vergessen haben, stellen diese bereit (engl. stage) und committen diese erneut mit der Option `--amend`: +Eines der häufigsten Undos tritt auf, wenn Sie zu früh committen und möglicherweise vergessen haben, einige Dateien hinzuzufügen, oder wenn Sie Fehler in ihrer Commit-Nachricht haben. +Wenn Sie den Commit erneut ausführen möchten, führen zusätzlichen Änderungen vor, die Sie vergessen haben, stellen diese bereit (engl. stage) und committen erneut mit der Option `--amend`: [source,console] ---- @@ -90,11 +90,11 @@ Changes not staged for commit: ---- Der Befehl klingt etwas merkwürdig, aber er funktioniert. -Die Datei `CONTRIBUTING.md` wurde modifiziert, aber erneut im Status unstaged. +Die Datei `CONTRIBUTING.md` ist modifiziert und wieder im Status unstaged überführt. [NOTE] ===== -Es ist wahr, dass `git reset` ein riskanter Befehl sein kann, besonders, wenn Sie das `--hard` Flag mitgeben. +Es stimmt, dass `git reset` ein riskanter Befehl sein kann, besonders, wenn Sie das `--hard` Flag mitgeben. In dem oben beschriebenen Szenario wird die Datei in Ihrem Arbeitsverzeichnis jedoch nicht angetastet, so dass er relativ sicher ist. ===== @@ -104,8 +104,8 @@ Wir werden viel ausführlicher darauf eingehen, was `reset` bewirkt und wie man ==== Änderung in einer modifizierten Datei zurücknehmen Was ist, wenn Sie feststellen, dass Sie Ihre Änderungen an der Datei `CONTRIBUTING.md` nicht behalten wollen? -Wie können Sie sie leicht wieder ändern – sie wieder so zurücksetzen, wie sie beim letzten Commit ausgesehen hat (oder anfänglich geklont wurde, oder wie auch immer Sie sie in Ihr Arbeitsverzeichnis bekommen haben)? -Glücklicherweise sagt Ihnen `git status` auch, wie Sie das machen können. +Wie können Sie sie in den Ursprungszustand zurücksetzen, so wie sie beim letzten Commit ausgesehen hat (oder anfänglich geklont wurde, oder wie auch immer Sie sie in Ihr Arbeitsverzeichnis bekommen haben)? +Glücklicherweise sagt Ihnen `git status`, wie Sie das machen können. Im letzten Beispiel sieht die Unstaged-Area so aus: [source,console] @@ -117,8 +117,8 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -Sie erklärt Ihnen ziemlich eindeutig, wie Sie die von Ihnen vorgenommenen Änderungen verwerfen können. -Lassen Sie uns machen, was da steht: +Git erklärt Ihnen, wie Sie die von Ihnen vorgenommenen Änderungen verwerfen können. +Lassen Sie es uns ausführen: [source,console] ---- @@ -132,12 +132,12 @@ Changes to be committed: ---- -Sie können erkennen, dass die Änderungen rückgängig gemacht wurden. +Wie Sie sehen, wurde die Änderungen rückgängig gemacht. [IMPORTANT] ===== -Es ist sehr wichtig zu begreifen, dass `git checkout -- ` ein riskanter Befehl ist. -Alle lokalen Änderungen, die Sie an dieser Datei vorgenommen haben, sind verloren – Git hat diese Datei einfach durch die zuletzt committete oder gestagten Version ersetzt. +Es ist sehr wichtig zu begreifen, dass `git checkout \-- ` ein riskanter Befehl ist. +Alle lokalen Änderungen, die Sie an dieser Datei vorgenommen haben, sind verloren – Git hat diese Datei einfach durch die zuletzt committete oder gestagte Version ersetzt. Verwenden Sie diesen Befehl nur, wenn Sie sich absolut sicher sind, dass Sie diese nicht gespeicherten lokalen Änderungen nicht benötigen. ===== @@ -145,18 +145,18 @@ Wenn Sie die Änderungen, die Sie an dieser Datei gemacht haben, beibehalten mö Denken Sie daran, dass alles, was in Git _committet_ wird, fast immer wiederhergestellt werden kann. Sogar Commits, die auf gelöschten Branches lagen oder Commits, die mit einem `--amend` Commit überschrieben wurden, können wiederhergestellt werden (siehe Kapitel 10 <> für das Wiederherstellen der Daten). -Allerdings wird alles, was Sie verloren haben und das nie committet wurde, wahrscheinlich nie wieder gesehen werden. +Wahrscheinlich werden Sie alles, was Sie verworfen und nie committet haben, nie wieder sehen. [[undoing_git_restore]] -==== Änderungen Rückgängigmachen mit git restore +==== Änderungen mit git restore Rückgängig machen Git Version 2.23.0 führte einen neuen Befehl ein: `git restore`. Es ist im Grunde eine Alternative zu `git reset`, die wir gerade behandelt haben. -Ab Git Version 2.23.0 verwendet Git für viele Rückgängig-Vorgänge `git restore` anstelle von `git reset`. +Ab Git Version 2.23.0 verwendet Git für viele dieser Vorgänge `git restore` anstelle von `git reset`. -Lassen Sie uns unsere Schritte zurückverfolgen und die Dinge mit `git restore` anstelle von `git reset` rückgängig machen. +Lassen Sie uns unsere Schritte wiederholen und die Dinge mit `git restore` anstelle von `git reset` rückgängig machen. -===== Unstagen einer staged Datei mit git restore +===== Eine Datei mit git restore unstagen Die nächsten beiden Abschnitte zeigen, wie Sie an Änderungen in Ihrem Staging-Bereich und im Arbeitsverzeichnisses mit `git restore` arbeiten. Das Schöne daran ist, dass der Befehl, mit dem Sie den Status dieser beiden Bereiche bestimmen, Ihnen auch zeigt, wie Sie Änderungen an ihnen rückgängig machen können. @@ -195,14 +195,14 @@ Changes not staged for commit: ---- -Die Datei `CONTRIBUTING.md` ist geändert aber wieder unstaged. +Die Datei `CONTRIBUTING.md` ist modifiziert und wieder im Status unstaged überführt. -===== Rückgängig machen einer geänderten Datei mit git restore +===== Eine geänderte Datei mit git restore rückgängig machen -Was ist, wenn Sie feststellen, dass Sie Ihre Änderungen an der Datei `CONTRIBUTING.md` nicht beibehalten möchten? -Wie können Sie sie einfach rückgängig machen -- sprich, sie so zurücksetzen, wie sie aussah, als Sie sie zuletzt committet haben (oder ursprünglich geklont haben oder wie auch immer Sie es in Ihr Arbeitsverzeichnis aufgenommen haben)? -Glücklicherweise sagt Ihnen `git status` wiederum, wie das geht. -In der letzten Beispielausgabe sieht der unstaged Bereich folgendermaßen aus: +Was ist, wenn Sie feststellen, dass Sie Ihre Änderungen an der Datei `CONTRIBUTING.md` nicht beibehalten wollen? +Wie können Sie sie in den Ursprungszustand zurücksetzen, so wie sie beim letzten Commit ausgesehen hat (oder anfänglich geklont wurde, oder wie auch immer Sie sie in Ihr Arbeitsverzeichnis bekommen haben)? +Glücklicherweise sagt Ihnen `git status`, wie Sie das machen können. +Im letzten Beispiel sieht die Unstaged-Area so aus: [source,console] ---- @@ -213,8 +213,8 @@ Changes not staged for commit: ---- -Es zeigt Ihnen ziemlich explizit, wie Sie die vorgenommenen Änderungen verwerfen können. -Lassen Sie uns das tun: +Git erklärt Ihnen, wie Sie die von Ihnen vorgenommenen Änderungen verwerfen können. +Lassen Sie es uns ausführen: [source,console] ---- diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 6848abe7..68d72310 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -39,11 +39,11 @@ Date: Sat Mar 15 10:31:28 2008 -0700 Standardmäßig, d.h. ohne Argumente, listet `git log` die in diesem Repository vorgenommenen Commits in umgekehrter chronologischer Reihenfolge auf, d.h. die neuesten Commits werden als Erstes angezeigt. Wie Sie sehen können, listet dieser Befehl jeden Commit mit seiner SHA-1-Prüfsumme, dem Namen und der E-Mail-Adresse des Autors, dem Erstellungs-Datum und der Commit-Beschreibung auf. -Eine Vielzahl und Vielfalt von Optionen für den Befehl `git log` stehen zur Verfügung, um Ihnen exakt das anzuzeigen, wonach Sie suchen. +Eine Vielzahl von Optionen stehen für den Befehl `git log` zur Verfügung, um Ihnen exakt das anzuzeigen, wonach Sie suchen. Hier zeigen wir Ihnen einige der gängigsten. -Eine der hilfreichsten Optionen ist `-p` oder `--patch`. Sie zeigt den Unterschied (die _patch_-Ausgabe) an, der bei jedem Commit eingefügt wird. -Sie können auch die Anzahl der anzuzeigenden Protokolleinträge begrenzen, z.B. mit `-2` nur die letzten beiden Einträge darstellen. +Eine der hilfreichsten Optionen ist `-p` oder `--patch`. Sie zeigt die Änderungen (die _patch_-Ausgabe) an, die bei jedem Commit durchgeführt wurden. +Sie können auch die Anzahl der anzuzeigenden Protokolleinträge begrenzen, z.B. mit `-2` werden nur die letzten beiden Einträge dargestellt. [source,console] ---- @@ -89,10 +89,10 @@ index a0a60ae..47c6340 100644 -end ---- -Diese Option zeigt die gleichen Informationen an, jedoch mit dem Unterschied, dass sie direkt hinter jedem Eintrag stehen. -Diese Funktion ist sehr hilfreich für die Code-Überprüfung oder zum schnellen Durchsuchen der Vorgänge während einer Reihe von Commits, die ein Teammitglied hinzugefügt hat. -Sie können auch eine Reihe von Optionen zur Verdichtung mit `git log` verwenden. -Wenn Sie beispielsweise einige gekürzte Statistiken für jede Übertragung sehen möchten, können Sie die Option `--stat` verwenden: +Diese Option zeigt die gleichen Informationen an, jedoch mit der diff Ausgabe direkt nach jedem Eintrag. +Dies ist sehr hilfreich für die Codeüberprüfung oder um schnell zu durchsuchen, was während einer Reihe von Commits passiert ist, die ein Teammitglied hinzugefügt hat. +Sie können auch mehrere Optionen zur Verdichtung der Ausgabe von `git log` verwenden. +Wenn Sie beispielsweise einige gekürzte Statistiken für jeden Commit sehen möchten, können Sie die Option `--stat` verwenden: [source,console] ---- @@ -176,7 +176,7 @@ a11bef0 - Scott Chacon, 6 years ago : Initial commit | `%ce` | E-Mail-Adresse des Committers | `%cd` | Erstellungs-Datum des Committers | `%cr` | relatives Erstellungs-Datum des Committers -| `%s` | Thema +| `%s` | Thema (engl. Subject) |================================ Sie fragen sich vielleicht, worin der Unterschied zwischen _Autor_ und _Committer_ besteht. @@ -212,14 +212,14 @@ Das sind nur einige einfache Optionen zur Ausgabe-Formatierung von `git log` – [cols="1,4",options="header"] |================================ | Option | Beschreibung -| `-p` | Zeigt den Patch an, der mit den jeweiligen Commits eingefügt wurde. +| `-p` | Zeigt den Patch (bzw. Änderung) an, der mit den jeweiligen Commits eingefügt wurde. | `--stat` | Anzeige der Statistiken für Dateien, die in den einzelnen Commits geändert wurden. -| `--shortstat` | Anzeige nur der geänderten/eingefügten/gelöschten Zeile des Befehls --stat. -| `--name-only` | Listet die Dateien auf, die nach den Commit-Informationen geändert wurden. -| `--name-status` | Listet die Dateien auf, die von hinzugefügten, geänderten oder gelöschten Informationen betroffen sind. +| `--shortstat` | Anzeige der geänderten/eingefügten/gelöschten Zeilen des Befehls --stat. +| `--name-only` | Listet nach den Commit-Informationen die geänderten Dateien auf +| `--name-status` | Listet die Dateien mit hinzugefügten/geänderten/gelöschten Informationen auf. | `--abbrev-commit` | Zeigt nur die ersten paar Zeichen der SHA-1-Prüfsumme an, nicht aber alle 40. | `--relative-date` | Zeigt das Datum in einem relativen Format an (z.B. „vor 2 Wochen“), anstatt das volle Datumsformat zu verwenden. -| `--graph` | Zeigt ein ASCII-Diagramm des Branches an und verbindet die Historie mit der Log-Ausgabe. +| `--graph` | Zeigt Sie neben der Historie ein ASCII-Diagramm des Branch- und Zusammenführungsverlaufs an. | `--pretty` | Zeigt Commits in einem anderen Format an. Zu den Optionswerten gehören oneline, short, full, fuller und format (womit Sie Ihr eigenes Format angeben können). | `--oneline` | Kurzform für die gleichzeitige Verwendung von `--pretty=oneline` und `--abbrev-commit`. |================================ @@ -228,10 +228,10 @@ Das sind nur einige einfache Optionen zur Ausgabe-Formatierung von `git log` – Zusätzlich zu den Optionen für die Ausgabe-Formatierung bietet `git log` eine Reihe nützlicher einschränkender Optionen, d.h. Optionen, mit denen Sie nur eine Teilmenge von Commits anzeigen können. Sie haben eine solche Option bereits gesehen – die Option `-2`, die nur die letzten beiden Commits anzeigt. -In Wahrheit können Sie `-` verwenden, wobei `n` eine beliebige ganze Zahl ist, um die letzten `n` Commits anzuzeigen. -In der Praxis werden Sie das kaum verwenden, da Git standardmäßig alle Ausgaben über einen Pager leitet, so dass Sie jeweils nur eine Seite der Log-Ausgabe sehen. +Sie können die Option `-` verwenden, wobei `n` eine beliebige ganze Zahl ist, um die letzten `n` Commits anzuzeigen. +In der Praxis werden Sie das selten verwenden, da Git standardmäßig alle Ausgaben über einen Pager leitet, so dass Sie jeweils nur eine Seite der Log-Ausgabe sehen. -Die zeitbeschränkenden Optionen wie `--since` und `--until` sind sehr nützlich. +Im Gegensatz dazu sind zeitbeschränkenden Optionen wie `--since` und `--until` sehr nützlich. Dieser Befehl ruft z.B. die Liste der in den letzten beiden Wochen durchgeführten Commits ab: [source,console] @@ -253,14 +253,14 @@ die _allen_ `--grep` Mustern entsprechen. ==== Ein weiterer wirklich hilfreicher Filter ist die Option `-S` (umgangssprachlich als Git's „Pickel“-Option bezeichnet), die eine Zeichenkette übernimmt und nur die Commits anzeigt, die die Anzahl der Vorkommen dieses Strings geändert haben. -Wenn Sie beispielsweise das letzte Commit suchen möchten, das einen Verweis auf eine bestimmte Funktion hinzugefügt oder entfernt hat, können Sie Folgendes aufrufen: +Wenn Sie beispielsweise den letzten Commit suchen möchten, der einen Verweis auf eine bestimmte Funktion hinzugefügt oder entfernt hat, können Sie Folgendes aufrufen: [source,console] ---- $ git log -S function_name ---- -Zuletzt eine wirklich nützliche Option, die Sie als Filter an `git log` übergeben können, den Pfad. +Die letzte hier angesprochene nützliche Option, die als Filter an `git log`übergeben werden kann, ist ein Pfad. Wenn Sie ein Verzeichnis oder einen Dateinamen angeben, können Sie die Log-Ausgabe auf Commits beschränken, die eine Änderung an diesen Dateien vorgenommen haben. Das ist immer die letzte Option und wird in der Regel durch Doppelstriche (`--`) eingeleitet, um Pfade von den Optionen zu trennen. @@ -269,7 +269,7 @@ Das ist immer die letzte Option und wird in der Regel durch Doppelstriche (`--`) $ git log -- path/to/file ---- -In <> werden wir Ihnen diese und einige andere gängige Optionen als Referenz auflisten. +In <> sind diese und einige andere gängige Optionen als Referenz aufgelistet. [[limit_options]] .Optionen zum Anpassen der Ausgabe von `git log` diff --git a/ch02-git-basics-chapter.asc b/ch02-git-basics-chapter.asc index d3842b96..203034b4 100644 --- a/ch02-git-basics-chapter.asc +++ b/ch02-git-basics-chapter.asc @@ -1,8 +1,8 @@ [[ch02-git-basics-chapter]] == Git Grundlagen -Wenn Sie nur ein Kapitel durcharbeiten können/wollen, um mit Git zu beginnen, dann ist dieses hier das richtige. -Dieses Kapitel behandelt alle grundlegenden Befehle, die Sie benötigen, um die überwiegende Anzahl der Aufgaben zu erledigen, die Sie irgendwann einmal mit Git erledigen werden. +Wenn Sie nur ein Kapitel durcharbeiten wollen, um mit Git zu beginnen, dann sind sie hier richtig. +Dieses Kapitel behandelt alle grundlegenden Befehle, die Sie benötigen, um die überwiegende Anzahl der Aufgaben zu erledigen, die Sie irgendwann einmal mit Git erledigen müssen. Am Ende des Kapitels sollten Sie in der Lage sein, ein neues Repository anzulegen und zu konfigurieren, Dateien zu versionieren bzw. aus der Versionsverwaltung zu entfernen, Dateien in die Staging-Area hinzuzufügen und schließlich einen Commit durchzuführen. Außerdem wird gezeigt, wie Sie Git so konfigurieren können, dass es bestimmte Dateien und Dateimuster ignoriert, wie Sie Fehler schnell und einfach rückgängig machen, wie Sie die Historie eines Projekts durchsuchen und Änderungen zwischen Commits nachschlagen, und wie Sie von einem Remote-Repository Daten herunter- bzw. dort hochladen können. @@ -22,5 +22,5 @@ include::book/02-git-basics/sections/aliases.asc[] === Zusammenfassung -Sie sollten jetzt in der Lage sein, die wichtigsten Git-Befehle einsetzen zu können. Folgendes sollte Ihnen jetzt gelingen: Erzeugen oder Klonen eines Repositorys, Änderungen vorzunehmen und zur Staging-Area hinzuzufügen, Commits anzulegen und die Historie aller Commits in einem Repository zu durchsuchen. +Sie sollten jetzt in der Lage sein, die wichtigsten Git-Befehle einsetzen zu können. Folgendes sollte Ihnen jetzt gelingen: Erzeugen oder Klonen eines Repositories, Änderungen vorzunehmen und zur Staging-Area hinzuzufügen, Commits anzulegen und die Historie aller Commits in einem Repository zu durchsuchen. Als nächstes werden wir uns mit der „Killer-Funktion“ von Git befassen: dem Branching-Modell. From 2266aa58925b259f3303a1b1b63e806905ae5652 Mon Sep 17 00:00:00 2001 From: Oscar Santiago Date: Fri, 15 Sep 2023 08:14:26 +0200 Subject: [PATCH 2/3] remaining changes --- book/02-git-basics/sections/aliases.asc | 6 +++--- ch02-git-basics-chapter.asc | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/book/02-git-basics/sections/aliases.asc b/book/02-git-basics/sections/aliases.asc index 46c14291..f677806a 100644 --- a/book/02-git-basics/sections/aliases.asc +++ b/book/02-git-basics/sections/aliases.asc @@ -5,7 +5,7 @@ Bevor wir dieses Kapitel über Basic Git abschließen, gibt es noch einen kurzen Tipp, der Ihre Arbeit mit Git einfacher, leichter und verständlicher machen kann: Aliase. Der Klarheit halber werden wir sie nirgendwo anders in diesem Buch verwenden, aber wenn Sie Git in Zukunft regelmäßig verwenden, dann sind Aliase etwas, das Sie kennen sollten. -Git erkennt nicht automatisch Ihren Befehl, wenn Sie ihn nur teilweise eingeben. +Git erkennt nicht automatisch Ihren abgesetzten Befehl, wenn Sie ihn nur teilweise eingeben. Wenn Sie nicht den gesamten Text jedes Git-Befehls eingeben möchten, können Sie mit Hilfe von `git config` einfach ein Alias für jeden Befehl einrichten.(((Git Befehle, config))) Hier sind ein paar Beispiele, die Sie einrichten sollten: @@ -36,7 +36,7 @@ $ git unstage fileA $ git reset HEAD -- fileA ---- -Das erscheint etwas klarer. +Das macht denn Sinn des aliasing hoffentlich klarer. Es ist auch üblich, einen `last` (dt. letzten) Befehl hinzuzufügen, so wie hier: [source,console] @@ -62,7 +62,7 @@ Wie Sie feststellen können, ersetzt Git einfach den neuen Befehl durch den Alia Vielleicht möchten Sie jedoch eher einen externen Befehl als einen Git-Subbefehl ausführen. In diesem Fall starten Sie den Befehl mit einem Ausrufezeichen (`!`). Das ist hilfreich, wenn Sie Ihre eigenen Tools schreiben, die mit einem Git-Repository arbeiten. -Wir können dies demonstrieren, indem wir `git visual` mit `gitk` aliasen: +Hier ein Beispiel, in dem wir `git visual` mit `gitk` aliasen: [source,console] ---- diff --git a/ch02-git-basics-chapter.asc b/ch02-git-basics-chapter.asc index 203034b4..daada149 100644 --- a/ch02-git-basics-chapter.asc +++ b/ch02-git-basics-chapter.asc @@ -22,5 +22,5 @@ include::book/02-git-basics/sections/aliases.asc[] === Zusammenfassung -Sie sollten jetzt in der Lage sein, die wichtigsten Git-Befehle einsetzen zu können. Folgendes sollte Ihnen jetzt gelingen: Erzeugen oder Klonen eines Repositories, Änderungen vorzunehmen und zur Staging-Area hinzuzufügen, Commits anzulegen und die Historie aller Commits in einem Repository zu durchsuchen. +Sie sollten jetzt in der Lage sein, die wichtigsten Git-Befehle einsetzen zu können. Folgendes sollte Ihnen jetzt gelingen: Erzeugen oder Klonen eines Repositories, Änderungen vornehmen und zur Staging-Area hinzufügen, Commits anlegen und die Historie aller Commits in einem Repository durchsuchen. Als nächstes werden wir uns mit der „Killer-Funktion“ von Git befassen: dem Branching-Modell. From 5f2a2e9a2a28296b1d23ee0696768b92d2af6c12 Mon Sep 17 00:00:00 2001 From: Oscar Santiago Date: Fri, 15 Sep 2023 19:36:50 +0200 Subject: [PATCH 3/3] undo repositories changes --- book/02-git-basics/sections/getting-a-repository.asc | 4 ++-- book/02-git-basics/sections/recording-changes.asc | 4 ++-- book/02-git-basics/sections/remotes.asc | 10 +++++----- ch02-git-basics-chapter.asc | 2 +- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index 48a8c2bb..5265d9f5 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -56,7 +56,7 @@ Im Moment ist nur wichtig, dass Sie verstehen, dass Sie jetzt ein Git-Repository [[_git_cloning]] ==== Ein existierendes Repository klonen -Wenn Sie eine Kopie eines existierenden Git-Repositories anlegen wollen – um beispielsweise an einem Projekt mitzuarbeiten – können Sie den Befehl `git clone` verwenden. +Wenn Sie eine Kopie eines existierenden Git-Repositorys anlegen wollen – um beispielsweise an einem Projekt mitzuarbeiten – können Sie den Befehl `git clone` verwenden. Wenn Sie bereits Erfahrung mit einem anderen VCS-System, wie Subversion, gesammelt haben, fällt Ihnen bestimmt sofort auf, dass der Befehl „clone“ und nicht etwa „checkout“ lautet. Das ist ein wichtiger Unterschied, den Sie unbedingt verstehen sollten. Anstatt nur eine einfache Arbeitskopie vom Projekt zu erzeugen, lädt Git nahezu alle Daten, die der Server bereithält, auf den lokalen Rechner. Jede Version von jeder Datei der Projekt-Historie wird automatisch heruntergeladen, wenn Sie `git clone` ausführen. @@ -70,7 +70,7 @@ Um beispielsweise das Repository der verlinkbaren Git-Bibliothek `libgit2` zu kl $ git clone https://github.com/libgit2/libgit2 ---- -Git legt dann ein Verzeichnis `libgit2` an, initialisiert in diesem ein `.git` Verzeichnis, lädt alle Daten des Repositories herunter und checkt eine Arbeitskopie der aktuellsten Version aus. +Git legt dann ein Verzeichnis `libgit2` an, initialisiert in diesem ein `.git` Verzeichnis, lädt alle Daten des Repositorys herunter und checkt eine Arbeitskopie der aktuellsten Version aus. Wenn Sie in das neue `libgit2` Verzeichnis wechseln, finden Sie dort die Projektdateien und können gleich damit arbeiten. Wenn Sie das Repository in ein Verzeichnis mit einem anderen Namen als `libgit2` klonen möchten, können Sie das wie folgt durchführen: diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index c92614f7..bd64023f 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -20,7 +20,7 @@ image::images/lifecycle.png[Der Status Ihrer Dateien im Überblick] ==== Zustand von Dateien prüfen Das wichtigste Hilfsmittel, um den Zustand zu überprüfen, in dem sich Ihre Dateien gerade befinden, ist der Befehl `git status`.(((Git Befehle, status))) -Wenn Sie diesen Befehl unmittelbar nach dem Klonen eines Repositories ausführen, sollte er in etwa folgende Ausgabe liefern: +Wenn Sie diesen Befehl unmittelbar nach dem Klonen eines Repositorys ausführen, sollte er in etwa folgende Ausgabe liefern: [source,console] ---- @@ -39,7 +39,7 @@ Wir werden im Kapitel <> au [NOTE] ==== GitHub änderte Mitte 2020 den Standard-Branch-Namen von `master` in `main`, und andere Git-Hosts folgten diesem Beispiel. -Daher werden Sie möglicherweise feststellen, dass der Standard-Branch-Name in einigen neu erstellten Repositories `main` und nicht `master` ist. +Daher werden Sie möglicherweise feststellen, dass der Standard-Branch-Name in einigen neu erstellten Repositorys `main` und nicht `master` ist. Außerdem kann der Standard-Branch-Name geändert werden (wie Sie in <> gesehen haben), sodass Sie möglicherweise einen anderen Namen für den Standard-Branch vorfinden. Git selbst verwendet jedoch immer noch `master` als Standard, also werden wir es auch im gesamten Buch verwenden. diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 743eb3af..2d0a20eb 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -1,15 +1,15 @@ [[_remote_repos]] === Mit Remotes arbeiten -Um an Git-Projekte mitarbeiten zu können, müssen Sie wissen, wie Sie Remote-Repositories verwalten können. -Remote-Repositories sind Versionen Ihres Projekts, die im Internet oder im Netzwerk irgendwo gehostet werden. +Um an Git-Projekte mitarbeiten zu können, müssen Sie wissen, wie Sie Remote-Repositorys verwalten können. +Remote-Repositorys sind Versionen Ihres Projekts, die im Internet oder im Netzwerk irgendwo gehostet werden. Sie können mehrere einrichten, von denen jedes in der Regel entweder schreibgeschützt oder beschreibbar für Sie ist. -Die Zusammenarbeit mit anderen erfordert die Verwaltung dieser Remote-Repositories sowie das Pushing und Pulling von Daten zu und von den Repositories, wenn Sie Ihre Arbeit teilen möchten. -Die Verwaltung von Remote-Repositories umfasst das Wissen, wie man entfernte Repositories hinzufügt, nicht mehr gültige Remotes entfernt, verschiedene Remote-Branches verwaltet, sie als versioniert oder nicht versioniert definiert und vieles mehr. +Die Zusammenarbeit mit anderen erfordert die Verwaltung dieser Remote-Repositorys sowie das Pushing und Pulling von Daten zu und von den Repositorys, wenn Sie Ihre Arbeit teilen möchten. +Die Verwaltung von Remote-Repositorys umfasst das Wissen, wie man entfernte Repositorys hinzufügt, nicht mehr gültige Remotes entfernt, verschiedene Remote-Branches verwaltet, sie als versioniert oder nicht versioniert definiert und vieles mehr. In diesem Abschnitt werden wir einige dieser Remote-Management-Fertigkeiten erörtern. [NOTE] -.Remote-Repositories können auch auf Ihrem lokalen Rechner liegen. +.Remote-Repositorys können auch auf Ihrem lokalen Rechner liegen. ==== Es ist durchaus möglich, dass Sie mit einem „entfernten“ Repository arbeiten können, das sich tatsächlich auf demselben Host befindet auf dem Sie gerade arbeiten. Das Wort „remote“ bedeutet nicht unbedingt, dass sich das Repository an einem anderen Ort im Netzwerk oder Internet befindet, sondern nur, dass es an einem anderen Ort liegt. diff --git a/ch02-git-basics-chapter.asc b/ch02-git-basics-chapter.asc index daada149..f379882d 100644 --- a/ch02-git-basics-chapter.asc +++ b/ch02-git-basics-chapter.asc @@ -22,5 +22,5 @@ include::book/02-git-basics/sections/aliases.asc[] === Zusammenfassung -Sie sollten jetzt in der Lage sein, die wichtigsten Git-Befehle einsetzen zu können. Folgendes sollte Ihnen jetzt gelingen: Erzeugen oder Klonen eines Repositories, Änderungen vornehmen und zur Staging-Area hinzufügen, Commits anlegen und die Historie aller Commits in einem Repository durchsuchen. +Sie sollten jetzt in der Lage sein, die wichtigsten Git-Befehle einsetzen zu können. Folgendes sollte Ihnen jetzt gelingen: Erzeugen oder Klonen eines Repositorys, Änderungen vornehmen und zur Staging-Area hinzufügen, Commits anlegen und die Historie aller Commits in einem Repository durchsuchen. Als nächstes werden wir uns mit der „Killer-Funktion“ von Git befassen: dem Branching-Modell.