diff --git a/C-git-commands.asc b/C-git-commands.asc index ee94f126..646995bc 100644 --- a/C-git-commands.asc +++ b/C-git-commands.asc @@ -10,10 +10,10 @@ Wir werden darüber reden, was jeder Befehl ganz allgemein tut, und dann darauf [TIP] ==== -Sie können lange Optionen abkürzen. -Zum Beispiel können Sie `git commit --a` eingeben, was sich so verhält, als ob Sie` git commit --amend` eingegeben hätten. +Du kannst lange Optionen abkürzen. +Zum Beispiel kannst du `git commit --a` eingeben, was sich so verhält, als ob du` git commit --amend` eingegeben hättest. Dies funktioniert nur, wenn die Buchstaben nach `--` für eine Option eindeutig sind. -Verwenden Sie beim Schreiben von Skripten die vollständige Option. +Verwende beim Schreiben von Skripten die vollständige Option. ==== === Setup und Konfiguration @@ -23,9 +23,9 @@ Es gibt zwei Befehle, die von den ersten Git-Aufrufen bis hin zum täglichen Opt ==== git config Git hat eine Standard-Methode, um Hunderte von Aufgaben zu erledigen. -Für viele dieser Aufgaben können Sie Git anweisen, sie auf eine andere Weise auszuführen oder Ihre persönlichen Einstellungen vorzunehmen. -Das reicht von der Angabe Ihres Namens bis hin zu bestimmten Terminal-Farbeinstellungen oder dem von Ihnen verwendeten Editor. -Bei diesem Befehl werden mehrere Dateien gelesen und beschrieben, so dass Sie Werte global oder bis zu einem bestimmten Repository festlegen können. +Für viele dieser Aufgaben kannst du Git anweisen, sie auf eine andere Weise auszuführen oder deine persönlichen Einstellungen vorzunehmen. +Das reicht von der Angabe deines Namens bis hin zu bestimmten Terminal-Farbeinstellungen oder dem von dir verwendeten Editor. +Bei diesem Befehl werden mehrere Dateien gelesen und beschrieben, so dass du Werte global oder bis zu einem bestimmten Repository festlegen kannst. Der `git config` Befehl wird in fast jedem Kapitel des Buches benutzt. @@ -33,18 +33,18 @@ In <> haben wir ihn verwendet, um unseren Name In <> haben wir gezeigt, wie man damit Kurzbefehle erstellen kann, die sich zu langen Optionssequenzen ausbauen, damit man sie nicht jedes Mal eingeben muss. -In <> haben wir ihn verwendet, um `--rebase` zum Standard der Anwendung zu machen, wenn Sie `git pull` ausführen. +In <> haben wir ihn verwendet, um `--rebase` zum Standard der Anwendung zu machen, wenn du `git pull` ausführst. -In <> haben wir damit einen Standard-Speicherservice für Ihre HTTP-Passwörter eingerichtet. +In <> haben wir damit einen Standard-Speicherservice für deine HTTP-Passwörter eingerichtet. -In <> haben wir gezeigt, wie Sie Smudge- und Clean-Filter für Inhalte einrichten können, die in Git ein- und ausgelesen werden. +In <> haben wir gezeigt, wie du Smudge- und Clean-Filter für Inhalte einrichten kannst, die in Git ein- und ausgelesen werden. Im Prinzip ist der gesamte Abschnitt <> dem Befehl gewidmet. [[ch_core_editor]] ==== git config core.editor commands -Neben den Konfigurationsanweisungen in <> können viele Editoren wie folgt eingerichtet werden: +Neben den Konfigurationsanweisungen in <> können viele Editoren wie folgt eingerichtet werden: .Exhaustive list of `core.editor` configuration commands [cols="1,2",options="header"] @@ -75,15 +75,15 @@ Neben den Konfigurationsanweisungen in <` ausführen. +Der `git help` Befehl zeigt dir zu einem beliebigen Befehl die gesamte Dokumentation, wie sie mit Git ausgeliefert wird. +Während wir in diesem Anhang nur einen groben Überblick über die meisten der gängigsten Befehle geben können, erhältst du jederzeit, für jeden Befehl eine komplette Aufstellung aller möglichen Optionen und Flags, wenn du `git help ` ausführst. -Wir haben den `git help` Befehl in <> vorgestellt und Ihnen gezeigt, wie Sie damit mehr Informationen über `git shell` in <> erhalten können. +Wir haben den `git help` Befehl in <> vorgestellt und dir gezeigt, wie du damit mehr Informationen über `git shell` in <> erhalten kannst. === Projekte importieren und erstellen @@ -93,11 +93,11 @@ Der eine ist, es aus einem bestehenden Repository im Netzwerk oder von irgendwo ==== git init -Um ein Verzeichnis zu übernehmen und es in ein neues Git-Repository umzuwandeln, so dass Sie die Versionskontrolle starten können, müssen Sie nur `git init` ausführen. +Um ein Verzeichnis zu übernehmen und es in ein neues Git-Repository umzuwandeln, so dass du die Versionskontrolle starten kannst, musst du nur `git init` ausführen. Wir haben das erstmals in <> präsentiert, wo wir zeigen, wie ein neues Repository erstellt wird, mit dem man dann arbeiten kann. -Wir besprechen in <> kurz, wie Sie den Standard-Branch-Namen „master“ ändern können. +Wir besprechen in <> kurz, wie du den Standard-Branch-Namen „master“ ändern kannst. Mit diesem Befehl erstellen wir für einen Server ein leeres Bare-Repository in <>. @@ -106,7 +106,7 @@ Zum Schluss werden wir in <> einige Deta ==== git clone Der `git clone` Befehl ist in Wahrheit ein Art Wrapper für mehrere andere Befehle. -Er erstellt ein neues Verzeichnis, wechselt dort hin und führt `git init` aus. So wird es zu einem leeren Git-Repository umgewandelt. Dann fügt er zu der übergebenen URL einen Remote (`git remote add`) hinzu (standardmäßig mit dem Namen `origin`). Er ruft ein `git fetch` von diesem Remote-Repository auf und holt mit `git checkout` den letzten Commit in Ihr Arbeitsverzeichnis. +Er erstellt ein neues Verzeichnis, wechselt dort hin und führt `git init` aus. So wird es zu einem leeren Git-Repository umgewandelt. Dann fügt er zu der übergebenen URL einen Remote (`git remote add`) hinzu (standardmäßig mit dem Namen `origin`). Er ruft ein `git fetch` von diesem Remote-Repository auf und holt mit `git checkout` den letzten Commit in dein Arbeitsverzeichnis. Der `git clone` Befehl wird an Dutzenden von Stellen im ganzen Buch verwendet, wir werden aber nur ein paar interessante Stellen auflisten. @@ -123,12 +123,12 @@ Obwohl der Befehl noch an vielen anderen Stellen im Buch verwendet wird, sind da === Einfache Snapshot-Funktionen -Für den grundlegenden Workflow der Erstellung von Inhalten und dem Committen in Ihren Verlauf gibt es nur wenige einfache Befehle. +Für den grundlegenden Workflow der Erstellung von Inhalten und dem Committen in deinen Verlauf gibt es nur wenige einfache Befehle. ==== git add Der `git add` Befehl fügt, für den nächsten Commit, Inhalte aus dem Arbeitsverzeichnis der Staging-Area (bzw. „Index“) hinzu. -Bei der Ausführung des Befehls `git commit` wird standardmäßig nur diese Staging-Area betrachtet, so dass mit `git add` festgelegt wird, wie Ihr nächster Commit-Schnappschuss aussehen soll. +Bei der Ausführung des Befehls `git commit` wird standardmäßig nur diese Staging-Area betrachtet, so dass mit `git add` festgelegt wird, wie dein nächster Commit-Schnappschuss aussehen soll. Dieser Befehl ist ein unglaublich wichtiges Kommando in Git und wird in diesem Buch mehrfach erwähnt oder verwendet. Wir werden kurz auf einige der einzigartigen Verwendungen eingehen, die es gibt. @@ -139,21 +139,21 @@ Wir besprechen in <>, wie man damit K Wir fahren in <> damit fort, bestimmte Teile einer modifizierten Datei interaktiv zur Staging-Area hinzuzufügen. -Schließlich emulieren wir ihn in <> auf einem unteren Level, so dass Sie sich vorstellen können, was er im Hintergrund bewirkt. +Schließlich emulieren wir ihn in <> auf einem unteren Level, so dass du dir vorstellen kannst, was er im Hintergrund bewirkt. ==== git status -Der `git status` Befehl wird Ihnen die verschiedenen Dateizustände in Ihrem Arbeitsverzeichnis und der Staging-Area anzeigen. +Der `git status` Befehl wird dir die verschiedenen Dateizustände in deinem Arbeitsverzeichnis und der Staging-Area anzeigen. Er zeigt welche Dateien modifiziert und nicht bereitgestellt und welche bereitgestellt (eng. staged), aber noch nicht committet sind. -In seiner üblichen Form werden Ihnen auch einige grundlegende Tipps gegeben, wie Sie Dateien zwischen diesen Stufen verschieben können. +In seiner üblichen Form werden dir auch einige grundlegende Tipps gegeben, wie du Dateien zwischen diesen Stufen verschieben kannst. Wir behandeln `status` zunächst in <>, sowohl in seinen grundlegenden als auch in seinen kompakten Formen. Im Buch wird so ziemlich alles angesprochen, was man mit dem Befehl `git status` machen kann. ==== git diff -Der `git diff` Befehl wird verwendet, wenn Sie Unterschiede zwischen zwei beliebigen Bäumen feststellen möchten. -Das könnte der Unterschied zwischen Ihrer Arbeitsumgebung und Ihrer Staging-Area (`git diff` an sich), zwischen Ihrer Staging-Area und Ihrem letzten Commit (`git diff --staged`) oder zwischen zwei Commits (`git diff master branchB`) sein. +Der `git diff` Befehl wird verwendet, wenn du Unterschiede zwischen zwei beliebigen Bäumen feststellen möchtest. +Das könnte der Unterschied zwischen deiner Arbeitsumgebung und deiner Staging-Area (`git diff` an sich), zwischen deiner Staging-Area und deinem letzten Commit (`git diff --staged`) oder zwischen zwei Commits (`git diff master branchB`) sein. In <> betrachten wir zunächst die grundsätzliche Anwendung von `git diff` und zeigen dort, wie man feststellen kann, welche Änderungen bereits der Staging-Area hinzugefügt wurden und welche noch nicht. @@ -167,7 +167,7 @@ Zuletzt verwenden wir ihn, um Submodul-Änderungen effektiv mit `--submodule` in ==== git difftool -Der Befehl `git difftool` startet ein externes Tool, um Ihnen den Unterschied zwischen zwei Bäumen zu zeigen, falls Sie einen anderen Befehl als das eingebaute `git diff` bevorzugen. +Der Befehl `git difftool` startet ein externes Tool, um dir den Unterschied zwischen zwei Bäumen zu zeigen, falls du einen anderen Befehl als das eingebaute `git diff` bevorzugst. Das erwähnen wir nur kurz in <>. @@ -189,8 +189,8 @@ Schließlich werfen wir einen Blick darauf, was der Befehl `git commit` im Hinte ==== git reset Der `git reset` Befehl wird in erster Linie verwendet, um Aktionen rückgängig zu machen, wie man am Kommando erkennen kann. -Er verschiebt den `HEAD` Pointer und ändert optional den `index` oder die Staging-Area und kann optional auch das Arbeitsverzeichnis ändern, wenn Sie `--hard` verwenden. -Bei falscher Verwendung der letzten Option kann mit diesem Befehl auch Arbeit verloren gehen, vergewissern Sie sich daher, dass Sie ihn verstehen, bevor Sie ihn verwenden. +Er verschiebt den `HEAD` Pointer und ändert optional den `index` oder die Staging-Area und kann optional auch das Arbeitsverzeichnis ändern, wenn du `--hard` verwendest. +Bei falscher Verwendung der letzten Option kann mit diesem Befehl auch Arbeit verloren gehen, vergewissere dich daher, dass du ihn verstehst, bevor du ihn verwendest. Wir befassen uns zunächst mit der einfachsten Anwendung von `git reset` in <>. Dort benutzen wir es, um eine Datei, die wir mit `git add` hinzu gefügt haben, wieder aus der Staging-Area zu entfernen. @@ -216,10 +216,10 @@ Wir beschreiben diesen Befehl nur kurz in <>. ==== git clean -Der Befehl `git clean` wird verwendet, um unerwünschte Dateien aus Ihrem Arbeitsverzeichnis zu entfernen. +Der Befehl `git clean` wird verwendet, um unerwünschte Dateien aus deinem Arbeitsverzeichnis zu entfernen. Dazu kann das Entfernen von temporären Build-Artefakten oder das Mergen von Konfliktdateien gehören. -Wir behandeln viele der Optionen und Szenarien, in denen Sie den clean-Befehl verwenden könnten in <>. +Wir behandeln viele der Optionen und Szenarien, in denen du den clean-Befehl verwenden könntest in <>. === Branching und Merging @@ -228,7 +228,7 @@ Es gibt nur eine Handvoll Befehle, die die meisten Branching- und Merging-Funkti ==== git branch Der `git branch` Befehl ist eigentlich so etwas wie ein Branch-Management-Tool. -Er kann die von Ihnen vorhandenen Branches auflisten, einen neuen Branch erstellen, Branches löschen und umbenennen. +Er kann die von dir vorhandenen Branches auflisten, einen neuen Branch erstellen, Branches löschen und umbenennen. Der größte Teil von <> ist dem Befehl `branch` gewidmet und wird im gesamten Kapitel verwendet. Wir stellen ihn zuerst in <> vor und betrachten die meisten seiner anderen Funktionen (das Auflisten und Löschen) in <>. @@ -239,7 +239,7 @@ Schließlich werden wir einige der Funktionen, die im Hintergrund ausgeführt we ==== git checkout -Der `git checkout` Befehl wird benutzt, um Branches zu wechseln und Inhalte in Ihr Arbeitsverzeichnis auszuchecken. +Der `git checkout` Befehl wird benutzt, um Branches zu wechseln und Inhalte in dein Arbeitsverzeichnis auszuchecken. Wir sind in <> zum ersten Mal dem `git branch` Befehl begegnet. @@ -257,26 +257,26 @@ Das `git merge` Tool wird benutzt, um einen oder mehrere Branches in den von in Es wird dann der aktuelle Branch zum Ergebnis des Merge-Vorgangs weitergeführt. Der Befehl `git merge` wurde zunächst in <> vorgestellt. -Obwohl er an verschiedenen Stellen im Buch verwendet wird, gibt es nur sehr wenige Variationen des Befehls `merge`. In der Regel nur `git merge ` mit dem Namen des einzelnen Branches, in dem Sie zusammenführen möchten. +Obwohl er an verschiedenen Stellen im Buch verwendet wird, gibt es nur sehr wenige Variationen des Befehls `merge`. In der Regel nur `git merge ` mit dem Namen des einzelnen Branches, in dem du zusammenführen möchtest. Wir haben am Ende von <> beschrieben, wie man ein Squashed Merge macht (bei dem Git die Arbeit zusammenführt, sich aber so verhält, als wäre es nur ein neuer Commit, ohne die Historie des Branches, in dem man zusammenführt, aufzuzeichnen). Wir haben in <> viel über den Merge-Prozess und -Befehl berichtet, einschließlich des Befehls `-Xignore-space-change` und des Flags `--abort`, um ein Merge-Problem abzubrechen. -Wir haben in <> gelernt, wie man Signaturen vor dem Zusammenführen überprüft, wenn Ihr Projekt GPG-Signaturen verwendet. +Wir haben in <> gelernt, wie man Signaturen vor dem Zusammenführen überprüft, wenn dein Projekt GPG-Signaturen verwendet. Schließlich haben wir in <> das Mergen von Sub-Trees kennengelernt. ==== git mergetool -Der `git mergetool` Befehl startet lediglich einen externen Merge-Helfer, falls Sie Probleme mit einer Zusammenführung in Git haben. +Der `git mergetool` Befehl startet lediglich einen externen Merge-Helfer, falls du Probleme mit einer Zusammenführung in Git hast. -Wir erwähnen ihn kurz in <> und gehen ausführlich in <> darauf ein, wie Sie Ihr eigenes externes Merge-Tool integrieren können. +Wir erwähnen ihn kurz in <> und gehen ausführlich in <> darauf ein, wie du dein eigenes externes Merge-Tool integrieren kannst. ==== git log Der `git log` Befehl wird verwendet, um den verfügbaren, aufgezeichneten Verlauf eines Projekts, ab des letzten Commit-Snapshots, rückwärts anzuzeigen. -Standardmäßig wird nur die Historie des Branchs angezeigt, in dem Sie sich gerade befinden, kann aber mit verschiedenen oder sogar mehreren Heads oder Branches belegt werden, mit denen Sie Schnittmengen haben können. +Standardmäßig wird nur die Historie des Branchs angezeigt, in dem du dich gerade befindest. Er kann aber mit verschiedenen oder sogar mehreren Heads oder Branches belegt werden, mit denen du Schnittmengen bilden kannst. Er wird häufig verwendet, um Unterschiede zwischen zwei oder mehr Branches auf der Commit-Ebene anzuzeigen. Dieses Kommando wird in fast jedem Kapitel des Buches verwendet, um die Verlaufshistorie eines Projekts zu demonstrieren. @@ -290,7 +290,7 @@ In <> und <> In <> gehen wir ausführlicher darauf ein. In <> und <> wird das Format `branchA...branchB` und die Syntax `--left-right` verwendet, um zu sehen, was in dem einen oder anderen Branch vorhanden ist, aber nicht in beiden. -In <> untersuchen wir auch, wie Sie die Option `--merge` verwenden können, um beim Debugging von Merge-Konflikten zu helfen, sowie die Option `--cc`, um Merge-Commit-Konflikte in Ihrem Verlauf zu betrachten. +In <> untersuchen wir auch, wie du die Option `--merge` verwenden kannst, um beim Debugging von Merge-Konflikten zu helfen, sowie die Option `--cc`, um Merge-Commit-Konflikte in deinem Verlauf zu betrachten. In <> benutzen wir die Option `-g`, um den Git-RefLog über dieses Tool anzuzeigen, anstatt eine Branch-Überquerung durchzuführen. @@ -300,7 +300,7 @@ In <> sehen wir, wie man mit ==== git stash -Der Befehl `git stash` wird verwendet, um nicht fertiggestellte Arbeit vorübergehend zu speichern, um Ihr Arbeitsverzeichnis aufzuräumen, ohne unfertige Arbeit auf einem Branch committen zu müssen. +Der Befehl `git stash` wird verwendet, um nicht fertiggestellte Arbeit vorübergehend zu speichern, um dein Arbeitsverzeichnis aufzuräumen, ohne unfertige Arbeit auf einem Branch committen zu müssen. Im Wesentlichen wird dieses Thema in <> vollständig behandelt. @@ -317,11 +317,11 @@ Wir behandeln in <> auch, wie man einen GPG-signierten === Projekte gemeinsam nutzen und aktualisieren Es gibt nicht besonders viele Befehle in Git, die auf das Netzwerk zugreifen, fast alle Befehle arbeiten mit der lokalen Datenbank. -Wenn Sie Ihre Arbeit freigeben oder Änderungen von anderswo beziehen wollen, gibt es eine kleine Anzahl von Befehlen, die sich mit Remote-Repositorys beschäftigen. +Wenn du deine Arbeit freigeben oder Änderungen von anderswo beziehen willst, gibt es eine kleine Anzahl von Befehlen, die sich mit Remote-Repositorys beschäftigen. ==== git fetch -Der Befehl `git fetch` kommuniziert mit einem entfernten Repository und holt alle Informationen, die sich in diesem Repository befinden, aber nicht in Ihrem aktuellen Repository und speichert sie in Ihrer lokalen Datenbank. +Der Befehl `git fetch` kontaktiert das entfernte Repository und lädt alle neuen Commits, Branches und Tags herunter, die in deinem lokalen Repository noch nicht vorhanden sind. Diese Informationen werden in der lokalen Git-Datenbank gespeichert, ohne deinen aktuellen Arbeitsstand zu verändern. Wir sehen uns diesen Befehl zunächst in <> an und betrachten anschließend weitere Beispiele für seine Verwendung in <>. @@ -333,15 +333,15 @@ Wir richten in <> eigene Referenzspezifikationen ei ==== git pull -Der `git pull` Befehl ist im Grunde eine Kombination aus den `git fetch` und `git merge` Befehlen, wobei Git von dem angegebenen Remote holt und dann sofort versucht, es in den Branch, auf dem Sie gerade sind, zu integrieren. +Der Befehl `git pull` kombiniert die Funktionen von `git fetch` und `git merge`: Git ruft die neuesten Änderungen aus dem angegebenen Remote-Repository ab und versucht anschließend, diese direkt in den aktuellen Branch zu integrieren. -Wir führen ihn in <> ein und zeigen in <> auf, was alles gemerged wird, wenn Sie ihn benutzen. +Wir führen ihn in <> ein und zeigen in <> auf, was alles gemerged wird, wenn du ihn benutzt. -Wir erfahren in <> auch, wie Sie damit bei Schwierigkeiten während des Rebasings umgehen können. +Wir erfahren in <> auch, wie du damit bei Schwierigkeiten während des Rebasings umgehen kannst. Wir zeigen in <>, wie man ihn mit einer URL verwendet, um Änderungen einmalig einzupflegen. -Schließlich erwähnen wir in <> noch kurz, wie Sie die Option `--verify-signatures` verwenden können, um beim Abrufen/Pullen von Commits überprüfen können, ob diese mit GPG signiert wurden. +Schließlich erwähnen wir in <> noch kurz, wie du die Option `--verify-signatures` verwenden kannst, um beim Abrufen/Pullen von Commits überprüfen kannst, ob diese mit GPG signiert wurden. ==== git push @@ -353,22 +353,22 @@ Hier beschreiben wir die grundlegenden Aspekte des Pushens einer Branch zu einem In <> gehen wir ein wenig detaillierter auf das Pushen bestimmter Branches ein und in <> sehen wir, wie man Tracking-Branches einrichtet, um dorthin automatisch zu pushen. In <> benutzen wir die Option `--delete`, um einen Branch auf dem Server mit `git push` zu löschen. -Im Kapitel 5 <> können Sie einige Beispiele für die Verwendung von `git push` finden,wie Sie Ihre Arbeit an Branches mit mehreren Remotes teilen können. +Im Kapitel 5 <> kannst du einige Beispiele für die Verwendung von `git push` finden,wie du deine Arbeit an Branches mit mehreren Remotes teilen kannst. -Wir sehen in <>, wie Sie diesen Befehl benutzen können, um Tags, die Sie mit der `--tags` Option erstellt haben, gemeinsam zu nutzen. +Wir sehen in <>, wie du diesen Befehl benutzen kannst, um Tags, die du mit der `--tags` Option erstellt hast, gemeinsam zu nutzen. In <> verwenden wir die Option `--recurse-submodules`, um zu überprüfen, ob alle unsere Submodule funktionieren, bevor wir zum Hauptprojekt pushen, was bei der Verwendung von Submodulen sehr hilfreich sein kann. In <> sprechen wir kurz über den `pre-push` Hook, ein Skript, das wir so einrichten können, dass es vor dem Abschluss eines Pushs ausgeführt wird, um zu prüfen, ob es zulässig sein sollte, zu pushen. Schließlich betrachten wir in <> das Pushen mit einer vollständigen Referenzspezifikation (engl. refspec) anstelle der allgemeinen Abkürzungen, die normalerweise verwendet werden. -Das kann Ihnen helfen, sehr spezifisch zu entscheiden, welche Arbeit Sie teilen möchten. +Das kann dir helfen, sehr spezifisch zu entscheiden, welche Arbeit du teilen möchtest. ==== git remote -Der Befehl `git remote` ist ein Management-Tool für die Verwaltung Ihrer Datensätze in Remote-Repositorys. -Er erlaubt Ihnen, lange URLs als kurze Handles zu speichern, wie z.B. „origin“, damit Sie diese nicht ständig abtippen müssen. -Sie können auch mehrere solcher Adressen einrichten und der Befehl `git remote` wird verwendet, um sie hinzuzufügen, zu ändern oder zu löschen. +Der Befehl `git remote` ist ein Management-Tool für die Verwaltung deiner Datensätze in Remote-Repositorys. +Er erlaubt dir, lange URLs als kurze Handles zu speichern, wie z.B. „origin“, damit du diese nicht ständig abtippen musst. +Du kannst auch mehrere solcher Adressen einrichten und der Befehl `git remote` wird verwendet, um sie hinzuzufügen, zu ändern oder zu löschen. Dieser Befehl wird ausführlich in <> behandelt, einschließlich des Auflistens, Hinzufügens, Entfernens und Umbenennens. @@ -393,7 +393,7 @@ Dieser Befehl wird nur in <> erwähnt und dort a ==== git show Der Befehl `git show` kann ein Git-Objekt auf eine einfache und für den Benutzer lesbare Weise darstellen. -Normalerweise würden Sie diesen Befehl verwenden, um die Informationen über ein Tag oder einen Commit anzuzeigen. +Normalerweise würdest du diesen Befehl verwenden, um die Informationen über ein Tag oder einen Commit anzuzeigen. Wir verwenden ihn erstmals in <>, um annotierte Tag-Informationen anzuzeigen. @@ -418,7 +418,7 @@ Wir verwenden `git describe` in <> und <> vollständig dokumentiert und nur i ==== git blame Der Befehl `git blame` kommentiert die Zeilen einer Datei, bei denen ein Commit zuletzt eine Änderung vorgenommen hat. Zudem wird vermerkt, wer der Autor des Commits ist. -Das hilft Ihnen, denjenigen zu ermitteln, der weitere Angaben zu einem bestimmten Abschnitt Ihres Codes machen kann. +Das hilft dir, denjenigen zu ermitteln, der weitere Angaben zu einem bestimmten Abschnitt deines Codes machen kann. Er wird in <> behandelt und nur in diesem Kapitel beschrieben. ==== git grep -Der Befehl `git grep` kann Ihnen bei der Suche nach einer beliebigen Zeichenfolge oder einem regulären Ausdruck in irgendeiner der Dateien Ihres Quellcodes behilflich sein, selbst in älteren Fassungen Ihres Projekts. +Der Befehl `git grep` kann dir bei der Suche nach einer beliebigen Zeichenfolge oder einem regulären Ausdruck in irgendeiner der Dateien deines Quellcodes behilflich sein, selbst in älteren Fassungen deines Projekts. Er wird in <> behandelt und nur dort beschrieben. === Patchen bzw. Fehlerkorrektur Ein paar Befehle in Git fokussieren sich um die konzeptionelle Überlegung, wie Commits sich in Bezug auf die Änderungen verhalten, die sie einführen, wenn die Commit-Serie eine Reihe von Patches wäre. -Diese Befehle helfen Ihnen, Ihre Branches auf dieser Grundlage zu organisieren. +Diese Befehle helfen dir, deine Branches auf dieser Grundlage zu organisieren. ==== git cherry-pick -Die `git cherry-pick` Anweisung wird benutzt, um die Änderung, die in einem einzelnen Git-Commit vorgenommen wurde, als neuen Commit auf dem Branch, auf dem Sie sich gerade befinden, erneut vorzunehmen. +Die `git cherry-pick` Anweisung wird benutzt, um die Änderung, die in einem einzelnen Git-Commit vorgenommen wurde, als neuen Commit auf dem Branch, auf dem du dich gerade befindest, erneut vorzunehmen. Das kann sinnvoll sein, um nur ein oder zwei Commits aus einem Branch individuell zu übernehmen, anstatt sie in den Branch einzubringen, der sämtliche geänderten Daten enthält. Das „Kirschenpflücken“ (engl. cherry picking) wird in <> beschrieben und demonstriert. @@ -459,7 +459,7 @@ Er ermittelt eine Reihe von Commits und nimmt sie dann nacheinander, in der glei Rebasing wird ausführlich in <> behandelt, einschließlich der Problematik bei der Zusammenarbeit im Zusammenhang mit Rebasing von bereits veröffentlichten Branches. -Wir verwenden ihn bei einem praktischen Beispiel in <> für die Aufteilung Ihres Verlaufs in zwei getrennte Repositorys, wobei auch das Flag `--onto` benutzt wird. +Wir verwenden ihn bei einem praktischen Beispiel in <> für die Aufteilung deines Verlaufs in zwei getrennte Repositorys, wobei auch das Flag `--onto` benutzt wird. In <> kommt es bei einem Rebase zu einem Merge-Konflikt. @@ -468,44 +468,44 @@ In <> verwenden wir ihn auch in einem interak ==== git revert Der `git revert` Befehl ist im Prinzip ein umgekehrter `git cherry-pick`. -Er erzeugt einen neuen Commit, der das genaue Gegenteil der Änderung bewirkt, die in dem Commit, auf den Sie gerade zugreifen, eingeführt wurde, d.h. er macht ihn rückgängig. +Er erzeugt einen neuen Commit, der das genaue Gegenteil der Änderung bewirkt, die in dem Commit, auf den du gerade zugreifst, eingeführt wurde, d.h. er macht ihn rückgängig. In <> verwenden wir diesen Befehl, um einen Merge-Commit rückgängig zu machen. === E-mails Viele Git-Projekte, einschließlich Git selbst, werden vollständig über Mailinglisten verwaltet. -Git hat eine Reihe von integrierten Tools, die diesen Prozess erleichtern. Angefangen bei der Erstellung von Patches, die Sie einfach per E-Mail versenden können, bis hin zur Anwendung dieser Patches aus einem E-Mail-Postfach heraus. +Git hat eine Reihe von integrierten Tools, die diesen Prozess erleichtern. Angefangen bei der Erstellung von Patches, die du einfach per E-Mail versenden kannst, bis hin zur Anwendung dieser Patches aus einem E-Mail-Postfach heraus. ==== git apply Der Befehl `git apply` wendet einen Patch an, der mit dem Befehl `git diff` oder auch mit GNU diff erstellt wurde. Das ist vergleichbar mit dem, was der Befehl `patch` macht, mit ein paar kleinen Unterschieden. -In <> zeigen wir Ihnen die Handhabung und die Bedingungen, unter denen Sie das tun sollten. +In <> zeigen wir dir die Handhabung und die Bedingungen, unter denen du das tun solltest. ==== git am Der Befehl `git am` wird für die Übernahme von Patches aus einem Email-Postfach verwendet, konkret aus einem mbox-formatierten Email-Postfach. -Dadurch können Sie Patches per E-Mail erhalten und sie einfach in Ihrem Projekt einsetzen. +Dadurch kannst du Patches per E-Mail erhalten und sie einfach in deinem Projekt einsetzen. In <> haben wir die Bedienung und den Umgang mit `git am` behandelt, einschließlich der Optionen `--resolved`, `-i` und `-3`. -Es gibt auch eine Reihe von Hooks, die Sie zur Vereinfachung des Workflows rund um `git am` verwenden können, die alle in <> behandelt werden. +Es gibt auch eine Reihe von Hooks, die du zur Vereinfachung des Workflows rund um `git am` verwenden kannst, die alle in <> behandelt werden. Wir verwenden ihn in <> ebenfalls, um patch-formatierte Anpassungen in GitHub Pull-Request anzuwenden. ==== git format-patch -Der Befehl `git format-patch` wird verwendet, um eine Reihe von Patches im mbox-Format zu erzeugen, die Sie an eine Mailingliste, korrekt formatiert, senden können. +Der Befehl `git format-patch` wird verwendet, um eine Reihe von Patches im mbox-Format zu erzeugen, die du an eine Mailingliste, korrekt formatiert, senden kannst. -Wir zeigen anhand eines Beispiels in <> wie Sie mit dem Tool `git format-patch` zu einem Projekt beitragen können . +Wir zeigen anhand eines Beispiels in <> wie du mit dem Tool `git format-patch` zu einem Projekt beitragen kannst . ==== git imap-send Der Befehl `git imap-send` lädt eine mit `git format-patch` erzeugte Mailbox in einen IMAP-Entwurfsordner hoch. -Wir betrachten in <> ein Beispiel, wie Sie durch Senden von Patches mit dem Tool `git imap-send` zu einem Projekt beitragen können. +Wir betrachten in <> ein Beispiel, wie du durch Senden von Patches mit dem Tool `git imap-send` zu einem Projekt beitragen kannst. ==== git send-email @@ -516,7 +516,7 @@ Wir sehen in <> ein Beispiel für eine ==== git request-pull Der Befehl `git request-pull` wird lediglich dazu verwendet, einen exemplarischen Nachrichtentext zu generieren, der an eine Person per E-Mail gesendet werden kann. -Wenn Sie einen Branch auf einem öffentlichen Server haben und jemanden wissen lassen wollen, wie man diese Änderungen integriert, ohne dass die Patches per E-Mail verschickt werden, können Sie diesen Befehl ausführen und die Ausgabe an die Person senden, die die Änderungen einspielen soll. +Wenn du einen Branch auf einem öffentlichen Server hast und jemanden wissen lassen willst, wie man diese Änderungen integriert, ohne dass die Patches per E-Mail verschickt werden, kannst du diesen Befehl ausführen und die Ausgabe an die Person senden, die die Änderungen einspielen soll. Wir zeigen in <>, wie man `git request-pull` verwendet, um eine Pull-Nachricht zu erzeugen. @@ -526,26 +526,26 @@ Git enthält einige Kommandos mit denen eine Integration mit anderen Versionskon ==== git svn -Mit Hilfe der Funktion `git svn` kann man als Client mit dem Versionskontrollsystem Subversion kommunizieren. -Das bedeutet, dass Sie Git zum Auschecken von und zum Committen an einen Subversion-Server verwenden können. +Der Befehl `git svn` wird verwendet, um als Client mit dem Versionskontrollsystem Subversion (SVN) zu kommunizieren. +Das bedeutet, du kannst Git verwenden, um ein Repository von einem Subversion-Server auszuchecken und Änderungen wieder dorthin zu übertragen (commiten). Dieser Befehl wird in <> ausführlich erläutert. ==== git fast-import -Für andere Versionskontrollsysteme oder den Import aus beinahe jedem Format können Sie `git fast-import` verwenden. So können Sie das andere Format einfach auf etwas umwandeln, das Git problemlos verarbeiten kann. +Für andere Versionskontrollsysteme oder den Import aus beinahe jedem Format kannst du `git fast-import` verwenden. So kannst du das andere Format einfach auf etwas umwandeln, das Git problemlos verarbeiten kann. In <> wird diese Funktion eingehend untersucht. === Administration -Wenn Sie ein Git-Repository verwalten oder etwas in größerem Umfang reparieren müssen, bietet Git eine Reihe von Verwaltungsbefehlen, die Sie dabei unterstützen. +Wenn du ein Git-Repository verwaltest oder etwas in größerem Umfang reparieren musst, bietet Git eine Reihe von Verwaltungsbefehlen, die dich dabei unterstützen. ==== git gc -Der Befehl `git gc` führt „garbage collection“ (dt. Speicherbereinigung) auf Ihrem Repository aus. Er entfernt unnötige Dateien aus Ihrer Datenbank und packt die verbleibenden Dateien in ein effizientes Format. +Der Befehl `git gc` führt „garbage collection“ (dt. Speicherbereinigung) auf deinem Repository aus. Er entfernt unnötige Dateien aus deiner Datenbank und packt die verbleibenden Dateien in ein effizientes Format. -Dieser Befehl läuft normalerweise im Hintergrund ab. Wenn Sie wollen, können Sie ihn aber auch manuell ausführen. +Dieser Befehl läuft normalerweise im Hintergrund ab. Wenn du willst, kannst du ihn aber auch manuell ausführen. Wir werden einige Beispiele dafür in <> näher betrachten. ==== git fsck @@ -556,7 +556,7 @@ Wir beschreiben ihn nur kurz in <>, um nach v ==== git reflog -Der Befehl `git reflog` untersucht ein Log-Protokoll, in dem alle Heads Ihrer Branches aufgezeichnet sind, während Sie daran gearbeitet haben. So können Sie Commits finden, die Sie durch das Umschreiben der Historie verloren haben könnten. +Der Befehl `git reflog` untersucht ein Log-Protokoll, in dem alle Heads deiner Branches aufgezeichnet sind, während du daran gearbeitet hast. So kannst du Commits finden, die du durch das Umschreiben der Historie verloren haben könntest. Wir beschäftigen uns mit diesem Befehl hauptsächlich in <>. Dort zeigen wir die normale Benutzung und die Verwendung von `git log -g`, um die gleichen Informationen so zu formatieren damit sie wie mit der `git log` Ausgabe aussehen. @@ -564,7 +564,7 @@ Wir stellen in <> ein praktisches Beispiel f ==== git filter-branch -Der Befehl `git filter-branch` dient dazu, eine Vielzahl von Commits nach bestimmten Kriterien umzuschreiben. Sie können beispielsweise eine Datei überall entfernen oder das gesamte Repository in ein einziges Unterverzeichnis filtern, zum Extrahieren eines Projekts. +Der Befehl `git filter-branch` wird verwendet, um eine große Anzahl von Commits nach bestimmten Mustern neu zu schreiben – zum Beispiel, um eine Datei aus der gesamten Historie zu entfernen oder das Repository auf ein bestimmtes Unterverzeichnis zu reduzieren, um daraus ein separates Projekt zu erstellen. In <> erklären wir den Befehl und untersuchen verschiedene Optionen wie `--commit-filter`, `--subdirectory-filter` und `--tree-filter`. @@ -577,7 +577,7 @@ Es gibt zudem eine ganze Reihe von Basisbefehlen, auf die wir in diesem Buch ges Zuerst begegnen wir `ls-remote` in <>, das wir zum Betrachten der Rohdaten auf dem Server verwenden. -Wir verwenden `ls-files` in <>, <> und <>, um einen groben Einblick in Ihre Staging-Area zu erhalten. +Wir verwenden `ls-files` in den Abschnitten <>, <> und <>, um einen direkteren bzw. roheren Blick darauf zu werfen, wie dein Staging-Bereich aussieht. Wir beziehen uns in <> auch auf `rev-parse`, um so gut wie jede beliebige Zeichenkette zu verwenden und sie in ein SHA-1 Objekt zu konvertieren. diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index 99945692..9d7640f9 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -7,7 +7,7 @@ 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 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`: +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] ---- diff --git a/book/03-git-branching/sections/workflows.asc b/book/03-git-branching/sections/workflows.asc index bcf2c673..4cf18d29 100644 --- a/book/03-git-branching/sections/workflows.asc +++ b/book/03-git-branching/sections/workflows.asc @@ -10,8 +10,8 @@ Da Git ein einfaches 3-Wege-Merge verwendet, ist mehrmaliges Zusammenführen von Das bedeutet, du kannst mehrere Branches haben, die immer offen sind und die du für unterschiedliche Stadien deines Entwicklungszyklus verwendest; du kannst sie regelmäßig mit anderen zusammenführen. Viele Git-Entwickler folgen einem Workflow, welcher den Ansatz verfolgt, nur stabilen Code im `master` Branch zu haben – möglicherweise auch nur Code, der released wurde oder werden soll. -Sie haben einen weiteren parallele Branches namens `develop` oder `next`, auf denen Sie arbeiten oder die Sie für Stabilitätstests nutzen. Diese sind nicht zwangsläufig stabil, aber wann immer sie einen stabilen Zustand erreichen, können sie mit dem `master` Branch zusammengeführt werden. -Sie werden genutzt, um Features (kurzlebige Branches, wie der früher genutzte `iss53` Branch) einfließen zu lassen, wenn diese fertiggestellt sind. Damit wird sichergestellt, dass sie alle Tests bestehen und keine Fehler einführen. +Sie haben einen weiteren parallelen Branches namens `develop` oder `next`, auf denen Sie arbeiten oder den Sie für Stabilitätstests nutzen. Dieser ist nicht zwangsläufig stabil, aber wann immer er einen stabilen Zustand erreicht, kann er in dem `master` Branch gemerged werden. +Er wird genutzt, um Features (kurzlebige Branches, wie der früher genutzte `iss53` Branch) einfließen zu lassen, wenn diese fertiggestellt sind. Damit wird sichergestellt, dass er alle Tests besteht und keine Fehler einführt. Eigentlich reden wir gerade über Zeiger, die sich in der Reihe der Commits, die du durchführst, vorwärts bewegen. Die stabilen Branches sind weiter hinten und die allerneuesten Branches sind weiter vorn im Verlauf. @@ -27,7 +27,7 @@ image::images/lr-branches-2.png[„Silo“-Modell eines Branchings mit zunehmend Du kannst das für mehrere Stabilitätsgrade einrichten. Einige größere Projekte haben auch einen Branch `proposed` (vorgeschlagen) oder `pu` (proposed updates – vorgeschlagene Updates), in welchem Branches integriert sind, die vielleicht noch nicht bereit sind in den Branch `next` oder `master` einzufließen. -Die Idee dahinter ist, dass Ihre Branches verschiedene Stabilitäts-Level repräsentieren. Sobald sie einen Grad höherer Stabilität erreichen, werden sie mit dem nächsthöheren Branch zusammengeführt. +Die Idee dahinter ist, dass deine Branches verschiedene Stabilitäts-Level repräsentieren. Sobald sie einen Grad höherer Stabilität erreichen, werden sie mit dem nächsthöheren Branch zusammengeführt. Zur Erinnerung: Langfristig verschiedene Branches parallel laufen zu lassen, ist nicht notwendig, aber oft hilfreich. Insbesondere dann, wenn man es mit sehr großen oder komplexen Projekten zu tun hat. [[_topic_branch]] diff --git a/book/06-github/sections/4-managing-organization.asc b/book/06-github/sections/4-managing-organization.asc index 5362b95e..e38fa039 100644 --- a/book/06-github/sections/4-managing-organization.asc +++ b/book/06-github/sections/4-managing-organization.asc @@ -24,7 +24,7 @@ Als Eigentümer in einer Organisation hast du beim Forken eines Repository die W Wenn du neue Repositorys erstellst, kannst du diese entweder unter deinem persönlichen Konto oder unter dem einer der Organisationen erstellen, deren Eigentümer du bist. Du „beobachtest“ (engl. watch) auch automatisch jedes neue Repository, das unter diesen Unternehmen erstellt wird. -Wie in <<_personal_avatar,Ihr Avatar-Bild>> gezeigt, kannst du ein Symbol-Bild für deine Organisation hochladen, um sie ein wenig zu personalisieren. +Wie in <<_personal_avatar,Dein Avatar-Bild>> gezeigt, kannst du ein Symbol-Bild für deine Organisation hochladen, um sie ein wenig zu personalisieren. Wie bei persönlichen Konten hast du auch eine Startseite für die Organisation, die alle deine Repositorys auflistet und von anderen eingesehen werden kann. Lass uns jetzt einige der Punkte ansprechen, die mit einem Organisationskonto etwas anders sind. diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index 438f01ac..ae71a6f3 100644 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -134,7 +134,7 @@ Wenn du diese Konfiguration nutzt, wird Git die komplette Ausgabe aller Befehle ===== `user.signingkey` (((GPG))) -Wenn du signierte und annotierte Tags erstellst (wie in Kapitel 7, <> beschrieben), erleichtert die Definition deines GPG-Signierschlüssels in der Konfigurations-Einstellung die Arbeit. +Wenn du signierte und annotierte Tags erstellst (wie in Kapitel 7, <> beschrieben), erleichtert die Definition deines GPG-Signierschlüssels in der Konfigurations-Einstellung die Arbeit. Stelle deine Schlüssel-ID so ein: [source,console] diff --git a/book/B-embedding-git/sections/jgit.asc b/book/B-embedding-git/sections/jgit.asc index c68cea5c..da44ff63 100644 --- a/book/B-embedding-git/sections/jgit.asc +++ b/book/B-embedding-git/sections/jgit.asc @@ -146,7 +146,7 @@ for (Ref ref : remoteRefs) { Das ist ein typisches Muster mit der Git-Klasse. Die Methoden geben ein Befehlsobjekt zurück, mit dem du Methodenaufrufe verketten kannst, um Parameter zu setzen, die beim Aufruf von `.call()` ausgeführt werden. Hier befragen wir den `origin` Remote nach Tags, nicht nach Heads. -Beachten Sie auch die Verwendung des Objekts `CredentialsProvider` zur Authentifizierung. +Beachte auch die Verwendung des Objekts `CredentialsProvider` zur Authentifizierung. Viele andere Befehle sind über die Git-Klasse verfügbar, einschließlich, aber nicht beschränkt auf `add`, `blame`, `commit`, `clean`, `push`, `rebase`, `revert` und `reset`. diff --git a/book/B-embedding-git/sections/libgit2.asc b/book/B-embedding-git/sections/libgit2.asc index 599c0a55..d72e2397 100644 --- a/book/B-embedding-git/sections/libgit2.asc +++ b/book/B-embedding-git/sections/libgit2.asc @@ -141,7 +141,7 @@ _Beachte, dass Fehler zwar erfasst, aber nicht bearbeitet werden. Wir hoffen, da <4> Ein Repository öffnen und so einrichten, dass es unsere ODB zum Suchen von Objekten verwendet. Aber was ist das für ein `git_odb_backend_mine`? -Nun, das ist der Konstruktor für Ihre eigene ODB-Implementation. Du kannst dort machen, was immer du willst, solange du die `git_odb_backend` Struktur richtig eingibst. +Nun, das ist der Konstruktor für deine eigene ODB-Implementation. Du kannst dort machen, was immer du willst, solange du die `git_odb_backend` Struktur richtig eingibst. Hier sieht man, wie es ausschauen _könnte_: [source,c] diff --git a/ch02-git-basics-chapter.asc b/ch02-git-basics-chapter.asc index eef57661..449de548 100644 --- a/ch02-git-basics-chapter.asc +++ b/ch02-git-basics-chapter.asc @@ -4,7 +4,7 @@ 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. +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.