diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc index 53e4aa99..ccbd277b 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -42,7 +42,7 @@ $ git checkout iss53 ---- .Erstellen eines neuen Branch-Zeigers -image::images/basic-branching-2.png[Erstellen eines neuen Branch-Zeigers] +image::images/basic-branching-2.png[alt="Ein Commit-Verlauf mit einem Branch"] Du arbeitest an deiner Website und führst einige Commits durch. Sobald du das machst, bewegt das den `iss53` Branch vorwärts, weil du in ihn gewechselt (engl. checked out) bist. Das bedeutet, dein `HEAD` zeigt auf diesen Branch: @@ -165,7 +165,7 @@ Da der Commit auf dem Branch, auf dem du dich gerade befindest, kein unmittelbar In diesem Fall führt Git einen einfachen Drei-Wege-Merge durch, indem er die beiden Schnappschüsse verwendet, auf die das Branch-Ende und der gemeinsame Vorgänger der beiden zeigen. .Drei Schnappschüsse, die bei einem typischen `merge` benutzt werden -image::images/basic-merging-1.png[Drei Schnappschüsse, die bei einem typischen `merge` benutzt werden] +image::images/basic-merging-1.png[Drei Schnappschüsse die bei einem typischen merge benutzt werden] Anstatt einfach den Zeiger des Branches vorwärts zu bewegen, erstellt Git einen neuen Schnappschuss, der aus dem Drei-Wege-Merge resultiert und erzeugt automatisch einen neuen Commit, der darauf zeigt. Das wird auch als Merge-Commit bezeichnet und ist ein Spezialfall, weil er mehr als nur einen Vorgänger hat. diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 2021c725..aa34e3b9 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -62,7 +62,7 @@ $ git branch testing Dieser Befehl erzeugt einen neuen Zeiger, der auf denselben Commit zeigt, auf dem du dich gegenwärtig befindest. .Zwei Branches, die auf dieselbe Serie von Commits zeigen -image::images/two-branches.png[Zwei Branches, die auf dieselbe Serie von Commits zeigen] +image::images/two-branches.png[Zwei Branches die auf dieselbe Serie von Commits zeigen] Woher weiß Git, auf welchem Branch du gegenwärtig bist? Es besitzt einen speziellen Zeiger namens `HEAD`. @@ -114,7 +114,7 @@ $ git commit -a -m 'made a change' ---- .Der Branch, auf den HEAD zeigt, bewegt sich vorwärts, wenn ein Commit gemacht wird -image::images/advance-testing.png[Der Branch, auf den HEAD zeigt, bewegt sich vorwärts, wenn ein Commit gemacht wird] +image::images/advance-testing.png[Der Branch auf den HEAD zeigt bewegt sich vorwärts wenn ein Commit gemacht wird] Das ist interessant, weil sich jetzt dein `testing` Branch vorwärts bewegt hat, aber dein `master` Branch noch auf den Commit zeigt, auf dem du dich befandest, als du die Anweisung `git checkout` ausführtest, um die Branches zu wechseln. Lassen uns zum Branch `master` zurückwechseln. @@ -137,7 +137,7 @@ Um alle Branches zu sehen, füge `--all` zu deinem Kommando `git log` hinzu. ==== .HEAD bewegt sich, wenn du auscheckst -image::images/checkout-master.png[HEAD bewegt sich, wenn du auscheckst] +image::images/checkout-master.png[HEAD bewegt sich wenn du auscheckst] Diese Anweisung hat zwei Dinge bewirkt. Es bewegte den HEAD-Zeiger zurück, um auf den `master` Branch zu zeigen und es setzte die Dateien in deinem Arbeitsverzeichnis auf den Snapshot zurück, auf den `master` zeigt. diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index ff6a8dea..5bd843d5 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -164,7 +164,7 @@ Du holst das Ganze dann von diesem Server ab und lädst die neuen Commits herunt [[_pre_merge_rebase_work]] .Jemand lädt Commits nach einem Rebase hoch und verwirft damit Commits, auf denen deine Arbeit basiert -image::images/perils-of-rebasing-3.png["Jemand lädt Commits nach einem Rebase hoch und verwirft damit Commits, auf denen deine Arbeit basiert"] +image::images/perils-of-rebasing-3.png[Jemand lädt Commits nach einem Rebase hoch und verwirft damit Commits auf denen deine Arbeit basiert] Jetzt sitzt ihr beide in der Klemme. Wenn du ein `git pull` durchführst, würdest du einen Merge-Commit erzeugen, welcher beide Entwicklungslinien einschließt und dein Repository würde so aussehen: diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index 59060130..314418ef 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -122,7 +122,7 @@ To https://github.com/tonychacon/blink Wenn wir nun zu unserem Fork auf GitHub zurückkehren, können wir sehen, dass GitHub bemerkt hat, dass wir einen neuen Feature-Branch gepusht haben. GitHub zeigt uns einen großen grünen Button, um unsere Änderungen zu überprüfen und einen Pull Request zum ursprünglichen Projekt zu öffnen. -Du kannst alternativ auch die Seite „Branches“ bei `https://github.com///branches` aufzurufen, um deinen Branch auszuwählen und von dort aus einen neuen Pull Request zu öffnen. +Du kannst alternativ auch die Seite „Branches" bei `https://github.com/user/project/branches` aufzurufen (ersetze `user` und `project` durch deine Werte), um deinen Branch auszuwählen und von dort aus einen neuen Pull Request zu öffnen. .Die Schaltfläche Pull Request image::images/blink-02-pr.png[Die Schaltfläche Pull Request] @@ -303,8 +303,8 @@ Es stellt sich heraus, dass es viele, viele Möglichkeiten gibt, auf andere Ding Beginnen wir mit der Frage, wie man einen anderen Pull-Request oder ein Issue vergleicht. Alle Pull-Requests und Issues sind mit Nummern versehen und innerhalb des Projekts eindeutig. Beispielsweise ist es nicht möglich, Pull Request +#3+ _und_ Issue +#3+ anzulegen. -Wenn du auf einen Pull-Request oder ein Issue von einem anderen verweisen möchtest, kannst du einfach `#` in einen Kommentar oder eine Beschreibung eingeben. -Du kannst auch präziser sein, wenn die Issue- oder Pull-Anforderung an einem anderen Ort liegen. Schreibe `Benutzername#`, wenn du dich auf ein Issue oder Pull Request beziehst, in einen Fork des Repositorys, in dem du dich befindest. Oder schreibe `Benutzername/repo#`, um auf etwas in einem anderen Repository zu verweisen. +Wenn du auf einen Pull-Request oder ein Issue von einem anderen verweisen möchtest, kannst du einfach `+#+` in einen Kommentar oder eine Beschreibung eingeben. +Du kannst auch präziser sein, wenn die Issue- oder Pull-Anforderung an einem anderen Ort liegen. Schreibe `username#`, wenn du dich auf ein Issue oder Pull Request beziehst, in einen Fork des Repositorys, in dem du dich befindest. Oder schreibe `username/repo#`, um auf etwas in einem anderen Repository zu verweisen. Schauen wir uns ein Beispiel an. Angenommen, wir haben den Branch aus dem vorherigen Beispiel rebased, einen neuen Pull-Request für ihn erstellt und jetzt wollen wir die alte Pull-Anforderung aus der neuen aufrufen. diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 015f5f84..92231f52 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -73,7 +73,7 @@ In diesem Fall solltest du eine E-Mail erhalten, in der du über den neuen Pull- [[_email_pr]] .E-Mail Benachrichtigung über einen neuen Pull-Request -image::images/maint-01-email.png[Pull-Request, E-Mail Benachrichtigung] +image::images/maint-01-email.png[E-Mail Benachrichtigung eines neuen Pull Requests] Es gibt ein paar Punkte, die man bei dieser E-Mail beachten sollte. Es gibt ein kleines diffstat – eine Liste von Dateien, die sich im Pull Request geändert haben und um wie sehr sie sich geändert haben. @@ -149,7 +149,7 @@ Wenn sich das Repository auf GitHub befindet und es offnee Pull-Requests gibt, Das sind im Prinzip Branches, die aber nicht unter `refs/heads/` stehen. Sie werden normalerweise nicht angezeigt, wenn du klonst oder vom Server fetchst – der Fetching-Prozess ignoriert sie normalerweise. Es gibt zwei Referenzen pro Pull-Request – eine endet mit `/head`. Sie zeigt auf genau den gleichen Commit wie der letzte Commit im Pull-Request-Branch. -Wenn also jemand einen Pull-Request in unserem Repository öffnet und sein Branch `bug-fix` heißt, der auf `a5a775` zeigt, dann haben wir in *unserem* Repository keinen `bug-fix` Branch (weil der in *seinem* Fork liegt). Wir haben jedoch `pull//head`, der auf `a5a775` zeigt. +Wenn also jemand einen Pull-Request in unserem Repository öffnet und sein Branch `bug-fix` heißt, der auf `a5a775` zeigt, dann haben wir in *unserem* Repository keinen `bug-fix` Branch (weil der in *seinem* Fork liegt). Wir haben jedoch `pull/\/head`, der auf `a5a775` zeigt. Das heißt, wir können jeden Pull-Request-Branch herunterladen, ohne lokal einen Menge Remotes hinzufügen zu müssen. Jetzt kannst du das Fetchen dieser Referenz direkt durchführen. @@ -215,7 +215,7 @@ Switched to a new branch 'pr/2' ---- Diejenigen mit Adleraugen unter euch werden das `head` am Ende des Remote-Abschnitts der refspec bemerkt haben. -Es gibt auch ein `refs/pull/#/merge` ref auf der GitHub-Seite, der den Commit darstellt, der sich ergeben würde, wenn du auf die Schaltfläche „merge“ klickst. +Es gibt auch ein `refs/pull/\/merge` ref auf der GitHub-Seite, der den Commit darstellt, der sich ergeben würde, wenn du auf die Schaltfläche „merge" klickst. Auf diese Weise kannst du das Ergebnis des Pull-Requests testen, bevor du überhaupt auf die Schaltfläche geklickt hast. ===== Pull-Requests auf Pull-Requests diff --git a/book/07-git-tools/sections/rerere.asc b/book/07-git-tools/sections/rerere.asc index 8eb0a3d2..e64fa991 100644 --- a/book/07-git-tools/sections/rerere.asc +++ b/book/07-git-tools/sections/rerere.asc @@ -209,7 +209,7 @@ index a440db6,54336ba..0000000 .Automatisch aufgelöster merge Konflikt, der eine vorherige Auflösung nutzt -image::images/rerere3.png[Automatisch aufgelöster merge Konflikt, der eine vorherige Auflösung nutzt] +image::images/rerere3.png[Automatisch aufgelöster merge Konflikt der eine vorherige Auflösung nutzt] Du kannst den Status der Konfliktdatei auch mit `git checkout` wiederherstellen: diff --git a/book/08-customizing-git/sections/attributes.asc b/book/08-customizing-git/sections/attributes.asc index e59bde0f..f4c4ddcc 100644 --- a/book/08-customizing-git/sections/attributes.asc +++ b/book/08-customizing-git/sections/attributes.asc @@ -200,8 +200,8 @@ Diese Filter können so eingestellt werden, um damit alle möglichen interessant image::images/smudge.png[Der „smudge“ Filter wird beim Auschecken ausgeführt] [[filters_b]] -.Der „clean“ Filter wird ausgeführt, wenn Dateien zum Commit vorgemerkt werden -image::images/clean.png[Der „clean“ Filter wird ausgeführt, wenn Dateien zum Commit vorgemerkt werden] +.Der „clean" Filter wird ausgeführt, wenn Dateien zum Commit vorgemerkt werden +image::images/clean.png[Der clean Filter wird ausgeführt wenn Dateien zum Commit vorgemerkt werden] Die ursprüngliche Commit-Meldung dieser Funktion zeigt ein einfaches Anwendungsbeispiel, wie du deinen C-Quellcode vor dem Commit durch das `indent` Programm laufen lassen kannst. Du kannst es so einrichten, dass das Filterattribut in deiner `.gitattributes` Datei so gesetzt ist, dass `*.c` Dateien mit dem Filter „indent“ gefiltert werden: diff --git a/book/10-git-internals/sections/environment.asc b/book/10-git-internals/sections/environment.asc index e0312bf7..c86fd471 100644 --- a/book/10-git-internals/sections/environment.asc +++ b/book/10-git-internals/sections/environment.asc @@ -54,8 +54,8 @@ Wenn du viele Projekte mit großen Dateien hast, die genau den gleichen Inhalt h Diese werden in der Datei `.gitignore` aber auch in der Befehlszeile (`git add *.c`) verwendet. *`GIT_GLOB_PATHSPECS`* und *`GIT_NOGLOB_PATHSPECS`* steuern das Standardverhalten von Platzhaltern in Pfadangaben. -Wenn `GIT_GLOB_PATHSPECS` auf 1 gesetzt ist, werden Platzhalterzeichen als Platzhalter verwendet (dies ist die Standardeinstellung). Wenn `GIT_NOGLOB_PATHSPECS` auf 1 gesetzt ist, stimmen Platzhalterzeichen nur mit sich selbst überein. Dies bedeutet, dass `*.c` nur mit einer Datei namens „* .c“ übereinstimmt und nicht mit einer Datei, deren Name mit `.c` endet. -Du kannst dies in Einzelfällen überschreiben, indem du die Pfadangabe mit `:(glob)` oder `:(literal)` beginnst, wie in `:(glob)*.c`. +Wenn `GIT_GLOB_PATHSPECS` auf 1 gesetzt ist, werden Platzhalterzeichen als Platzhalter verwendet (dies ist die Standardeinstellung). Wenn `GIT_NOGLOB_PATHSPECS` auf 1 gesetzt ist, stimmen Platzhalterzeichen nur mit sich selbst überein. Dies bedeutet, dass `\*.c` nur mit einer Datei namens „*.c" übereinstimmt und nicht mit einer Datei, deren Name mit `.c` endet. +Du kannst dies in Einzelfällen überschreiben, indem du die Pfadangabe mit `:(glob)` oder `:(literal)` beginnst, wie in `:(glob)\*.c`. *`GIT_LITERAL_PATHSPECS`* deaktiviert beide oben genannten Verhaltensweisen. Es können keine Platzhalterzeichen verwendet werden, und die Präfixe zum Überschreiben sind ebenfalls deaktiviert.