diff --git a/book/02-git-basics/sections/aliases.asc b/book/02-git-basics/sections/aliases.asc index f677806a..37c84e1f 100644 --- a/book/02-git-basics/sections/aliases.asc +++ b/book/02-git-basics/sections/aliases.asc @@ -2,12 +2,12 @@ === Git Aliases (((Aliasnamen))) -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. +Bevor wir dieses Kapitel über Basic Git abschließen, gibt es noch einen kurzen Tipp, der deine 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 du Git in Zukunft regelmäßig verwendest, dann sind Aliase etwas, das du kennen solltest. -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: +Git erkennt nicht automatisch deinen abgesetzten Befehl, wenn du ihn nur teilweise eingibst. +Wenn du nicht den gesamten Text jedes Git-Befehls eingeben möchtest, könntest du mit Hilfe von `git config` einfach ein Alias für jeden Befehl einrichten.(((Git Befehle, config))) +Hier sind ein paar Beispiele, die du einrichten sollten: [source,console] ---- @@ -17,11 +17,11 @@ $ git config --global alias.ci commit $ git config --global alias.st status ---- -Das bedeutet, dass Sie z.B. anstelle von `git commit` einfach `git ci` eingeben können. -Wenn Sie Git nun weiter verwenden, werden Sie vermutlich auch andere Befehle häufig verwenden; scheuen Sie sich nicht, neue Aliase zu erstellen. +Das bedeutet, dass du z.B. anstelle von `git commit` einfach `git ci` eingeben kannst. +Je mehr du Git verwendest, wirst du vermutlich noch andere Befehle häufiger verwenden; scheue dich nicht, neue Aliase zu erstellen. -Diese Technik kann auch sehr nützlich sein, um Befehle zu erstellen, von denen Sie glauben, dass sie vorhanden sein sollten. -Um beispielsweise ein Usability-Problem zu beheben, auf das Sie beim Entfernen einer Datei aus der Staging-Area stoßen, können Sie Git Ihren eigenen Unstage-Alias hinzufügen: +Diese Technik kann auch sehr nützlich sein, um Befehle zu erstellen, von denen du glaubst, dass sie vorhanden sein sollten. +Um beispielsweise ein Usability-Problem zu beheben, auf das du beim Entfernen einer Datei aus der Staging-Area stößt, kannst du Git deinen eigenen Unstage-Alias hinzufügen: [source,console] ---- @@ -44,7 +44,7 @@ Es ist auch üblich, einen `last` (dt. letzten) Befehl hinzuzufügen, so wie hie $ git config --global alias.last 'log -1 HEAD' ---- -Auf diese Weise können Sie den letzten Commit leicht auffinden: +Auf diese Weise kannst du den letzten Commit leicht auffinden: [source,console] ---- @@ -58,10 +58,10 @@ Date: Tue Aug 26 19:48:51 2008 +0800 Signed-off-by: Scott Chacon ---- -Wie Sie feststellen können, ersetzt Git einfach den neuen Befehl durch den Alias, für den Sie ihn verwenden. -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. +Wie du siehst, ersetzt Git den neuen Befehl einfach durch den Alias, den du ihn geben hast. +Vielleicht möchtest du jedoch eher einen externen Befehl als einen Git-Subbefehl ausführen. +In diesem Fall starte den Befehl mit einem Ausrufezeichen (`!`). +Das ist hilfreich, wenn du deine eigenen Tools schreibst, die mit einem Git-Repository arbeiten. Hier ein Beispiel, in dem 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 5265d9f5..db44478c 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -1,17 +1,17 @@ [[_getting_a_repo]] === Ein Git-Repository anlegen -Sie haben zwei Möglichkeiten, ein Git-Repository auf Ihrem Rechner anzulegen. +Du hast zwei Möglichkeiten, ein Git-Repository auf Deinem Rechner anzulegen. -1. Sie können ein lokales Verzeichnis, das sich derzeit nicht unter Versionskontrolle befindet, in ein Git-Repository verwandeln, oder -2. Sie können ein bestehendes Git-Repository von einem anderen Ort aus _klonen_. +1. Du kannst ein lokales Verzeichnis, das sich derzeit nicht unter Versionskontrolle befindet, in ein Git-Repository verwandeln, oder +2. Du kannst ein bestehendes Git-Repository von einem anderen Ort aus _klonen_. -In beiden Fällen erhalten Sie ein einsatzbereites Git-Repository auf Ihrem lokalen Rechner. +In beiden Fällen erhältst Du ein einsatzbereites Git-Repository auf Deinem lokalen Rechner. ==== Ein Repository in einem bestehenden Verzeichnis einrichten -Wenn Sie ein Projektverzeichnis haben, das sich derzeit nicht unter Versionskontrolle befindet, und Sie mit der Kontrolle über Git beginnen möchten, müssen Sie zunächst in das Verzeichnis dieses Projekts wechseln. -Wenn Sie dies noch nie getan haben, sieht es je nachdem, welches System Sie verwenden, etwas anders aus: +Wenn Du ein Projektverzeichnis hast, das sich derzeit nicht unter Versionskontrolle befindet, und Du mit dessen Versionierung über Git beginnen möchten, musst Du zunächst in das Verzeichnis dieses Projekts wechseln. +Das sieht je nachdem, welches System verwendet wird, unterschiedlich aus: für Linux: [source,console] @@ -29,19 +29,20 @@ für Windows: $ cd C:/Users/user/my_project ---- -Führen Sie dort folgenden Befehl aus: +Führe dort folgenden Befehl aus: [source,console] ---- $ git init ---- -Der Befehl erzeugt ein Unterverzeichnis `.git`, in dem alle relevanten Git-Repository-Daten enthalten sind, also ein Git-Repository Grundgerüst. +Der Befehl erzeugt ein Unterverzeichnis `.git`, in dem alle relevanten Git-Repository-Daten enthalten sind, also so etwas wie ein Git-Repository Grundgerüst. Zu diesem Zeitpunkt werden noch keine Dateien in Git versioniert. -In Kapitel 10, <>, finden Sie weitere Informationen, welche Dateien im `.git` Verzeichnis enthalten sind und was ihre Aufgabe ist.(((Git Befehle, init))) +In Kapitel 10, <>, findest Du weitere Informationen, welche Dateien im `.git` Verzeichnis erzeugt wurden.(((Git Befehle, init))) -Wenn Sie bereits existierende Dateien versionieren möchten (und es sich nicht nur um ein leeres Verzeichnis handelt), dann sollten Sie den aktuellen Stand in einem initialen Commit starten. -Mit dem Befehl `git add` legen Sie fest, welche Dateien versioniert werden sollen und mit dem Befehl `git commit` erzeugen Sie einen neuen Commit: +Wenn Du bereits existierende Dateien versionieren möchtest (und es sich nicht nur um ein leeres Verzeichnis handelt), dann solltest Du den aktuellen Stand mit einem initialen Commit tracken. +Mit dem Befehl `git add` legst Du fest, welche Dateien versioniert werden sollen und mit dem Befehl `git commit` erzeugst Du einen neuen Commit: +Du kannst dies mit ein paar `git add`-Befehlen erreichen. Damit markierst du die zu trackende Dateien. Anschließend gibst du ein `git commit` ein: [source,console] ---- @@ -51,29 +52,29 @@ $ git commit -m 'Initial project version' ---- Wir werden gleich noch einmal genauer auf diese Befehle eingehen. -Im Moment ist nur wichtig, dass Sie verstehen, dass Sie jetzt ein Git-Repository erzeugt und einen ersten Commit angelegt haben. +Im Moment ist nur wichtig zu verstehen, dass du jetzt ein Git-Repository erzeugt und einen ersten Commit angelegt hast. [[_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 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 versionierte Daten wären vorhanden – siehe Kapitel 4, <>, für weitere Details.) +Wenn du eine Kopie eines existierenden Git-Repositorys anlegen möchtest – um beispielsweise an einem Projekt mitzuarbeiten – kannst du den Befehl `git clone` verwenden. +Wenn du bereits Erfahrung mit einem anderen VCS-System wie Subversion gesammelt hast, fällt dir bestimmt sofort auf, dass der Befehl „clone“ und nicht etwa „checkout“ lautet. +Das ist ein wichtiger Unterschied, den du unbedingt verstehen solltest. 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 du `git clone` ausführst. +Wenn deine Serverfestplatte beschädigt wird, kannst du 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. (Du wirst 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: +Du klonst ein Repository mit dem Befehl `git clone [url]`.(((Git Befehle, clone))) +Um beispielsweise das Repository der verlinkbaren Git-Bibliothek `libgit2` zu klonen, führst du folgenden Befehl aus: [source,console] ---- $ 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. -Wenn Sie in das neue `libgit2` Verzeichnis wechseln, finden Sie dort die Projektdateien und können gleich damit arbeiten. +Git legt dann ein Verzeichnis `libgit2` an, initialisiert in diesem ein `.git` Verzeichnis, lädt alle Daten des Repositorys herunter und checkt eine Kopie der aktuellsten Version aus. +Wenn du in das neue `libgit2` Verzeichnis wechselst, findest du dort die Projektdateien und kannst 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: +Wenn du das Repository in ein Verzeichnis mit einem anderen Namen als `libgit2` klonen möchtest, kannst du das wie folgt durchführen: [source,console] ---- @@ -83,5 +84,5 @@ $ git clone https://github.com/libgit2/libgit2 mylibgit Dieser Befehl tut das Gleiche wie der vorhergehende, aber das Zielverzeichnis lautet diesmal `mylibgit`. 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 möglichen Optionen. +Das vorhergehende Beispiel verwendet das `https://` Protokoll, aber dir könnten 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 dein 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 bd64023f..a68955ed 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -1,17 +1,17 @@ === Änderungen nachverfolgen und im Repository speichern -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. +An dieser Stelle solltest du ein _angemessenes_ Git-Repository auf deinem lokalen Computer und eine Checkout- oder Arbeitskopie aller deiner Dateien vor dir haben. +Normalerweise wirst du damit beginnen wollen, Änderungen vorzunehmen und Schnappschüsse dieser Änderungen in dein Repository zu committen, wenn das Projekt so weit fortgeschritten ist, dass du 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_). +Denke daran, dass sich jede Datei in deinem 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. Kurz gesagt, nachverfolgte Dateien sind Dateien, die Git kennt. -Alle anderen Dateien in Ihrem Arbeitsverzeichnis dagegen, sind nicht versioniert: das sind all diejenigen Dateien, die nicht schon im letzten Schnappschuss enthalten waren und die sich nicht in der Staging-Area befinden. -Wenn Sie ein Repository zum ersten Mal klonen, sind alle Dateien versioniert und unverändert. Nach dem Klonen wurden sie ja ausgecheckt und bis dahin haben Sie auch noch nichts an ihnen verändert. +Alle anderen Dateien in deinem Arbeitsverzeichnis dagegen, sind nicht versioniert: Das sind all diejenigen Dateien, die nicht schon im letzten Schnappschuss enthalten waren und die sich nicht in der Staging-Area befinden. +Wenn du ein Repository zum ersten Mal klonst, sind alle Dateien versioniert und unverändert. Nach dem Klonen wurden sie ja ausgecheckt und bis dahin hast du auch noch nichts an ihnen verändert. -Sobald Sie anfangen, versionierte Dateien zu bearbeiten, erkennt Git diese als modifiziert, weil sie sich im Vergleich zum letzten Commit verändert haben. -Die geänderten Dateien können Sie dann für den nächsten Commit vormerken und schließlich alle Änderungen, die sich in der Staging-Area befinden, einchecken/committen. Danach wiederholt sich der Zyklus. +Sobald du anfängst versionierte Dateien zu bearbeiten, erkennt Git diese als modifiziert, weil sie sich im Vergleich zum letzten Commit verändert haben. +Die geänderten Dateien kannst du dann für den nächsten Commit vormerken und schließlich alle Änderungen, die sich in der Staging-Area befinden, einchecken (engl. committen). Danach wiederholt sich dieser Vorgang. .Der Status Ihrer Dateien im Überblick image::images/lifecycle.png[Der Status Ihrer Dateien im Überblick] @@ -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 du diesen Befehl unmittelbar nach dem Klonen eines Repositorys ausführen, sollte er in etwa folgende Ausgabe liefern: [source,console] ---- @@ -32,21 +32,21 @@ nothing to commit, working tree clean Dieser Zustand wird auch als sauberes Arbeitsverzeichnis (engl. clean working directory) bezeichnet. Mit anderen Worten, es gibt keine Dateien, die unter Versionsverwaltung stehen und seit dem letzten Commit geändert wurden – andernfalls würden sie hier aufgelistet werden. -Außerdem teilt Ihnen der Befehl mit, auf welchem Branch Sie gerade arbeiten und informiert Sie darüber, dass dieser sich im Vergleich zum Branch auf dem Server nicht verändert hat. -Momentan ist dieser Zweig immer `master`, was der Vorgabe entspricht; Sie müssen sich jetzt nicht darum kümmern. -Wir werden im Kapitel <> auf Branches detailliert eingehen. +Außerdem teilt dir der Befehl mit, auf welchem Branch du gerade arbeitest und informiert dich darüber, dass dieser sich im Vergleich zum Branch auf dem Server nicht verändert hat. +Momentan ist dieser Zweig immer `master`, was der Vorgabe entspricht; Du musst dich jetzt nicht darum kümmern. +Wir werden im Kapitel <> detaillierter auf Branches eingehen. [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 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. +Daher wirst du 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 du in <> gesehen hast), sodass du möglicherweise einen anderen Namen für den Standard-Branch vorfindest. 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. -Wenn die Datei zuvor nicht existiert hat und Sie jetzt `git status` ausführen, zeigt Git die bisher nicht versionierte Datei wie folgt an: +Nehmen wir einmal an, du fügst eine neue Datei mit dem Namen `README` zu deinem Projekt hinzu. +Wenn die Datei zuvor nicht existiert hat und du jetzt `git status` ausführst, zeigt Git die bisher nicht versionierte Datei wie folgt an: [source,console] ---- @@ -63,22 +63,22 @@ nothing added to commit but untracked files present (use "git add" to track) ---- Alle Dateien, die im Abschnitt „Untracked files“ aufgelistet werden, sind Dateien, die bisher noch nicht versioniert sind. Dort wird jetzt auch die Datei `README` angezeigt. -Mit anderen Worten, die Datei README wird in diesem Bereich gelistet, weil sie im letzten Schnappschuss nicht enthalten war und noch nicht gestaged wurde. Git nimmt eine solche Datei nicht automatisch in die Versionsverwaltung auf, sondern Sie müssen Git dazu ausdrücklich auffordern. -Ansonsten würden generierte Binärdateien oder andere Dateien, die Sie nicht in Ihrem Repository haben möchten, automatisch hinzugefügt werden. Das möchte man in den meisten Fällen vermeiden. +Mit anderen Worten, die Datei README wird in diesem Bereich gelistet, weil sie im letzten Schnappschuss nicht enthalten war und noch nicht gestaged wurde. Git nimmt eine solche Datei nicht automatisch in die Versionsverwaltung auf. Du musst Git dazu ausdrücklich auffordern. +Ansonsten würden generierte Binärdateien oder andere Dateien, die du nicht in deinem Repository haben möchtest, automatisch hinzugefügt werden. Das möchte man in den meisten Fällen vermeiden. Jetzt wollen wir aber Änderungen an der Datei `README` verfolgen und fügen sie deshalb zur Versionsverwaltung hinzu. [[_tracking_files]] ==== Neue Dateien zur Versionsverwaltung hinzufügen -Um eine neue Datei zu versionieren, können Sie den Befehl `git add` verwenden.(((Git Befehle, add))) -Für Ihre neue `README` Datei, können Sie folgendes ausführen: +Um eine neue Datei zu versionieren, kannst du den Befehl `git add` verwenden.(((Git Befehle, add))) +Für deine neue `README` Datei, kannst du folgendes ausführen: [source,console] ---- $ git add README ---- -Wenn Sie erneut den Befehl `git status` ausführen, werden Sie sehen, dass sich Ihre `README` Datei jetzt unter Versionsverwaltung befindet und für den nächsten Commit vorgemerkt ist: +Wenn du erneut den Befehl `git status` ausführst, wirst du sehen, dass sich deine `README` Datei jetzt unter Versionsverwaltung befindet und für den nächsten Commit vorgemerkt ist: [source,console] ---- @@ -92,15 +92,15 @@ Changes to be committed: ---- -Sie können erkennen, dass die Datei für den nächsten Commit vorgemerkt ist, weil sie unter der Rubrik „Changes to be committed“ aufgelistet ist. -Wenn Sie jetzt einen Commit anlegen, wird der Schnappschuss den Zustand der Datei festhalten, den sie zum Zeitpunkt des Befehls `git add` hat. -Sie erinnern sich vielleicht daran, wie Sie vorhin `git init` und anschließend `git add ` ausgeführt haben. Mit diesen Befehlen haben Sie die Dateien in Ihrem Verzeichnis zur Versionsverwaltung hinzugefügt.(((Git Befehle, init)))(((Git Befehle, add))) -Der Befehl `git add` akzeptiert einen Pfadnamen einer Datei oder eines Verzeichnisses. Wenn Sie ein Verzeichnis angeben, fügt `git add` alle Dateien in diesem Verzeichnis und allen Unterverzeichnissen rekursiv hinzu. +Du kannst erkennen, dass die Datei für den nächsten Commit vorgemerkt ist, weil sie unter der Rubrik „Changes to be committed“ aufgelistet ist. +Wenn du jetzt einen Commit anlegst, wird der Schnappschuss den Zustand der Datei festhalten, den sie zum Zeitpunkt des Befehls `git add` hat. +Du erinnerst dich vielleicht daran, wie du vorhin `git init` und anschließend `git add ` ausgeführt hast. Mit diesen Befehlen hast du die Dateien in deinem Verzeichnis zur Versionsverwaltung hinzugefügt.(((Git Befehle, init)))(((Git Befehle, add))) +Der Befehl `git add` akzeptiert einen Pfadnamen einer Datei oder eines Verzeichnisses. Wenn du ein Verzeichnis angibst, fügt `git add` alle Dateien in diesem Verzeichnis und allen Unterverzeichnissen rekursiv hinzu. ==== Geänderte Dateien zur Staging-Area hinzufügen -Lassen Sie uns jetzt eine bereits versionierte Datei ändern. -Wenn Sie zum Beispiel eine bereits unter Versionsverwaltung stehende Datei mit dem Dateinamen `CONTRIBUTING.md` ändern und danach den Befehl `git status` erneut ausführen, erhalten Sie in etwa folgende Ausgabe: +Las uns jetzt eine bereits versionierte Datei ändern. +Wenn du zum Beispiel eine bereits unter Versionsverwaltung stehende Datei mit dem Dateinamen `CONTRIBUTING.md` änderst und danach den Befehl `git status` erneut ausführst, erhältst du in etwa folgende Ausgabe: [source,console] ---- @@ -121,10 +121,10 @@ Changes not staged for commit: ---- Die Datei `CONTRIBUTING.md` erscheint im Abschnitt „Changes not staged for commit“. Das bedeutet, dass eine versionierte Datei im Arbeitsverzeichnis verändert worden ist, aber noch nicht für den Commit vorgemerkt wurde. -Um sie vorzumerken, führen Sie den Befehl `git add` aus. +Um sie vorzumerken, führst du den Befehl `git add` aus. Der Befehl `git add` wird zu vielen verschiedenen Zwecken eingesetzt. Man verwendet ihn, um neue Dateien zur Versionsverwaltung hinzuzufügen, Dateien für einen Commit vorzumerken und verschiedene andere Dinge – beispielsweise einen Konflikt aus einem Merge als aufgelöst zu kennzeichnen. -Leider wird der Befehl `git add` oft missverstanden. Viele assoziieren damit, dass damit Dateien zum Projekt hinzugefügt werden. Wie Sie aber gerade gelernt haben, wird der Befehl auch noch für viele andere Dinge eingesetzt. Wenn Sie den Befehl `git add` einsetzen, sollten Sie das eher so sehen, dass Sie damit einen bestimmten Inhalt für den nächsten Commit vormerken.(((Git Befehle, add))) -Lassen Sie uns nun mit `git add` die Datei `CONTRIBUTING.md` zur Staging-Area hinzufügen und danach das Ergebnis mit `git status` kontrollieren: +Leider wird der Befehl `git add` oft missverstanden. Viele assoziieren damit, dass damit Dateien zum Projekt hinzugefügt werden. Wie du aber gerade gelernt hast, wird der Befehl auch noch für viele andere Dinge eingesetzt. Wenn du den Befehl `git add` einsetzt, solltest du das eher so sehen, dass du damit einen bestimmten Inhalt für den nächsten Commit vormerkst.(((Git Befehle, add))) +Las uns nun mit `git add` die Datei `CONTRIBUTING.md` zur Staging-Area hinzufügen und danach das Ergebnis mit `git status` kontrollieren: [source,console] ---- @@ -141,9 +141,9 @@ Changes to be committed: ---- Beide Dateien sind nun für den nächsten Commit vorgemerkt. -Nehmen wir an, Sie wollen jetzt aber noch eine weitere Änderung an der Datei `CONTRIBUTING.md` vornehmen, bevor Sie den Commit tatsächlich starten. -Sie öffnen die Datei erneut, ändern sie entsprechend ab und eigentlich wären Sie ja jetzt bereit den Commit durchzuführen. -Allerdings lassen Sie uns vorher noch einmal den Befehl `git status` ausführen: +Nehmen wir an, du willst jetzt aber noch eine weitere Änderung an der Datei `CONTRIBUTING.md` vornehmen, bevor du den Commit tatsächlich startest. +Du öffnest die Datei erneut, änderst sie entsprechend ab und eigentlich wärst du jetzt bereit den Commit durchzuführen. +Las uns vorher noch einmal den Befehl `git status` ausführen: [source,console] ---- @@ -168,9 +168,9 @@ Changes not staged for commit: Was zum Kuckuck ...? Jetzt wird die Datei `CONTRIBUTING.md` sowohl in der Staging-Area als auch als geändert aufgelistet. Wie ist das möglich? -Die Erklärung dafür ist, dass Git eine Datei in exakt dem Zustand für den Commit vormerkt, in dem sie sich befindet, wenn Sie den Befehl `git add` ausführen. -Wenn Sie den Commit jetzt anlegen, wird die Version der Datei `CONTRIBUTING.md` denjenigen Inhalt haben, den sie hatte, als Sie `git add` zuletzt ausgeführt haben und nicht denjenigen, den sie in dem Moment hat, wenn Sie den Befehl `git commit` ausführen. -Wenn Sie stattdessen die gegenwärtige Version im Commit haben möchten, müssen Sie erneut `git add` ausführen, um die Datei der Staging-Area hinzuzufügen: +Die Erklärung dafür ist, dass Git eine Datei in exakt dem Zustand für den Commit vormerkt, in dem sie sich befindet, wenn du den Befehl `git add` ausführst. +Wenn du den Commit jetzt anlegst, wird die Version der Datei `CONTRIBUTING.md` denjenigen Inhalt haben, den sie hatte, als du `git add` zuletzt ausgeführt hast und nicht denjenigen, den sie in dem Moment hat, wenn du den Befehl `git commit` ausführst. +Wenn du stattdessen die gegenwärtige Version im Commit haben möchten, müsst du erneut `git add` ausführen, um die Datei der Staging-Area hinzuzufügen: [source,console] ---- @@ -188,8 +188,8 @@ Changes to be committed: ==== Kompakter Status Die Ausgabe von `git status` ist sehr umfassend und auch ziemlich wortreich. -Git hat auch ein Kurzformat, mit dem Sie Ihre Änderungen kompakter sehen können. -Wenn Sie `git status -s` oder `git status --short` ausführen, erhalten Sie eine kürzere Darstellung des Befehls: +Git hat auch ein Kurzformat, mit dem du deine Änderungen kompakter sehen kannst. +Wenn du `git status -s` oder `git status --short` ausführst, erhältst du eine kürzere Darstellung des Befehls: [source,console] ---- @@ -201,8 +201,8 @@ M lib/simplegit.rb ?? LICENSE.txt ---- -Neue Dateien, die nicht versioniert werden, haben `??` neben sich, neue Dateien, die der Staging-Area hinzugefügt wurden, haben ein `A`, geänderte Dateien haben ein `M` usw. -Es gibt zwei Spalten für die Ausgabe – die linke Spalte zeigt den Status der Staging-Area und die rechte Spalte den Status des Verzeichnisbaums. +Neue Dateien, die nicht versioniert werden, werden mit `??` markiert. Neue Dateien, die der Staging-Area hinzugefügt wurden, haben ein `A`, geänderte Dateien haben ein `M` usw. +Es gibt zwei Spalten für die Ausgabe – die linke Spalte zeigt den Status der Staging-Area und die rechte Spalte den Status des Arbeitsverzeichnis. So ist beispielsweise in der Bildschirmausgabe oben die Datei `README` im Arbeitsverzeichnis geändert, aber noch nicht staged, während die Datei `lib/simplegit.rb` geändert und staged ist. Das `Rakefile` wurde modifiziert, staged und dann wieder modifiziert, so dass es Änderungen an ihm gibt, die sowohl staged als auch unstaged sind. @@ -211,7 +211,7 @@ Das `Rakefile` wurde modifiziert, staged und dann wieder modifiziert, so dass es Häufig gibt es eine Reihe von Dateien, die Git nicht automatisch hinzufügen oder schon gar nicht als „nicht versioniert“ (eng. untracked) anzeigen soll. Dazu gehören in der Regel automatisch generierte Dateien, wie Log-Dateien oder Dateien, die von Ihrem Build-System erzeugt werden. -In solchen Fällen können Sie die Datei `.gitignore` erstellen, die eine Liste mit Vergleichsmustern enthält.(((ignorieren von Dateien)))(((Dateien, ignorieren))) +In solchen Fällen kannst du die Datei `.gitignore` erstellen, die eine Liste mit Vergleichsmustern enthält.(((ignorieren von Dateien)))(((Dateien, ignorieren))) Hier ist eine `.gitignore` Beispieldatei: [source,console] @@ -221,22 +221,22 @@ $ cat .gitignore *~ ---- -Die erste Zeile weist Git an, alle Dateien zu ignorieren, die auf „.o“ oder „.a“ enden – Objekt- und Archivdateien, die das Ergebnis der Codegenerierung sein könnten. +Die erste Zeile weist Git an, alle Dateien zu ignorieren, die auf „.o“ oder „.a“ enden – Objekt- und Archivdateien, die das Ergebnis einer Codegenerierung sein könnten. Die zweite Zeile weist Git an, alle Dateien zu ignorieren, deren Name mit einer Tilde (`~`) enden, was von vielen Texteditoren wie Emacs zum Markieren temporärer Dateien verwendet wird. -Sie können auch ein Verzeichnis „log“, „tmp“ oder „pid“ hinzufügen, eine automatisch generierte Dokumentation usw. -Es ist im Allgemeinen eine gute Idee, die `.gitignore` Datei für Ihr neues Repository einzurichten, noch bevor Sie loslegen. So können Sie nicht versehentlich Dateien committen, die Sie wirklich nicht in Ihrem Git-Repository haben möchten. +Du kannst auch ein Verzeichnis „log“, „tmp“ oder „pid“ hinzufügen, eine automatisch generierte Dokumentation usw. +Es ist im Allgemeinen eine gute Idee, die `.gitignore` Datei für dein neues Repository einzurichten, noch bevor du loslegen. So kannst du nicht versehentlich Dateien committen, die du nicht in deinem Git-Repository haben möchtest. -Die Richtlinien für Vergleichsmuster, die Sie in der Datei `.gitignore` eingeben können, lauten wie folgt: +Die Richtlinien für Vergleichsmuster, die du in der Datei `.gitignore` eingeben kannst, lautet wie folgt: * Leerzeilen oder Zeilen, die mit `#` beginnen, werden ignoriert. * Standard-Platzhalter-Zeichen funktionieren und werden rekursiv im gesamten Verzeichnisbaum angewendet. -* Sie können Vergleichsmuster mit einem Schrägstrich (`/`) **beginnen**, um die Rekursivität zu verhindern. -* Sie können Vergleichsmuster mit einem Schrägstrich (`/`) **beenden**, um ein Verzeichnis anzugeben. -* Sie können ein Vergleichsmuster verbieten, indem Sie es mit einem Ausrufezeichen (`!`) beginnen. +* Du kannst Vergleichsmuster mit einem Schrägstrich (`/`) **beginnen**, um die Rekursivität zu verhindern. +* Du kannst Vergleichsmuster mit einem Schrägstrich (`/`) **beenden**, um ein Verzeichnis anzugeben. +* Du kannst ein Vergleichsmuster negieren, indem es mit einem Ausrufezeichen (`!`) beginnt. Platzhalter-Zeichen sind wie einfache, reguläre Ausdrücke, die von der Shell genutzt werden. Ein Sternchen (`\*`) entspricht null oder mehr Zeichen; `[abc]` entspricht jedem Zeichen innerhalb der eckigen Klammern (in diesem Fall a, b oder c); ein Fragezeichen (`?`) entspricht einem einzelnen Zeichen und eckige Klammern, die durch einen Bindestrich (`[0-9]`) getrennte Zeichen einschließen, passen zu jedem Zeichen dazwischen (in diesem Fall von 0 bis 9). -Sie können auch zwei Sterne verwenden, um verschachtelte Verzeichnisse abzugleichen; `a/**/z` würde zu `a/z`, `a/b/z`, `a/b/c/z` usw. passen. +Du kannst auch zwei Sterne verwenden, um verschachtelte Verzeichnisse abzugleichen; `a/**/z` würde zu `a/z`, `a/b/z`, `a/b/c/z` usw. passen. Hier ist eine weitere `.gitignore` Beispieldatei: @@ -263,7 +263,7 @@ doc/**/*.pdf [TIP] ==== -GitHub unterhält eine ziemlich umfassende Liste guter `.gitignore` Beispiel-Dateien für Dutzende von Projekten und Sprachen auf https://github.com/github/gitignore[^], falls Sie einen Ansatzpunkt für Ihr Projekt suchen. +GitHub unterhält eine ziemlich umfassende Liste guter `.gitignore` Beispiel-Dateien für Dutzende von Projekten und Sprachen auf https://github.com/github/gitignore[^], falls du einen Ansatzpunkt für dein Projekt suchst. ==== [NOTE] @@ -279,13 +279,13 @@ Es würde den Rahmen dieses Buches sprengen, detaillierter auf den Einsatz mehre [[_git_diff_staged]] ==== Überprüfen der Staged- und Unstaged-Änderungen -Wenn der Befehl `git status` für Sie zu vage ist – Sie wollen genau wissen, *was* Sie geändert haben, nicht nur welche Dateien geändert wurden – können Sie den Befehl `git diff` verwenden.(((Git Befehle, diff))) -Wir werden `git diff` später ausführlicher behandeln, aber Sie werden es wahrscheinlich am häufigsten verwenden, um diese beiden Fragen zu beantworten: Was hat sich geändert, ist aber noch nicht zum Commit vorgemerkt (engl. staged)? -Und was haben Sie zum Commit vorgemerkt und können es demnächst committen? -Der Befehl `git status` beantwortet diese Fragen ganz allgemein, indem er die Dateinamen auflistet; `git diff` zeigt Ihnen aber genau die hinzugefügten und entfernten Zeilen – sozusagen den Patch. +Wenn der Befehl `git status` zu wage für dich ist und du genau wissen willst, *was* du geändert hast, kannst du den Befehl `git diff` verwenden.(((Git Befehle, diff))) +Wir werden `git diff` später ausführlicher behandeln, aber du wirst es wahrscheinlich oft verwenden, um dir diese beiden Fragen zu beantworten: Was hat sich geändert, ist aber noch nicht zum Commit vorgemerkt (engl. staged)? +Was hast du zum Commit vorgemerkt und wird demnächst committet? +Der Befehl `git status` beantwortet diese Fragen ganz allgemein, indem er die Dateinamen auflistet; `git diff` zeigt dir aber genau die hinzugefügten und entfernten Zeilen – sozusagen den aktuellen Patch. -Nehmen wir an, Sie bearbeiten und merken die Datei `README` zum Commit vor (engl. stage) und bearbeiten dann die Datei `CONTRIBUTING.md`, ohne sie zu „stagen“. -Wenn Sie den Befehl `git status` ausführen, sehen Sie erneut so etwas wie das hier: +Nehmen wir an, du bearbeitest und stagst die Datei `README` nochmal und bearbeitest dann die Datei `CONTRIBUTING.md`, ohne sie zu stagen. +Wenn du den Befehl `git status` ausführst, siehst du erneut so etwas: [source,console] ---- @@ -304,7 +304,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -Um die Änderungen zu sehen, die Sie noch nicht zum Commit vorgemerkt haben, geben Sie den Befehl `git diff`, ohne weitere Argumente, ein: +Um die Änderungen zu sehen, die du noch nicht zum Commit vorgemerkt hast, gibst du den Befehl `git diff` ohne weitere Argumente, ein: [source,console] ---- @@ -326,10 +326,10 @@ index 8ebb991..643e24f 100644 ---- Dieses Kommando vergleicht, was sich in Ihrem Arbeitsverzeichnis befindet, mit dem, was sich in Ihrer Staging-Area befindet. -Das Ergebnis gibt Ihnen an, welche Änderungen Sie vorgenommen haben, die noch nicht „gestaged“ sind. +Das Ergebnis gibt dir an, welche Änderungen du vorgenommen hast, die noch nicht gestaged sind. -Wenn Sie wissen wollen, was Sie zum Commit vorgemerkt haben, das in Ihren nächsten Commit einfließt, können Sie `git diff --staged` verwenden. -Dieser Befehl vergleicht Ihre zum Commit vorgemerkten Änderungen mit Ihrem letzten Commit: +Wenn du wissen willst, was du zum Commit vorgemerkt hast, das in deinem nächsten Commit einfließt, kannst du `git diff --staged` verwenden. +Dieser Befehl vergleicht deine zum Commit vorgemerkten Änderungen mit deinem letzten Commit: [source,console] ---- @@ -344,10 +344,10 @@ index 0000000..03902a1 ---- Es ist wichtig zu wissen, dass `git diff` von sich aus nicht alle Änderungen seit Ihrem letzten Commit anzeigt – nur die Änderungen, die noch „unstaged“ sind. -Wenn Sie alle Ihre Änderungen bereits „gestaged“ haben, wird `git diff` Ihnen keine Antwort geben. +Wenn du alle deine Änderungen bereits „gestaged“ hast, wird `git diff` dir keine Antwort geben. -Ein weiteres Beispiel: wenn Sie die Datei `CONTRIBUTING.md` zum Commit vormerken und dann wieder bearbeiten, können Sie mit `git diff` die Änderungen in der „staged“-Datei und die „unstaged“-Änderungen sehen. -Wenn Sie folgendes gemacht haben +Ein weiteres Beispiel: Wenn du die Datei `CONTRIBUTING.md` stagst und dann bearbeitest, kannst du `git diff` verwenden, um die Änderungen in der Datei anzuzeigen, die staged und nicht staged sind. +Wenn es bei dir so aussieht: [source,console] ---- @@ -368,7 +368,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -können Sie jetzt mit `git diff` sehen, was noch nicht zum Commit vorgemerkt ist +kannst du jetzt mit `git diff` sehen, was noch nicht zum Commit vorgemerkt ist [source,console] ---- @@ -384,7 +384,7 @@ index 643e24f..87f08c8 100644 +# test line ---- -und `git diff --cached` zeigt Ihnen, was Sie bisher zum Commit vorgemerkt haben (`--staged` und `--cached` sind Synonyme, sie bewirken das Gleiche): +und `git diff --cached` zeigt an, was du bisher zum Commit vorgemerkt hast (`--staged` und `--cached` sind Synonyme, sie bewirken das Gleiche): [source,console] ---- @@ -409,30 +409,30 @@ index 8ebb991..643e24f 100644 .Git Diff mit einem externen Tool ==== Wir werden den Befehl `git diff` im weiteren Verlauf des Buches auf vielfältige Weise verwenden. -Es gibt eine weitere Methode, diese Diffs zu betrachten, wenn Sie lieber ein graphisches oder externes Diff-Viewing-Programm bevorzugen. -Wenn Sie `git difftool` anstelle von `git diff` verwenden, können Sie alle diese Unterschiede in einer Software wie emerge, vimdiff und viele andere (einschließlich kommerzieller Produkte) anzeigen lassen. -Führen Sie den Befehl `git difftool --tool-help` aus, um zu sehen, was auf Ihrem System verfügbar ist. +Es gibt eine weitere Methode, diese Diffs zu betrachten, solltest du lieber ein graphisches oder externes Diff-Viewing-Programm bevorzugen. +Wenn du `git difftool` anstelle von `git diff` verwendest, könntest du alle diese Unterschiede in einer Software wie emerge, vimdiff und viele andere (einschließlich kommerzieller Produkte) anzeigen lassen. +Führe einfach den Befehl `git difftool --tool-help` aus, um zu sehen, was auf deinem System verfügbar ist. ==== [[_committing_changes]] ==== Die Änderungen committen -Nachdem Ihre Staging-Area nun so eingerichtet ist, wie Sie es wünschen, können Sie Ihre Änderungen committen. -Denken Sie daran, dass alles, was noch nicht zum Commit vorgemerkt ist – alle Dateien, die Sie erstellt oder geändert haben und für die Sie seit Ihrer Bearbeitung nicht mehr `git add` ausgeführt haben – nicht in diesen Commit einfließen werden. -Sie bleiben aber als geänderte Dateien auf Ihrer Festplatte erhalten. -In diesem Beispiel nehmen wir an, dass Sie beim letzten Mal, als Sie `git status` ausgeführt haben, gesehen haben, dass alles zum Commit vorgemerkt wurde und bereit sind, Ihre Änderungen zu committen.(((Git Befehle, status))) -Am einfachsten ist es, wenn Sie `git commit` eingeben:(((Git Befehle, commit))) +Nachdem deine Staging-Area nun so eingerichtet ist, wie du es wünschst, kannst du deine Änderungen committen. +Denke daran, dass alles, was noch nicht zum Commit vorgemerkt ist – alle Dateien, die du erstellt oder geändert hast und für die du seit deiner Bearbeitung nicht mehr `git add` ausgeführt hast – nicht in diesen Commit einfließen werden. +Sie bleiben aber als geänderte Dateien auf deiner Festplatte erhalten. +In diesem Beispiel nehmen wir an, dass du beim letzten Mal, als du `git status` ausgeführt hast, gesehen hast, dass alles zum Commit vorgemerkt wurde und du bereit bist, alle deine Änderungen zu committen.(((Git Befehle, status))) +Am einfachsten committen man, wenn `git commit` eingegeben wird:(((Git Befehle, commit))) [source,console] ---- $ git commit ---- -Dadurch wird der Editor Ihrer Wahl gestartet. +Dadurch wird der Editor deiner Wahl gestartet. [NOTE] ==== -Das wird durch die Umgebungsvariable `EDITOR` Ihrer Shell festgelegt – normalerweise Vim oder Emacs. Sie können den Editor aber auch mit dem Befehl `git config --global core.editor` beliebig konfigurieren, wie Sie es in Kapitel 1, <> gesehen haben.(((Editor, ändern der Voreinstellung)))(((Git Befehle, config))) +Das wird durch die Umgebungsvariable `EDITOR` deiner Shell festgelegt – normalerweise Vim oder Emacs. Du kannst den Editor aber auch mit dem Befehl `git config --global core.editor` beliebig konfigurieren, wie du es in Kapitel 1, <> gesehen hast.(((Editor, ändern der Voreinstellung)))(((Git Befehle, config))) ==== Der Editor zeigt den folgenden Text an (dieses Beispiel ist eine Vim-Ansicht): @@ -455,18 +455,18 @@ Der Editor zeigt den folgenden Text an (dieses Beispiel ist eine Vim-Ansicht): ".git/COMMIT_EDITMSG" 9L, 283C ---- -Sie können erkennen, dass die Standard-Commit-Meldung die neueste Ausgabe des auskommentierten Befehls `git status` und eine leere Zeile darüber enthält. -Sie können diese Kommentare entfernen und Ihre Commit-Nachricht eingeben oder Sie können sie dort stehen lassen, damit Sie sich merken können, was Sie committen. +Du kannst erkennen, dass die Standard-Commit-Meldung die neueste Ausgabe des auskommentierten Befehls `git status` und eine leere Zeile darüber enthält. +Du kannst diese Kommentare entfernen und deine eigene Commit-Nachricht eingeben oder du kannst sie dort stehen lassen, damit du dir merken kannst, was was du committed hast. [NOTE] ==== -Für eine noch bessere Gedächtnisstütze über das, was Sie geändert haben, können Sie die Option `-v` an `git commit` übergeben. -Dadurch wird auch die Differenz Ihrer Änderung in den Editor geschrieben, so dass Sie genau sehen können, welche Änderungen Sie committen. +Für eine noch bessere Gedächtnisstütze über das, was du geändert hast, kannst du die Option `-v` an `git commit` übergeben. +Dadurch wird auch die Änderung in den Editor geschrieben, so dass du genau sehen kannst, welche Änderungen du committest. ==== -Wenn Sie den Editor verlassen, erstellt Git Ihren Commit mit dieser Commit-Nachricht (mit den Kommentaren und ausgeblendetem Diff). +Wenn du den Editor verlässt, erstellt Git deinen Commit mit dieser Commit-Nachricht (mit den Kommentaren und ausgeblendetem Diff). -Alternativ können Sie Ihre Commit-Nachricht auch inline mit dem Befehl `commit -m` eingeben. Das Flag `-m` ermöglicht die direkte Eingabe eines Kommentartextes: +Alternativ kannst du deine Commit-Nachricht auch inline mit dem Befehl `commit -m` eingeben. Das Flag `-m` ermöglicht die direkte Eingabe eines Kommentartextes: [source,console] ---- @@ -476,19 +476,19 @@ $ git commit -m "Story 182: fix benchmarks for speed" create mode 100644 README ---- -Jetzt haben Sie Ihren ersten Commit erstellt! -Sie können sehen, dass der Commit eine Nachricht über sich selbst ausgegeben hat: in welchen Branch Sie committet haben (`master`), welche SHA-1-Prüfsumme der Commit hat (`463dc4f`), wie viele Dateien geändert wurden und Statistiken über hinzugefügte und entfernte Zeilen im Commit. +Jetzt hast du deinen ersten Commit erstellt! +Du kannst sehen, dass der Commit eine Nachricht über sich selbst ausgegeben hat: in welchen Branch du committet hast (`master`), welche SHA-1-Prüfsumme der Commit hat (`463dc4f`), wie viele Dateien geändert wurden und Statistiken über hinzugefügte und entfernte Zeilen im Commit. -Denken Sie daran, dass der Commit den Snapshot aufzeichnet, den Sie in Ihrer Staging-Area eingerichtet haben. -Alles, was von Ihnen nicht zum Commit vorgemerkt wurde, liegt immer noch als modifiziert da. Sie können einen weiteren Commit durchführen, um es zu Ihrer Historie hinzuzufügen. -Jedes Mal, wenn Sie einen Commit ausführen, zeichnen Sie einen Schnappschuss Ihres Projekts auf, auf den Sie zurückgreifen oder mit einem späteren Zeitpunkt vergleichen können. +Denke daran, dass der Commit den Snapshot aufzeichnet, den du in deiner Staging-Area eingerichtet hast. +Alles, was von dir nicht zum Commit vorgemerkt wurde, ist weiterhin verfügbar. Du kannst einen weiteren Commit durchführen, um es zu deiner Historie hinzuzufügen. +Jedes Mal, wenn du einen Commit ausführst, zeichnest du einen Schnappschuss deines Projekts auf, auf den du zurückgreifen oder mit dem du später vergleichen kannst. ==== Die Staging-Area überspringen (((Staging-Area, überspringen))) -Obwohl es außerordentlich nützlich sein kann, Commits so zu erstellen, wie Sie es wünschen, ist die Staging-Area manchmal etwas komplexer, als Sie es für Ihren Workflow benötigen. -Wenn Sie die Staging-Area überspringen möchten, bietet Git eine einfache Kurzform. -Durch das Hinzufügen der Option `-a` zum Befehl `git commit` wird jede Datei, die bereits vor dem Commit versioniert war, automatisch von Git zum Commit vorgemerkt (engl. staged), so dass Sie den Teil `git add` überspringen können: +Obwohl es außerordentlich nützlich sein kann, Commits so zu erstellen, wie du es wünschst, ist die Staging-Area manchmal etwas komplexer, als du es für deinen Workflow benötigst. +Wenn du die Staging-Area überspringen möchten, bietet Git eine einfache Kurzform. +Durch das Hinzufügen der Option `-a` zum Befehl `git commit` wird jede Datei, die bereits vor dem Commit versioniert war, automatisch von Git zum Commit staged, so dass du den Teil `git add` überspringen kannst: [source,console] ---- @@ -507,18 +507,18 @@ $ git commit -a -m 'Add new benchmarks' 1 file changed, 5 insertions(+), 0 deletions(-) ---- -Beachten Sie, dass Sie in diesem Fall `git add` nicht für die Datei `CONTRIBUTING.md` ausführen müssen, bevor Sie committen. +Beachte, dass du in diesem Fall `git add` nicht für die Datei `CONTRIBUTING.md` ausführen musst, bevor du committest. Das liegt daran, dass das `-a`-Flag alle geänderten Dateien einschließt. -Das ist bequem, aber seien Sie vorsichtig. Manchmal führt dieses Flag dazu, dass Sie ungewollte Änderungen vornehmen. +Das ist bequem. Aber sei vorsichtig, manchmal führt dieses Flag dazu, dass du ungewollte Änderungen vornimmst. [[_removing_files]] ==== Dateien löschen (((Dateien, entfernen))) -Um eine Datei aus Git zu entfernen, müssen Sie sie aus der Versionsverwaltung entfernen (genauer gesagt, aus Ihrem Staging-Bereich löschen) und dann committen. -Der Befehl `git rm` erledigt das und entfernt die Datei auch aus Ihrem Arbeitsverzeichnis, so dass Sie sie beim nächsten Mal nicht mehr als „untracked“-Datei sehen. +Um eine Datei aus Git zu entfernen, musst du sie aus der Versionsverwaltung entfernen (genauer gesagt, aus Ihrem Staging-Bereich löschen) und dann committen. +Der Befehl `git rm` erledigt das und entfernt die Datei auch aus deinem Arbeitsverzeichnis, so dass du sie beim nächsten Mal nicht mehr als „untracked“-Datei siehst. -Wenn Sie die Datei einfach aus Ihrem Arbeitsverzeichnis entfernen, erscheint sie unter dem „Changes not staged for commit“-Bereich (das ist die _unstaged_-Area) Ihrer `git status` Ausgabe: +Wenn du die Datei einfach aus deinem Arbeitsverzeichnis entfernst, erscheint sie unter dem „Changes not staged for commit“-Bereich (das ist die _unstaged_-Area) deiner `git status` Ausgabe: [source,console] ---- @@ -535,7 +535,7 @@ Changes not staged for commit: no changes added to commit (use "git add" and/or "git commit -a") ---- -Wenn Sie dann `git rm` ausführen, wird die Entfernung der Datei zum Commit vorgemerkt: +Wenn du dann `git rm` ausführst, wird die Entfernung der Datei zum Commit vorgemerkt: [source,console] ---- @@ -550,32 +550,32 @@ Changes to be committed: deleted: PROJECTS.md ---- -Wenn Sie das nächste Mal einen Commit ausführen, ist die Datei weg und ist nicht mehr versioniert (engl. tracked). -Wenn Sie die Datei geändert oder bereits zur Staging-Area hinzugefügt haben, müssen Sie das Entfernen mit der Option `-f` erzwingen. +Wenn du das nächste Mal einen Commit ausführst, ist die Datei weg und ist nicht mehr versioniert (engl. tracked). +Wenn du die Datei geändert oder bereits zur Staging-Area hinzugefügt hast, musst du das Entfernen mit der Option `-f` erzwingen. Hierbei handelt es sich um eine Sicherheitsfunktion, die ein versehentliches Entfernen von Dateien verhindert, die noch nicht in einem Snapshot aufgezeichnet wurden und die nicht von Git wiederhergestellt werden können. -Eine weitere nützliche Sache, die Sie möglicherweise nutzen möchten, ist, die Datei in Ihrem Verzeichnisbaum zu behalten, sie aber aus Ihrer Staging-Area zu entfernen. -Mit anderen Worten, Sie können die Datei auf Ihrer Festplatte behalten, aber nicht mehr von Git protokollieren/versionieren lassen. +Eine weitere nützliche Sache, die du möglicherweise nutzen möchtest, ist, die Datei in Ihrem Verzeichnisbaum zu behalten, sie aber aus deiner Staging-Area zu entfernen. +Mit anderen Worten, du kannst die Datei auf deiner Festplatte behalten, aber nicht mehr von Git protokollieren/versionieren lassen. -Das ist besonders dann nützlich, wenn Sie vergessen haben, etwas zu Ihrer Datei `.gitignore` hinzuzufügen und dies versehentlich „gestaged“ haben (eine große Logdatei z.B. oder eine Reihe von .a-kompilierten Dateien). -Das erreichen Sie mit der Option `--cached`: +Das ist besonders dann nützlich, wenn du vergessen hast, etwas zu deiner Datei `.gitignore` hinzuzufügen und dies dann versehentlich gestaged hast (eine große Logdatei z.B. oder eine Reihe von .a-kompilierten Dateien). +Das erreichst du mit der Option `--cached`: [source,console] ---- $ git rm --cached README ---- -Sie können Dateien, Verzeichnisse und Platzhalter-Zeichen an den Befehl `git rm` übergeben. -Das bedeutet, dass Sie folgende Möglichkeit haben: +Du kannst Dateien, Verzeichnisse und Platzhalter-Zeichen an den Befehl `git rm` übergeben. +Das bedeutet, dass du folgende Möglichkeit hast: [source,console] ---- $ git rm log/\*.log ---- -Beachten Sie den Backslash (`\`) vor dem `*`. -Der ist notwendig, weil Git zusätzlich zur Dateinamen-Erweiterung Ihrer Shell eine eigene Dateinamen-Erweiterung vornimmt. +Beachten den Backslash (`\`) vor dem `*`. +Der ist notwendig, weil Git zusätzlich zur Dateinamen-Erweiterung deiner Shell eine eigene Dateinamen-Erweiterung vornimmt. Mit dem Befehl oben werden alle Dateien entfernt, die die Erweiterung `.log` im Verzeichnis `log/` haben. -Oder Sie können Folgendes ausführen: +Oder du kannst Folgendes ausführen: [source,console] ---- @@ -589,11 +589,11 @@ Dieses Kommando entfernt alle Dateien, deren Name mit `~` endet. (((Dateien, verschieben))) Im Gegensatz zu vielen anderen VCS-Systemen verfolgt (engl. track) Git das Verschieben von Dateien nicht ausdrücklich. -Wenn Sie eine Datei in Git umbenennen, werden keine Metadaten in Git gespeichert, die dem System mitteilen, dass Sie die Datei umbenannt haben. +Wenn du eine Datei in Git umbenennst, werden keine Metadaten in Git gespeichert, die dem System mitteilen, dass du die Datei umbenannt hast. Allerdings ist Git ziemlich clever, das im Nachhinein herauszufinden – wir werden uns etwas später mit der Erkennung von Datei-Verschiebungen befassen. Daher ist es etwas verwirrend, dass Git einen Befehl `mv` vorweisen kann. -Wenn Sie eine Datei in Git umbenennen möchten, können Sie beispielsweise Folgendes ausführen: +Wenn du eine Datei in Git umbenennen möchten, kannst du beispielsweise Folgendes ausführen: [source,console] ---- @@ -601,7 +601,7 @@ $ git mv file_from file_to ---- Das funktioniert gut. -Tatsache ist, wenn Sie so einen Befehl ausführen und sich den Status ansehen, werden Sie sehen, dass Git es für eine umbenannte Datei hält: +Tatsache ist, wenn du so einen Befehl ausführst und dir den Status ansiehst, wirst du sehen, dass Git es für eine umbenannte Datei hält: [source,console] ---- @@ -624,6 +624,6 @@ $ git rm README.md $ git add README ---- -Git erkennt, dass es sich um eine umbenannte Datei handelt, so dass es egal ist, ob Sie eine Datei auf diese Weise oder mit dem Befehl `mv` umbenennen. +Git erkennt, dass es sich um eine umbenannte Datei handelt, so dass es egal ist, ob du eine Datei auf diese Weise oder mit dem Befehl `mv` umbenennst. Der alleinige, reale Unterschied ist, dass `git mv` ein einziger Befehl ist statt deren drei – es ist eine Komfortfunktion. -Wichtiger ist, dass Sie jedes beliebige Tool verwenden können, um eine Datei umzubenennen und das `add`/`rm` später aufrufen können, bevor Sie committen. +Wichtiger ist, dass du jedes beliebige Tool verwenden können, um eine Datei umzubenennen und das du `add`/`rm` später aufrufen kannst, bevor du committest. diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 2d0a20eb..fac84e65 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -1,26 +1,26 @@ [[_remote_repos]] === Mit Remotes arbeiten -Um an Git-Projekte mitarbeiten zu können, müssen Sie wissen, wie Sie Remote-Repositorys verwalten können. +Um an Git-Projekte mitarbeiten zu können, musst du wissen, wie du deine Remote-Repositorys verwalten kannst. 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-Repositorys sowie das Pushing und Pulling von Daten zu und von den Repositorys, wenn Sie Ihre Arbeit teilen möchten. +Du kannst Mehrere davon haben, von denen jedes in der Regel entweder schreibgeschützt oder beschreibbar ist. +Die Zusammenarbeit mit Anderen erfordert die Verwaltung dieser Remote-Repositorys sowie das Pushing und Pulling von Daten zu und von den Repositorys, wenn du deine Arbeit teilen möchtest. 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-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. +Es ist durchaus möglich, dass du mit einem „entfernten“ Repository arbeiten kannst, das sich eigentlich auf demselben Host befindet auf dem du gerade arbeitest. 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. Die Arbeit mit einem solchen entfernten Repository würde immer noch alle üblichen Push-, Pull- und Fetch-Operationen einschließen, wie bei jedem anderen Remote-Repository. ==== ==== Auflisten der Remotes -Um zu sehen, welche Remote-Server Sie konfiguriert haben, können Sie den Befehl `git remote` aufrufen.(((Git Befehle, remote))) -Er listet die Kurznamen der einzelnen von Ihnen festgelegten Remote-Handles auf. -Wenn Sie Ihr Repository geklont haben, sollten Sie zumindest `origin` sehen – das ist der Standardname, den Git dem Server gibt, von dem Sie geklont haben: +Um zu sehen, welche Remote-Server bei dir konfiguriert sind, kannst du den Befehl `git remote` aufrufen.(((Git Befehle, remote))) +Er listet die Kurznamen der einzelnen von dir festgelegten Remote-Handles auf. +Wenn du dein Repository geklont hast, solltest du zumindest `origin` sehen – das ist der Standardname, den Git dem Server gibt, von dem du geklont hast: [source,console] ---- @@ -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, um beim Lesen und Schreiben auf diesen Remote zuzugreifen: +Du kannst zusätzlich auch `-v` angeben, das dir die URLs anzeigt, die Git für den Kurznamen gespeichert hat, um beim Lesen und Schreiben auf diesen Remote zuzugreifen: [source,console] ---- @@ -45,7 +45,7 @@ origin https://github.com/schacon/ticgit (fetch) origin https://github.com/schacon/ticgit (push) ---- -Wenn Sie mehr als einen Remote haben, listet der Befehl sie alle auf. +Wenn du mehr als einen Remote hast, listet der Befehl sie alle auf. Ein Repository mit mehreren Remotes für die Arbeit mit mehreren Beteiligten könnte beispielsweise so aussehen. [source,console] @@ -67,13 +67,13 @@ origin git@github.com:mojombo/grit.git (push) Das bedeutet, dass wir Beiträge von jedem dieser Benutzer ziemlich einfach abrufen können. Möglicherweise haben wir zusätzlich die Erlaubnis, auf einen oder mehrere von diesen zu pushen, obwohl wir das hier nicht erkennen können. -Beachten Sie, dass diese Remotes eine Vielzahl von Protokollen verwenden; wir werden mehr darüber erfahren, wenn wir <>. +Beachte: Diese Remotes verwenden unterschiedliche Protokollen; wir werden mehr darüber hier erfahren: <>. ==== 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. -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: +Wir haben bereits erwähnt und einige Beispiele gezeigt, wie der Befehl `git clone` stillschweigend den Remote `origin` hinzufügt. +Im Folgendem beschreiben wir, wie du einen neuen Remote hinzufügen kannst.(((Git Befehle, remote))) +Um ein neues Remote-Git-Repository als Kurzname hinzuzufügen, auf das du verweisen kannst, führe `git remote add ` aus: [source,console] ---- @@ -87,8 +87,8 @@ pb https://github.com/paulboone/ticgit (fetch) pb https://github.com/paulboone/ticgit (push) ---- -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: +Nun kannst du die Zeichenfolge `pb` auf der Kommandozeile anstelle der gesamten URL verwenden. +Wenn du beispielsweise alle Informationen fetchen möchtest, die Paul hat, die aber noch nicht in deinem Repository enthalten sind, kannst du `git fetch pb` ausführen: [source,console] ---- @@ -102,65 +102,65 @@ From https://github.com/paulboone/ticgit * [new branch] ticgit -> pb/ticgit ---- -Pauls `master` Branch ist nun lokal als `pb/master` erreichbar – Sie können ihn in eine Ihrer Branches einbinden oder an dieser Stelle in einen lokalen Branch wechseln (engl. checkout), wenn Sie ihn inspizieren möchten. +Pauls `master` Branch ist nun lokal als `pb/master` erreichbar – Du kannst ihn in eine deiner Branches mergen oder ihn in einen lokalen Branch auschecken, wenn du ihn inspizieren möchten. Wir werden in <> detailliert beschreiben, was Branches sind und wie man sie nutzt. [[_fetching_and_pulling]] ==== Fetchen und Pullen von Ihren Remotes -Wie Sie gerade gesehen haben, können Sie Daten aus Ihren Remote-Projekten abrufen:(((Git Befehle, fetch))) +Wie du gerade gesehen hast, kannst du Daten aus deinem Remote-Projekt abrufen:(((Git Befehle, fetch))) [source,console] ---- $ git fetch ---- -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. +Der Befehl geht an das Remote-Projekt und zieht (engl. pull) alle Daten von diesem Remote-Projekt, die du noch nicht hast. +Danach solltest du Referenzen auf alle Branches dieses Remote haben, die du jederzeit mergen oder inspizieren kannst. -Wenn Sie ein Repository klonen, fügt der Befehl dieses entfernte Repository automatisch unter dem Namen „origin“ hinzu. +Wenn du ein Repository klonst, fügt der Befehl dieses entfernte Repository automatisch unter dem Namen „origin“ hinzu. 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. +Es ist jedoch wichtig zu beachten, dass der Befehl `git fetch` nur die Daten in dein lokales Repository herunterlädt – er merged sie nicht automatisch mit deiner Arbeit zusammen oder ändert das, woran du gerade arbeitest. +Du musst das Ganze manuell mit deiner Arbeit zusammenführen, wenn du soweit bist. -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. Anschliessend wird automatisch versucht diese Daten in ihren Code zu mergen. +Wenn dein aktueller Branch so eingerichtet ist, dass er einen entfernten Branch verfolgt (engl. tracking), kannst du den Befehl `git pull` verwenden, um diesen entfernten Branch automatisch zu fetchen und dann mit deinem aktuellen Branch zu mergen (siehe den nächsten Abschnitt und <> für weitere Informationen).(((Git Befehle, pull))) +Das könnte ein einfacherer oder komfortablerer Workflow 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 du geklont hast. +Wenn du `git pull` ausführst, werden normalerweise Daten von dem Server abgerufen, von dem du ursprünglich geklont hast. Anschliessend wird automatisch versucht diese Daten in deinem Code zu mergen. [NOTE] ==== Ab der Version 2.27 von Git wird `git pull` eine Warnung ausgeben, wenn die Variable `pull.rebase` nicht gesetzt ist. -Git wird Sie so lange warnen, bis Sie die Variable setzen. +Git wird dich so lange warnen, bis du die Variable setzt. -Falls Sie das Standardverhalten (möglichst ein fast-forward, ansonsten einen Merge-Commit erstellen) von Git beibehalten wollen: +Falls du das Standardverhalten (möglichst ein fast-forward, ansonsten einen Merge-Commit erstellen) von Git beibehalten willst: `git config --global pull.rebase "false"` -Wenn Sie mit dem Pullen einen Rebase machen wollen: +Wenn du jedoch mit dem Pullen einen Rebase machen willst: `git config --global pull.rebase "true"` ==== [[_pushing_remotes]] ==== Zu Ihren Remotes Pushen -Wenn Sie Ihr Projekt an einem Punkt haben, den Sie teilen möchten, können Sie es zum Upstream verschieben (engl. pushen). +Wenn du dein Projekt an einem Punkt hast, an dem du es teilen möchtest, können wir 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: +Wenn du deinen `master` Branch auf den `origin` Server pushen möchtest (Zur Erinnerung: das Klonen richtet im Regelfall diese beiden Branches automatisch ein), dann kannst du diesen Befehl auch nutzen, um alle Commits, die du durchgeführt hast, auf den Server zu pushen: [source,console] ---- $ git push origin master ---- -Dieser Befehl funktioniert allerdings nur, wenn Sie von einem Server geklont haben, auf den Sie Schreibzugriff haben und wenn in der Zwischenzeit noch niemand anderes gepusht hat. -Wenn Sie und ein anderer Benutzer gleichzeitig klonen und Sie beide Upstream pushen wollen, Sie aber etwas später nach Upstream pushen, dann wird Ihr Push zu Recht abgelehnt. -Sie müssen zuerst dessen Bearbeitung abholen und in Ihre einbinden, bevor Sie pushen können. +Dieser Befehl funktioniert allerdings nur, wenn du von einem Server geklont hast, auf den du Schreibzugriff hast und wenn in der Zwischenzeit noch niemand anderes gepusht hat. +Wenn du und ein anderer Benutzer gleichzeitig klonen und beide Upstream pushen wollen, du aber etwas später nach Upstream pushst, dann wird dein Push zu Recht abgelehnt. +Du musst zuerst dessen Bearbeitung abholen und in deine einbinden, bevor du pushen kannst. Siehe Kapitel 3 <> mit ausführlicheren Details zum Pushen auf Remote-Server. [[_inspecting_remote]] ==== 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 remote Kurznamen ausführen, wie z.B. `origin`, erhalten Sie bspw. folgende Meldung: +Wenn du mehr Informationen über einen bestimmten Remote sehen möchten, kannst du den Befehl `git remote show ` verwenden.(((Git Befehle, remote))) +Wenn du diesen Befehl mit einem remote Kurznamen ausführen, wie z.B. `origin`, erhältst du bspw. folgende Meldung: [source,console] ---- @@ -179,11 +179,11 @@ $ git remote show origin ---- 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. +Der Befehl teilt dir mit: Wenn du dich im Master-Zweig befindest und `git pull` ausführst, 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 möglicherweise treffen werden. -Wenn Sie Git hingegen intensiver verwenden, können die `git remote show` Ausgabe wesentlich umfangreicher sein: +Das ist nur ein einfaches Beispiel, auf das du möglicherweise treffen wirst. +Wenn du Git hingegen intensiver verwendest, könnte die `git remote show` Ausgabe wesentlich umfangreicher sein: [source,console] ---- @@ -209,13 +209,13 @@ $ git remote show origin master pushes to master (up to date) ---- -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 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. +Dieser Befehl zeigt an, zu welchem Zweig automatisch gepusht wird, wenn du `git push` ausführst, während du dich in bestimmten Branches befindest. +Er zeigt dir auch, welche entfernten Branches auf dem Server vorhanden sind, die du noch nicht hast, welche entfernten Branches du hast, die aber vom Server gelöscht wurden und die lokalen Branches, die automatisch mit deinen Remote-Tracking-Branch zusammengeführt (gemergt) werden können, wenn du `git pull` ausführst. ==== Umbenennen und Entfernen von Remotes -Sie können `git remote rename` ausführen, um den Kurznamen eines Remotes zu ändern.(((Git Befehle, remote))) -Wenn Sie beispielsweise `pb` in `paul` umbenennen möchten, können Sie dieses mit dem Befehl `git remote rename` machen: +Du kannst `git remote rename` ausführen, um den Kurznamen eines Remotes zu ändern.(((Git Befehle, remote))) +Wenn du beispielsweise `pb` in `paul` umbenennen möchtest, kannst du dies mit dem Befehl `git remote rename` erreichen: [source,console] ---- @@ -225,10 +225,10 @@ origin paul ---- -Es ist zu beachten, dass dadurch auch alle Ihre Remote-Tracking-Branchnamen geändert werden. +Es ist zu beachten, dass dadurch auch alle deine Remote-Tracking-Branchnamen geändert werden. 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: +Wenn du einen Remote aus irgendwelchen Gründen entfernen möchten – Du hast den Server verschoben oder verwendest einen bestimmten Mirror nicht länger oder ein Beitragender ist nicht mehr dabei – dann kannst du entweder `git remote remove` oder `git remote rm` verwenden: [source,console] ---- @@ -237,4 +237,4 @@ $ git remote origin ---- -Sobald Sie die Referenz auf einen Remote auf diese Weise gelöscht haben, werden auch alle mit diesem Remote verbundenen Remote-Tracking-Branches und Konfigurationseinstellungen gelöscht. +Sobald du die Referenz auf einen Remote auf diese Weise gelöscht hast, werden auch alle mit diesem Remote verbundenen Remote-Tracking-Branches und Konfigurationseinstellungen gelöscht. diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 2124229c..7e2ca1aa 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -4,12 +4,12 @@ (((Tags))) Wie die meisten VCSs hat Git die Möglichkeit, bestimmte Punkte in der Historie eines Repositorys als wichtig zu markieren. Normalerweise verwenden Leute diese Funktionalität, um Releases zu markieren (`v1.0`, `v2.0` usw). -In diesem Abschnitt erfahren Sie, wie Sie bestehende Tags auflisten, Tags erstellen und löschen können sowie was die unterschiedlichen Tag-Typen sind. +In diesem Abschnitt erfährst du, wie bestehende Tags aufgelistet, Tags erstellt und gelöscht werden können sowie was die unterschiedlichen Tag-Typen sind. -==== Ihre Tags auflisten +==== Deine Tags auflisten Die Auflistung der vorhandenen Tags in Git ist unkompliziert. -Geben Sie einfach `git tag` (mit optionalem `-l` oder `--list`) ein:(((Git Befehle, tag))) +Gib einfach `git tag` (mit optionalem `-l` oder `--list`) ein:(((Git Befehle, tag))) [source,console] ---- @@ -20,9 +20,9 @@ v2.0 Dieser Befehl listet die Tags in alphabetischer Reihenfolge auf. Die Reihenfolge, in der sie angezeigt werden, hat keine wirkliche Bedeutung. -Sie können auch nach Tags suchen, die einer bestimmten Zeichenfolge entsprechen. +Du kannst auch nach Tags suchen, die einer bestimmten Zeichenfolge entsprechen. Das Git-Source-Repo zum Beispiel enthält mehr als 500 Tags. -Wenn Sie nur daran interessiert sind, sich die 1.8.5-Serie anzusehen, können Sie Folgendes ausführen: +Wenn du nur daran interessiert bist, dir die 1.8.5-Serie anzusehen, kannst du Folgendes ausführen: [source,console] ---- @@ -42,9 +42,9 @@ v1.8.5.5 [NOTE] .Das Auflisten von Tag-Wildcards erfordert die Option `-l` oder `--list` ==== -Wenn Sie lediglich die gesamte Liste der Tags wünschen, geht die Ausführung des Befehls `git tag` implizit davon aus, dass Sie eine Auflistung haben wollen und gibt sie aus; die Verwendung von `-l` oder `--list` ist in diesem Fall optional. +Wenn du lediglich die gesamte Liste der Tags wünschst, geht die Ausführung des Befehls `git tag` implizit davon aus, dass du eine Auflistung haben willst und gibt sie aus; die Verwendung von `-l` oder `--list` ist in diesem Fall optional. -Wenn Sie jedoch ein Platzhaltermuster angeben, das mit den Tag-Namen übereinstimmt, ist die Verwendung von `-l` oder `--list` obligatorisch. +Wenn du jedoch ein Platzhaltermuster angibst, das mit den Tag-Namen übereinstimmt, ist die Verwendung von `-l` oder `--list` obligatorisch. ==== ==== Erstellen von Tags @@ -55,14 +55,14 @@ Ein nicht-annotiertes Tag ist sehr ähnlich eines Branches, der sich nicht ände 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-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. +Es wird allgemein empfohlen annotierte Tags zu erstellen, damit all diese Informationen gespeichert werden; aber wenn du ein temporäres Tag wünschst oder aus irgendwelchen Gründen die anderen Informationen nicht speichern willst, sind auch nicht-annotierte Tags möglich. [[_annotated_tags]] ==== Annotated Tags (((Tags, annotiert))) Das Erstellen eines annotierten Tags in Git ist einfach. -Der einfachste Weg ist die Eingabe von `-a`, wenn Sie den Befehl `tag` ausführen:(((Git Befehle, tag))) +Der einfachste Weg ist die Eingabe von `-a`, beim Ausführen des `tag` Befehls:(((Git Befehle, tag))) [source,console] ---- @@ -74,9 +74,9 @@ v1.4 ---- 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. +Wenn du keine Nachricht für ein annotierten Tag angibst, startet Git deinen Editor, damit du eine Nachricht eingeben kannst. -Sie können die Tag-Daten zusammen mit dem getaggten Commit sehen, indem Sie den Befehl `git show` verwenden: +Du kannst die Tag-Daten zusammen mit dem getaggten Commit sehen, indem du den Befehl `git show` verwendest: [source,console] ---- @@ -94,14 +94,14 @@ 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 Annotationsnachricht 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 (((Tags, lightweight))) Eine weitere Möglichkeit, Commits zu markieren, ist ein leichtgewichtiger, nicht-annotierter Tag. Das ist im Grunde genommen die in einer Datei gespeicherte Commit-Prüfsumme – es werden keine weiteren Informationen gespeichert. -Um einen leichtgewichtigen Tag zu erstellen, geben Sie keine der Optionen `-a`, `-s` oder `-m` an, sondern nur einen Tag-Namen: +Um einen leichtgewichtigen Tag zu erstellen, gib keine der Optionen `-a`, `-s` oder `-m` an, sondern nur einen Tag-Namen: [source,console] ---- @@ -114,7 +114,7 @@ v1.4-lw v1.5 ---- -Wenn Sie diesmal `git show` auf dem Tag ausführen, sehen Sie keine zusätzlichen Tag-Informationen.(((Git Befehle, show))) +Wenn du diesmal `git show` auf dem Tag ausführst, siehst du keine zusätzlichen Tag-Informationen.(((Git Befehle, show))) Der Befehl zeigt nur den Commit an: [source,console] @@ -129,8 +129,8 @@ Date: Mon Mar 17 21:52:11 2008 -0700 ==== Nachträgliches Tagging -Sie können auch ältere Commits markieren. -Angenommen, Ihr Commit-Verlauf sieht so aus: +Du kannst auch ältere Commits markieren. +Angenommen, dein Commit-Verlauf sieht so aus: [source,console] ---- @@ -147,16 +147,16 @@ a6b4c97498bd301d84096da251c98a07c7723e65 Create write support 8a5cbc430f1a9c3d00faaeffd07798508422908a Update readme ---- -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: +Nehmen wir an, du hast vergessen, das Projekt mit v1.2 beim Commit von „Update rakefile“ zu taggen. +Du kannst ihn nachträglich hinzufügen. +Um diesen Commit zu markieren, gib am Ende des Befehls die Commit-Prüfsumme (oder einen Teil davon) an: [source,console] ---- $ git tag -a v1.2 9fceb02 ---- -Sie sehen, dass Sie den Commit getaggt haben:(((Git Befehle, tag))) +Du siehst, dass du den Commit getaggt hast:(((Git Befehle, tag))) [source,console] ---- @@ -186,8 +186,8 @@ Date: Sun Apr 27 20:43:35 2008 -0700 ==== 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 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. +Du musst Tags explizit auf einen Server verschieben, nachdem du sie erstellt hast. +Dieser Prozess funktioniert genauso wie das Teilen von Remote-Branches – Du musst dazu `git push origin ` ausführen. [source,console] ---- @@ -201,8 +201,8 @@ To git@github.com:schacon/simplegit.git * [new tag] v1.5 -> v1.5 ---- -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. +Wenn du viele Tags hast, die du auf einmal pushen willst, kannst du auch die Option `--tags` mit dem Befehl `git push` verwenden. +Dadurch werden alle deine Tags auf den Remote-Server übertragen, die sich noch nicht auf dem Server befinden. [source,console] ---- @@ -215,7 +215,7 @@ To git@github.com:schacon/simplegit.git * [new tag] v1.4-lw -> v1.4-lw ---- -Wenn jetzt jemand anderes aus Ihrem Repository klont oder pullt, erhält er auch alle Ihre Tags. +Wenn jetzt jemand anderes aus deinem Repository klont oder pullt, erhält er auch alle deine Tags. [NOTE] .`git push` pusht beide Arten von Tags @@ -226,7 +226,7 @@ Es gibt zur Zeit keine Möglichkeit, nur Lightweight-Tags zu pushen, aber wenn S ==== Tags löschen -Um einen Tag aus dem lokalen Repository zu löschen, verwenden Sie `git tag -d `. +Um einen Tag aus dem lokalen Repository zu löschen, verwende `git tag -d `. Wir könnten beispielsweise den leichtgewichtigen Tag wie folgt entfernen: [source,console] @@ -235,8 +235,8 @@ $ git tag -d v1.4-lw Deleted tag 'v1.4-lw' (was e7d5add) ---- -Beachten Sie, dass dadurch das Tag nicht von Remote-Servern entfernt wird. -Es gibt zwei gängige Varianten, um ein Tag von einem entfernten Server zu löschen. +Beachte, dass dadurch der Tag nicht von Remote-Servern entfernt wird. +Es gibt zwei gängige Varianten, um ein Tag von einem remote Server zu löschen. Die erste Möglichkeit ist `git push :refs/tags/`: @@ -247,7 +247,7 @@ To /git@github.com:schacon/simplegit.git - [deleted] v1.4-lw ---- -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. +Zur Erklärung des obigen Befehls: Vor dem Doppelpunkt ist nichts und somit als Nullwert zu lesen. Darauf wird der Remote-Tag-Name gepushed, wodurch dieser gelöscht wird. Der zweite, intuitivere Weg, ein Remote-Tag zu löschen, ist mit: @@ -258,7 +258,7 @@ $ git push origin --delete ==== Tags auschecken -Wenn Sie die Dateiversion anzeigen möchten, auf die ein bestimmter Tag zeigt, können Sie `git checkout` auf dieses Tag durchführen, obwohl dies Ihr Repository in den Zustand „detached HEAD“ (dt. losgelöst) versetzt, was einige negative Nebenwirkungen hat: +Wenn du die Dateiversion anzeigen möchtest, auf die ein bestimmter Tag zeigt, kannst du `git checkout` auf dieses Tag durchführen. Dies versetzt dein Repository in den Zustand „detached HEAD“ (dt. losgelöst), was einige negative Nebenwirkungen hat: [source,console] ---- @@ -287,8 +287,8 @@ Previous HEAD position was 99ada87... Merge pull request #89 from schacon/append 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 einen Branch erstellen: +Wenn du im Zustand „detached HEAD“ Änderungen wornimmst und dann einen Commit erstellst, bleibt der Tag gleich, aber dein neuer Commit gehört zu keinem Branch und ist unzugänglich, außer mit dem genauen Commit-Hash. +Wenn du also Änderungen vornehmen musst – z.B. wenn du einen Fehler in einer älteren Version behebst – wirst du normalerweise 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 Branch `version2` leicht von Ihrem Tag `v2.0.0` unterscheiden, da er mit Ihren neuen Änderungen fortschreitet, seien Sie also vorsichtig. +Wenn du das tust und einen Commit erstellst, wird sich dein Branch `version2` leicht von deinem Tag `v2.0.0` unterscheiden, da er mit deinen neuen Änderungen fortschreitet, sei also vorsichtig. diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index 6e3748bd..c8c1c92e 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -1,26 +1,26 @@ [[_undoing]] === Ungewollte Änderungen rückgängig 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. +Es kommt sicherlich irgendwann der Zeitpunkt, an dem du eine Änderung rückgängig (engl. undo) machen willst. +Wir werden hier einige grundlegende Werkzeuge besprechen, mit denen du genau das tun kannst. +Sei vorsichtig, man kann diese Aktionen nicht immer rückgängig machen. +Das ist einer der wenigen Bereiche in Git, in denen du Arbeit verlieren könntest, wenn du etwas falsch machst. -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`: +Eines der häufigsten Undos tritt auf, wenn du zu früh committest und möglicherweise vergessen hast, einige Dateien hinzuzufügen, oder wenn du Fehler in deiner Commit-Nachricht hast. +Wenn du diesen Commit wiederholen möchtest, nimm zusätzlichen Änderungen vor, die du vergessen hast, stage Sie und committe erneut mit der Option `--amend`: [source,console] ---- $ git commit --amend ---- -Dieser Befehl übernimmt Ihre Staging-Area und verwendet sie für den Commit. -Wenn Sie seit Ihrem letzten Commit keine Änderungen vorgenommen haben (z.B. Sie führen diesen Befehl unmittelbar nach Ihrem vorherigen Commit aus), dann sieht Ihr Snapshot genau gleich aus; Sie ändern nur Ihre Commit-Nachricht. +Dieser Befehl übernimmt deine Staging-Area und verwendet sie für den Commit. +Wenn du seit deinem letzten Commit keine Änderungen vorgenommen hast (z.B. du führst diesen Befehl unmittelbar nach deinem vorherigen Commit aus), dann sieht dein Snapshot genau gleich aus; du änderst nur deine Commit-Nachricht. -Der gleiche Commit-Message-Editor wird aufgerufen, enthält aber bereits die Nachricht Ihres vorherigen Commits. -Sie können die Nachricht wie gewohnt bearbeiten, aber sie überschreibt den vorherigen Commit. +Der gleiche Commit-Message-Editor wird aufgerufen, enthält aber bereits die Nachricht deines vorherigen Commits. +Du kannst die Nachricht wie gewohnt bearbeiten, aber sie überschreibt den vorherigen Commit. -Wenn Sie zum Beispiel die Änderungen in einer Datei, die Sie zu dieser Übertragung hinzufügen wollten, vergessen haben, können Sie etwas Ähnliches durchführen: +Wenn du beispielsweise einen Commit durchführst und dann feststellst, dass du vergessen hast, eine Datei zu ändern, könntest du Folgendes tun: [source,console] ---- @@ -29,30 +29,30 @@ $ git add forgotten_file $ git commit --amend ---- -Sie erhalten am Ende einen einzigen Commit – der zweite Commit ersetzt die Ergebnisse des ersten. +Du erhälst am Ende einen einzigen Commit – der zweite Commit ersetzt die Ergebnisse des Ersten. [NOTE] ==== -Es ist wichtig zu verstehen, dass, wenn Sie Ihren letzten Commit ändern, Sie ihn weniger reparieren, als ihn komplett durch einen neuen, verbesserten Commit _ersetzen_. Der alte Commit wird aus dem Weg geräumt und der neue Commit an seine Stelle gesetzt. -Tatsächlich ist es so, als ob der letzte Commit nie stattgefunden hätte und er nicht mehr in Ihrem Repository-Verlauf auftaucht. +Es ist wichtig zu verstehen: wenn du deinen letzten Commit änderst, korrigierst du ihn nicht. Du _ersetzt_ ihn durch einen neuen, verbesserten Commit. Der alte Commit wird entfernt und der neue Commit an seine Stelle gesetzt. +Tatsächlich ist es so, als ob der letzte Commit nie stattgefunden hätte und er nicht mehr in deinem Repository-Verlauf auftaucht. -Der naheliegendste Nutzen für die Änderung von Commits besteht darin, kleine Verbesserungen an Ihrem letzten Commit vorzunehmen, ohne Ihren Repository-Verlauf mit Commit-Nachrichten der Form „Ups, vergessen, eine Datei hinzuzufügen“ oder „Verdammt, einen Tippfehler im letzten Commit behoben“ zu überladen. +Der naheliegendste Nutzen für die Änderung von Commits besteht darin, kleine Verbesserungen an deinem letzten Commit vorzunehmen, ohne dein Repository-Verlauf mit Commit-Nachrichten der Form „Ups, vergessen, eine Datei hinzuzufügen“ oder „Verdammt, einen Tippfehler im letzten Commit behoben“ zu überladen. ==== [NOTE] ==== -Ändern Sie nur lokale Commits, die noch nicht gepusht wurden. +Änderne nur lokale Commits, die noch nicht gepusht wurden. Das Ändern zuvor übertragener Commits und das forcierte pushen des Branches verursacht Probleme bei ihren Mitstreitern. -Weitere Informationen darüber, was dabei passiert und wie Sie es wieder gerade ziehen können, wenn Sie sich auf der Empfängerseite befinden, finden Sie unter <>. +Weitere Informationen darüber, was dabei passiert und wie du es wieder gerade ziehen kannst, wenn du dich auf der Empfängerseite befinden, findest du unter <>. ==== [[_unstaging]] ==== Eine Datei aus der Staging-Area entfernen -Die nächsten beiden Abschnitte erläutern, wie Sie mit Ihrer Staging-Area und den Änderungen des Arbeitsverzeichnisses arbeiten. -Der angenehme Nebeneffekt ist, dass der Befehl, mit dem Sie den Zustand dieser beiden Bereiche bestimmen, Sie auch daran erinnert, wie Sie Änderungen an ihnen rückgängig machen können. -Nehmen wir zum Beispiel an, Sie haben zwei Dateien geändert und möchten sie als zwei separate Änderungen übertragen, aber Sie geben versehentlich `git add *` ein und stellen sie dann beide in der Staging-Area bereit. -Wie können Sie eine der beiden aus der Staging-Area entfernen? +Die nächsten beiden Abschnitte erläutern, wie du mit deiner Staging-Area und den Änderungen des Arbeitsverzeichnisses arbeitest. +Der angenehme Nebeneffekt ist, dass der Befehl, mit dem du den Zustand dieser beiden Bereiche bestimmst, dich auch daran erinnert, wie du Änderungen an ihnen rückgängig machen kannst. +Nehmen wir zum Beispiel an, du hast zwei Dateien geändert und möchtest sie als zwei separate Änderungen übertragen, aber du gibst versehentlich `git add *` ein und stellst sie dann beide in der Staging-Area bereit. +Wie kannst du eine der beiden aus der Staging-Area entfernen? Der Befehl `git status` meldet: [source,console] @@ -68,7 +68,7 @@ Changes to be committed: ---- Direkt unter dem Text „Changes to be committed“, steht, dass man `git reset HEAD ...` verwenden soll, um die Staging-Area zu entleeren. -Lassen Sie uns also diesem Rat folgen und die Datei `CONTRIBUTING.md` aus der Staging-Area entfernen: +Lass uns also diesem Rat folgen und die Datei `CONTRIBUTING.md` aus der Staging-Area entfernen: [source,console] ---- @@ -94,18 +94,18 @@ Die Datei `CONTRIBUTING.md` ist modifiziert und wieder im Status unstaged überf [NOTE] ===== -Es stimmt, 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 du das `--hard` Flag mitgibst. In dem oben beschriebenen Szenario wird die Datei in Ihrem Arbeitsverzeichnis jedoch nicht angetastet, so dass er relativ sicher ist. ===== -Im Moment ist dieser Aufruf alles, was Sie über den Befehl `git reset` wissen müssen. -Wir werden viel ausführlicher darauf eingehen, was `reset` bewirkt und wie man es beherrscht, um wirklich interessante Aufgaben zu erledigen, siehe Kapitel 7 <>. +Im Moment ist dieser Aufruf alles, was du über den Befehl `git reset` wissen musst. +Wir werden viel ausführlicher darauf eingehen, was `reset` bewirkt und wie man damit umgeht, um wirklich interessante Aufgaben zu erledigen, siehe Kapitel 7 <>. ==== Ä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 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. +Was ist, wenn du feststellst, dass du deine Änderungen an der Datei `CONTRIBUTING.md` nicht behalten willst? +Wie kannst du sie in den Ursprungszustand zurücksetzen, so wie sie beim letzten Commit ausgesehen hat (oder anfänglich geklont wurde, oder wie auch immer du sie in dein Arbeitsverzeichnis bekommen hast)? +Glücklicherweise sagt dir `git status`, wie du das machen kannst. Im letzten Beispiel sieht die Unstaged-Area so aus: [source,console] @@ -117,8 +117,8 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -Git erklärt Ihnen, wie Sie die von Ihnen vorgenommenen Änderungen verwerfen können. -Lassen Sie es uns ausführen: +Git erklärt dir, wie du die von dir vorgenommenen Änderungen verwerfen kannst. +Lassen es uns ausführen: [source,console] ---- @@ -132,20 +132,20 @@ Changes to be committed: ---- -Wie Sie sehen, wurde die Änderungen rückgängig gemacht. +Wie du siehst, 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 gestagte Version ersetzt. -Verwenden Sie diesen Befehl nur, wenn Sie sich absolut sicher sind, dass Sie diese nicht gespeicherten lokalen Änderungen nicht benötigen. +Alle lokalen Änderungen, die du an dieser Datei vorgenommen hast, sind verloren – Git hat diese Datei einfach durch die zuletzt committete oder gestagte Version ersetzt. +Verwenden diesen Befehl nur, wenn du dir absolut sicher bist, dass du diese nicht gespeicherten lokalen Änderungen nicht benötigst. ===== -Wenn Sie die Änderungen, die Sie an dieser Datei gemacht haben, beibehalten möchten, sie aber vorerst aus dem Weg räumen möchten, sollten wir das Stashing und Branching in Kapitel 3 – <> durchgehen; das sind im Allgemeinen die besseren Methoden, um das zu erledigen. +Wenn du die Änderungen, die du an dieser Datei gemacht hast, beibehalten möchten, sie aber vorerst aus dem Weg räumen willst, sollten wir das Stashing und Branching in Kapitel 3 – <> durchgehen; das sind im Allgemeinen die besseren Methoden, um das zu erledigen. -Denken Sie daran, dass alles, was in Git _committet_ wird, fast immer wiederhergestellt werden kann. +Denke 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). -Wahrscheinlich werden Sie alles, was Sie verworfen und nie committet haben, nie wieder sehen. +Aber: alles, was du verworfen und nie committet hast, wirst du wahrscheinlich nie wieder sehen. [[undoing_git_restore]] ==== Änderungen mit git restore Rückgängig machen @@ -154,15 +154,15 @@ 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 dieser Vorgänge `git restore` anstelle von `git reset`. -Lassen Sie uns unsere Schritte wiederholen und die Dinge mit `git restore` anstelle von `git reset` rückgängig machen. +Lasse uns unsere Schritte wiederholen und die Dinge mit `git restore` anstelle von `git reset` rückgängig machen. ===== 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. -Angenommen, Sie haben zwei Dateien geändert und möchten sie als zwei separate Änderungen festschreiben. Sie geben jedoch versehentlich `git add *` ein und stellen beide bereit. -Wie können sie einen der beiden wieder unstagen? -Der Befehl `git status` zeigt es ihnen: +Die nächsten beiden Abschnitte zeigen, wie du an Änderungen in deinem Staging-Bereich und im Arbeitsverzeichnisses mit `git restore` arbeitest. +Das Schöne daran ist, dass der Befehl, mit dem du den Status dieser beiden Bereiche bestimmst, dir auch zeigt, wie du Änderungen an ihnen rückgängig machen kannst. +Angenommen, du hast zwei Dateien geändert und möchtest sie als zwei separate Änderungen committen. Du gibst jedoch versehentlich `git add *` ein und committest beide. +Wie kannst du eine der beiden wieder unstagen? +Der Befehl `git status` zeigt folgendes: [source,console] ---- @@ -199,9 +199,9 @@ Die Datei `CONTRIBUTING.md` ist modifiziert und wieder im Status unstaged überf ===== 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 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. +Was ist, wenn du merkst, dass du deine Änderungen an der Datei `CONTRIBUTING.md` nicht beibehalten willst? +Wie kannst du sie in den Ursprungszustand zurücksetzen, so wie sie beim letzten Commit ausgesehen hat (oder anfänglich geklont wurde, oder wie auch immer du sie in dein Arbeitsverzeichnis bekommen hast)? +Glücklicherweise sagt dir `git status`, wie du das machen kannst. Im letzten Beispiel sieht die Unstaged-Area so aus: [source,console] @@ -213,8 +213,8 @@ Changes not staged for commit: ---- -Git erklärt Ihnen, wie Sie die von Ihnen vorgenommenen Änderungen verwerfen können. -Lassen Sie es uns ausführen: +Git erklärt dir, wie du die von dir vorgenommene Änderungen verwerfen kannst. +Lassen es uns ausführen: [source,console] ---- @@ -230,6 +230,6 @@ Changes to be committed: [IMPORTANT] ===== Es ist wichtig zu verstehen, dass `git restore ` ein gefährlicher Befehl ist. -Alle lokalen Änderungen, die Sie an dieser Datei vorgenommen haben, sind weg. Git hat diese Datei 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. +Alle lokalen Änderungen, die du an dieser Datei vorgenommen hast, sind weg. Git hat diese Datei durch die zuletzt committete oder gestagte Version ersetzt. +Verwende diesen Befehl nur, wenn du dir absolut sicher bist, dass du diese nicht gespeicherten lokalen Änderungen nicht benötigst. ===== diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 68d72310..61868ac1 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -1,18 +1,18 @@ [[_viewing_history]] === Anzeigen der Commit-Historie -Nachdem Sie mehrere Commits erstellt haben, oder wenn Sie ein Repository mit einer bestehenden Commit-Historie geklont haben, werden Sie wahrscheinlich zurückschauen wollen, um zu erfahren, was geschehen ist. +Nachdem du mehrere Commits erstellt hast, oder wenn du ein Repository mit einer bestehenden Commit-Historie geklont hast, wirst du wahrscheinlich zurückschauen wollen, um zu erfahren, was geschehen ist. Das wichtigste und mächtigste Werkzeug dafür ist der Befehl `git log`. Diese Beispiele verwenden ein sehr einfaches Projekt namens „simplegit“. -Um das Projekt zu erstellen, führen Sie diesen Befehl aus: +Um das Projekt zu erstellen, führe diesen Befehl aus: [source,console] ---- $ git clone https://github.com/schacon/simplegit-progit ---- -Wenn Sie `git log` in diesem Projekt aufrufen, sollten Sie eine Ausgabe erhalten, die ungefähr so aussieht:(((Git Befehle, log))) +Wenn du `git log` in diesem Projekt aufrufst, solltest du eine Ausgabe erhalten, die ungefähr so aussieht:(((Git Befehle, log))) [source,console] ---- @@ -37,13 +37,13 @@ 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. +Wie du sehen kannst, 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 von Optionen stehen für den Befehl `git log` 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 dir exakt das anzuzeigen, wonach du suchst. Hier zeigen wir Ihnen einige der gängigsten. 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. +Du kannst auch die Anzahl der anzuzeigenden Protokolleinträge begrenzen, z.B. mit `-2` werden nur die letzten beiden Einträge dargestellt. [source,console] ---- @@ -91,8 +91,8 @@ index a0a60ae..47c6340 100644 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: +Du kannst auch mehrere Optionen zur Verdichtung der Ausgabe von `git log` verwenden. +Wenn du beispielsweise einige gekürzte Statistiken für jeden Commit sehen möchtest, kannst du die Option `--stat` verwenden: [source,console] ---- @@ -127,13 +127,13 @@ Date: Sat Mar 15 10:31:28 2008 -0700 3 files changed, 54 insertions(+) ---- -Wie Sie sehen können, gibt die Option `--stat` unter jedem Commit-Eintrag eine Liste der geänderten Dateien aus. Wie viele Dateien geändert wurden und wie viele Zeilen in diesen Dateien hinzugefügt und entfernt wurden. +Wie du sehen kannst, gibt die Option `--stat` unter jedem Commit-Eintrag eine Liste der geänderten Dateien aus, wie viele Dateien geändert wurden und wie viele Zeilen in diesen Dateien hinzugefügt und entfernt wurden. Sie enthält auch eine Zusammenfassung am Ende des Berichts. Eine weitere wirklich nützliche Option ist `--pretty`. Diese Option ändert das Format der Log-Ausgabe in ein anderes als das Standard-Format. -Ihnen stehen einige vorgefertigte Optionswerte zur Verfügung. -Der Wert `oneline` für diese Option gibt jeden Commit in einer einzigen Zeile aus, was besonders nützlich ist, wenn Sie sich viele Commits ansehen. +Dir stehen einige vorgefertigte Optionswerte zur Verfügung. +Der Wert `oneline` für diese Option gibt jeden Commit in einer einzigen Zeile aus, was besonders nützlich ist, wenn du dir viele Commits ansiehst. Darüber hinaus zeigen die Werte `short`, `full` und `fuller` die Ausgabe im etwa gleichen Format, allerdings mit mehr oder weniger Informationen an: [source,console] @@ -144,8 +144,8 @@ ca82a6dff817ec66f44342007202690a93763949 Change version number a11bef06a3f659402fe7563abf99ad00de2209e6 Initial commit ---- -Der interessanteste Wert ist `format`, mit dem Sie Ihr eigenes Log-Ausgabeformat festlegen können. -Dieses Verfahren ist besonders nützlich, wenn Sie Ausgaben für das maschinelle Parsen generieren – da Sie das Format explizit angeben, wissen Sie, dass es sich mit Updates von Git nicht ändert:(((Log formatieren))) +Der interessanteste Wert ist `format`, mit dem du dein eigenes Log-Ausgabeformat festlegen kannst. +Dieses Verfahren ist besonders nützlich, wenn du Ausgaben für das maschinelle Parsen generierst – da du das Format explizit angibst, weißt du, dass es sich mit Updates von Git nicht ändert:(((Log formatieren))) [source,console] ---- @@ -166,8 +166,8 @@ a11bef0 - Scott Chacon, 6 years ago : Initial commit | `%h` | gekürzter Commit-Hash | `%T` | Hash-Baum | `%t` | gekürzter Hash-Baum -| `%P` | Eltern-Hashes -| `%p` | gekürzte Eltern-Hashes +| `%P` | Parent-Hashes +| `%p` | gekürzte Parent-Hashes | `%an` | Name des Autors | `%ae` | E-Mail-Adresse des Autors | `%ad` | Erstellungs-Datum des Autors (Format berücksichtigt --date=option) @@ -179,13 +179,13 @@ a11bef0 - Scott Chacon, 6 years ago : Initial commit | `%s` | Thema (engl. Subject) |================================ -Sie fragen sich vielleicht, worin der Unterschied zwischen _Autor_ und _Committer_ besteht. +Du fragst dich vielleicht, worin der Unterschied zwischen _Autor_ und _Committer_ besteht. Der Autor ist die Person, die das Werk ursprünglich geschrieben hat, während der Committer die Person ist, die das Werk zuletzt bearbeitet hat. -Wenn Sie also einen Patch an ein Projekt senden und eines der Core-Mitglieder den Patch einbindet, erhalten Sie beide die Anerkennung – Sie als Autor und das Core-Mitglied als Committer. +Wenn du also einen Patch an ein Projekt sendest und eines der Core-Mitglieder den Patch einbindet, erhalten beide die Anerkennung – du als Autor und das Core-Mitglied als Committer. Wir werden diese Unterscheidung näher in Kapitel 5, <> erläutern. Die Optionswerte `oneline` und `format` sind vor allem bei einer anderen `log` Option mit der Bezeichnung `--graph` hilfreich. -Diese Option fügt ein schönes kleines ASCII-Diagramm hinzu, das Ihren Branch und den Merge-Verlauf zeigt: +Diese Option fügt ein schönes kleines ASCII-Diagramm hinzu, das deinen Branch und den Merge-Verlauf zeigt: [source,console] ---- @@ -219,17 +219,17 @@ Das sind nur einige einfache Optionen zur Ausgabe-Formatierung von `git log` – | `--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 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). +| `--graph` | Zeigt 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 du dein eigenes Format angeben kannst). | `--oneline` | Kurzform für die gleichzeitige Verwendung von `--pretty=oneline` und `--abbrev-commit`. |================================ ==== Einschränken der Log-Ausgabe -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. -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. +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 du nur eine Teilmenge von Commits anzeigen kannst. +Du hast eine solche Option bereits gesehen – die Option `-2`, die nur die letzten beiden Commits anzeigt. +Du kannst die Option `-` verwenden, wobei `n` eine beliebige ganze Zahl ist, um die letzten `n` Commits anzuzeigen. +In der Praxis wirst du das selten verwenden, da Git standardmäßig alle Ausgaben über einen Pager leitet, so dass du immer nur eine Seite der Log-Ausgabe siehst. 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: @@ -239,21 +239,18 @@ Dieser Befehl ruft z.B. die Liste der in den letzten beiden Wochen durchgeführt $ git log --since=2.weeks ---- -Dieser Befehl funktioniert mit vielen Formaten. Sie können ein bestimmtes Datum wie `"2008-01-15"` angeben, oder ein relatives Datum wie `"vor 2 Jahren 1 Tag 3 Minuten"`. +Dieser Befehl funktioniert mit vielen Formaten. Du kannst ein bestimmtes Datum wie `"2008-01-15"` angeben, oder ein relatives Datum wie `"vor 2 Jahren 1 Tag 3 Minuten"`. -Sie können die Liste auch nach Commits filtern, die bestimmten Suchkriterien entsprechen. -Mit der Option `--author` können Sie nach einem bestimmten Autor filtern und mit der Option `--grep` können Sie nach Schlüsselwörtern in den Übertragungsmeldungen suchen. +Du kannst die Liste auch nach Commits filtern, die bestimmten Suchkriterien entsprechen. +Mit der Option `--author` kannst du nach einem bestimmten Autor filtern und mit der Option `--grep` kannst du nach Schlüsselwörtern in den Übertragungsmeldungen suchen. [NOTE] ==== -Sie können mehr als eine Instanz der Suchkriterien `--author` und `--grep` angeben, -was die Commit-Ausgabe auf Commits beschränkt, die _jedem_ der `--author` Muster und _jedem_ der `--grep` Muster entsprechen; -durch Hinzufügen der Option `--all-match` wird die Ausgabe jedoch weiter auf diejenigen Commits beschränkt, -die _allen_ `--grep` Mustern entsprechen. +Du kannst mehr als eine Instanz der Suchkriterien `--author` und `--grep` angeben, was die Commit-Ausgabe auf Commits beschränkt, die _jedem_ der `--author` Muster und _jedem_ der `--grep` Muster entsprechen; durch Hinzufügen der Option `--all-match` wird die Ausgabe jedoch weiter auf diejenigen Commits beschränkt, 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 den letzten Commit suchen möchten, der einen Verweis auf eine bestimmte Funktion hinzugefügt oder entfernt hat, können Sie Folgendes aufrufen: +Ein weiterer wirklich hilfreicher Filter ist die Option `-S` (umgangssprachlich als Git's „Pickel“-Option bezeichnet), die eine Zeichenkette empfängt und nur die Commits anzeigt, die die Anzahl der Vorkommen dieser Zeichenkette geändert haben. +Wenn du beispielsweise den letzten Commit suchen möchtest, der einen Verweis auf eine bestimmte Funktion hinzugefügt oder entfernt hat, kannst du Folgendes aufrufen: [source,console] ---- @@ -261,7 +258,7 @@ $ git log -S function_name ---- 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. +Wenn du ein Verzeichnis oder einen Dateinamen angibst, kannst du 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. [source,console] @@ -285,7 +282,7 @@ In <> sind diese und einige andere gängige Optionen als Referenz | `-S` | Zeigt nur Commits an, die solchen Code hinzufügen oder entfernen, der mit der Zeichenkette übereinstimmt |================================ -Wenn Sie zum Beispiel sehen möchten, welche der Commits die Testdateien in der Git-Quellcode-Historie ändern, die von Junio Hamano im Monat Oktober 2008 committet wurden und keine Merge-Commits sind, können Sie in etwa folgendes aufrufen:(((Log filtern))) +Wenn du zum Beispiel sehen möchtest, welche der Commits die Testdateien in der Git-Quellcode-Historie ändern, die von Junio Hamano im Monat Oktober 2008 committet wurden und keine Merge-Commits sind, kannst du in etwa folgendes aufrufen:(((Log filtern))) [source,console] ---- @@ -304,6 +301,6 @@ Von den fast 40.000 Commits in der Git-Quellcode-Historie zeigt dieser Befehl di [TIP] .Die Anzeige von Merge-Commits unterdrücken ==== -Abhängig von dem in Ihrem Repository verwendeten Workflow ist es möglich, dass ein beträchtlicher Prozentsatz der Commits in Ihrer Log-Historie nur Merge-Commits sind, die in der Regel nicht sehr informativ sind. -Um zu vermeiden, dass die Anzeige von Merge-Commits Ihren Log-Verlauf überflutet, fügen Sie einfach die Log-Option `--no-merges` hinzu. +Abhängig von dem in deinem Repository verwendeten Workflow ist es möglich, dass ein beträchtlicher Prozentsatz der Commits in deiner Log-Historie nur Merge-Commits sind, die in der Regel nicht sehr informativ sind. +Um zu vermeiden, dass die Anzeige von Merge-Commits deinen Log-Verlauf überflutet, füge einfach die Log-Option `--no-merges` hinzu. ==== diff --git a/ch02-git-basics-chapter.asc b/ch02-git-basics-chapter.asc index f379882d..eef57661 100644 --- a/ch02-git-basics-chapter.asc +++ b/ch02-git-basics-chapter.asc @@ -1,10 +1,12 @@ [[ch02-git-basics-chapter]] == Git Grundlagen -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. +Falls du es eilig hast und du nur die Zeit hast ein einziges Kapitel dieses hervorragendes Buches durchzulesen, bist du hier genau richtig. + +Dieses Kapitel behandelt alle grundlegenden Befehle, die Du benötigst, um den großteil der Aufgaben zu erledigen, die mit Git erledigt werden müssen. +Am Ende des Kapitels solltest Du in der Lage sein, ein neues Repository anzulegen und zu konfigurieren, Dateien zu versionieren bzw. Sie aus der Versionsverwaltung zu entfernen, Dateien in die Staging-Area hinzuzufügen und einen Commit durchzuführen. + +Außerdem wird gezeigt, wie Du Git so konfigurieren kannst, dass es bestimmte Dateien und Dateimuster ignoriert, wie Du Fehler schnell und einfach rückgängig machen, wie Du die Historie eines Projekts durchsuchen und Änderungen zwischen Commits nachschlagen, und wie Du von einem Remote-Repository Daten herunter- bzw. dort hochladen kannst. include::book/02-git-basics/sections/getting-a-repository.asc[] @@ -22,5 +24,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 vornehmen und zur Staging-Area hinzufügen, Commits anlegen und die Historie aller Commits in einem Repository durchsuchen. +Du solltest jetzt in der Lage sein, die wichtigsten Git-Befehle einsetzen zu können. Folgendes sollte Dir 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.