diff --git a/LICENSE.asc b/LICENSE.asc index be3737ab..1e86b5e0 100644 --- a/LICENSE.asc +++ b/LICENSE.asc @@ -1,2 +1,2 @@ -Dieses Werk ist lizensiert unter der „Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported“ Lizenz. -Um eine Kopie dieser Lizenz zu lesen, besuchen Sie https://creativecommons.org/licenses/by-nc-sa/3.0 oder senden Sie einen Brief an Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. +Dieses Werk ist lizenziert unter der „Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported“ Lizenz. +Um eine Kopie dieser Lizenz zu lesen, besuche https://creativecommons.org/licenses/by-nc-sa/3.0 oder sende einen Brief an Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index a83b9e70..c5654eaf 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -5,9 +5,9 @@ Was ist „Versionsverwaltung“, und warum sollten Sie sich dafür interessiere Versionsverwaltung ist ein System, welches die Änderungen an einer oder einer Reihe von Dateien über die Zeit hinweg protokolliert, sodass man später auf eine bestimmte Version zurückgreifen kann. Die Dateien, die in den Beispielen in diesem Buch unter Versionsverwaltung gestellt werden, enthalten Quelltext von Software. Tatsächlich kann in der Praxis nahezu jede Art von Datei per Versionsverwaltung nachverfolgt werden. -Wenn Sie Grafik- oder Webdesigner sind und jede Version eines Bildes oder Layouts behalten möchten (was Sie mit Sicherheit möchten), ist die Verwendung eines Versionskontrollsystems (VCS) eine sehr kluge Sache. -Damit können Sie ausgewählte Dateien auf einen früheren Zustand zurücksetzen, das gesamte Projekt auf einen früheren Zustand zurücksetzen, Änderungen im Laufe der Zeit vergleichen, sehen, wer zuletzt etwas geändert hat, das möglicherweise ein Problem verursacht, wer wann ein Problem verursacht hat und vieles mehr. -Die Verwendung eines VCS bedeutet im Allgemeinen auch, dass Sie problemlos eine Wiederherstellung durchführen können, wenn etwas kaputt geht oder Dateien verloren gehen. +Wenn du Grafik- oder Webdesigner bist und jede Version eines Bildes oder Layouts behalten möchtest (was Du mit Sicherheit möchtest), ist die Verwendung eines Versionskontrollsystems (VCS) eine sehr kluge Sache. +Damit kannst du ausgewählte Dateien auf einen früheren Zustand zurücksetzen, das gesamte Projekt auf einen früheren Zustand zurücksetzen, zurückliegende Änderungen vergleichen, sehen wer zuletzt etwas geändert hat, das möglicherweise ein Problem verursacht, wer wann ein Problem verursacht hat und vieles mehr. +Die Verwendung eines VCS bedeutet im Allgemeinen auch, dass du problemlos eine Wiederherstellung durchführen könntest, wenn etwas kaputt geht oder Dateien verloren gehen. All diese Vorteile erhält man mit einen nur sehr geringen, zusätzlichen Aufwand. ==== Lokale Versionsverwaltung @@ -28,7 +28,7 @@ https://www.gnu.org/software/rcs/[RCS^] arbeitet nach dem Prinzip, dass für jed ==== Zentrale Versionsverwaltung (((Versionsverwaltung, zentral))) -Ein weiteres großes Problem, mit dem sich viele Leute dann konfrontiert sahen, bestand in der Zusammenarbeit mit anderen Entwicklern auf anderen Systemen. +Ein weiteres großes Problem, mit dem sich viele Leute konfrontiert sahen, bestand in der Zusammenarbeit mit anderen Entwicklern auf anderen Systemen. Um dieses Problem zu lösen, wurden zentralisierte Versionsverwaltungssysteme entwickelt (engl. Centralized Version Control System, CVCS). Diese Systeme, wozu beispielsweise CVS, Subversion und Perforce gehören, basieren auf einem zentralen Server, der alle versionierte Dateien verwaltet. Die Clients können die Dateien von diesem zentralen Ort abholen und auf ihren PC übertragen. Den Vorgang des Abholens nennt man Auschecken (engl. to check out). (((CVS)))(((Subversion)))(((Perforce))) Diese Art von System war über viele Jahre hinweg der Standard für Versionsverwaltungssysteme. @@ -41,10 +41,10 @@ Zum Beispiel weiß jeder mehr oder weniger genau darüber Bescheid, was andere a Administratoren haben die Möglichkeit, detailliert festzulegen, wer was tun kann. Und es ist sehr viel einfacher, ein CVCS zu administrieren als lokale Datenbanken auf jedem einzelnen Anwenderrechner zu verwalten. Allerdings hat dieser Aufbau auch einige erhebliche Nachteile. -Der offensichtlichste Nachteil ist das Risiko eines Systemausfalls bei Ausfall einer einzelnen Komponente, nämlich dann, wenn der zentralisierte Server ausfällt. +Der offensichtlichste Nachteil ist das Risiko eines Systemausfalls bei Ausfall einer einzelnen Komponente, d.h. wenn der zentrale Server ausfällt. Wenn dieser Server nur für eine Stunde nicht verfügbar ist, dann kann in dieser einen Stunde niemand in irgendeiner Form mit anderen zusammenarbeiten oder Dateien, an denen gerade gearbeitet wird, versioniert abspeichern. Wenn die auf dem zentralen Server eingesetzte Festplatte beschädigt wird und keine Sicherheitskopien erstellt wurden, dann sind all diese Daten unwiederbringlich verloren – die komplette Historie des Projektes, abgesehen natürlich von dem jeweiligen Zustand, den Mitarbeiter gerade zufällig auf ihrem Rechner noch vorliegen haben. -Lokale Versionskontrollsysteme haben natürlich dasselbe Problem: Wenn man die Historie eines Projektes an einer einzigen, zentralen Stelle verwaltet, riskiert man, sie vollständig zu verlieren, wenn irgendetwas an dieser zentralen Stelle ernsthaft schief läuft. +Lokale Versionskontrollsysteme haben natürlich dasselbe Problem: Wenn man die Historie eines Projektes an einer einzigen, zentralen Stelle verwaltet, riskiert man, sie vollständig zu verlieren, wenn irgendetwas an dieser zentralen Stelle schief läuft. ==== Verteilte Versionsverwaltung diff --git a/book/01-introduction/sections/command-line.asc b/book/01-introduction/sections/command-line.asc index 86a4b6c6..6d8fd182 100644 --- a/book/01-introduction/sections/command-line.asc +++ b/book/01-introduction/sections/command-line.asc @@ -4,8 +4,8 @@ Es gibt viele verschiedene Möglichkeiten Git einzusetzen. Auf der einen Seite gibt es die Werkzeuge, die per Kommandozeile bedient werden und auf der anderen, die vielen grafischen Benutzeroberflächen (engl. graphical user interface, GUI), die sich im Leistungsumfang unterscheiden. In diesem Buch verwenden wir die Kommandozeile. In der Kommandozeile können nämlich wirklich *alle* vorhandenen Git Befehle ausgeführt werden. Bei den meisten grafischen Oberflächen ist dies nicht möglich, da aus Gründen der Einfachheit nur ein Teil der Git-Funktionalitäten zur Verfügung gestellt werden. -Wenn Sie sich in der Kommandozeilenversion von Git auskennen, finden Sie sich wahrscheinlich auch in einer GUI-Version relativ schnell zurecht, aber andersherum muss das nicht unbedingt zutreffen. +Wenn du dich in der Kommandozeilenversion von Git auskennen, findest du dich wahrscheinlich auch in einer GUI-Version relativ schnell zurecht, aber andersherum muss das nicht unbedingt zutreffen. Außerdem ist die Wahl der grafischen Oberfläche eher Geschmackssache, wohingegen die Kommandozeilenversion auf jedem Rechner installiert und verfügbar ist. -In diesem Buch gehen wir deshalb davon aus, dass Sie wissen, wie man bei einem Mac ein Terminal öffnet, oder wie man unter Windows die Eingabeaufforderung oder die Powershell öffnet. -Sollten Sie jetzt nur Bahnhof verstehen, sollten Sie an dieser Stelle abbrechen und sich schlau machen, was ein Terminal bzw. eine Eingabeaufforderung ist und wie man diese bedient. Nur so ist sichergestellt, dass Sie unseren Beispielen und Ausführungen im weiteren Verlauf des Buches folgen können. +In diesem Buch gehen wir deshalb davon aus, dass du weißt, wie man bei einem Mac ein Terminal öffnet, oder wie man unter Windows die Eingabeaufforderung oder die Powershell öffnet. +Falls du jetzt nur Bahnhof verstehst, solltest du an dieser Stelle abbrechen und dich schlau machen, was ein Terminal bzw. eine Eingabeaufforderung ist und wie man diese bedient. Nur so ist sichergestellt, dass du unsere Beispiele und Ausführungen im weiteren Verlauf des Buches folgen kannst. diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 017a5f5c..ea95c310 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -1,41 +1,40 @@ [[_first_time]] === Git Basis-Konfiguration -Nachdem Git jetzt auf Ihrem System installiert ist, sollten Sie Ihre Git-Konfiguration noch anpassen. -Dies muss nur einmalig auf dem jeweiligen System durchgeführt werden. Die Konfiguration bleibt bestehen, wenn Sie Git auf eine neuere Version aktualisieren. +Nachdem Git jetzt auf deinem System installiert ist, solltest du deine Git-Konfiguration noch anpassen. +Dies muss nur einmalig auf dem jeweiligen System durchgeführt werden. Die Konfiguration bleibt bestehen, wenn du Git auf eine neuere Version aktualisierst. Die Git-Konfiguration kann auch jederzeit geändert werden, indem die nachfolgenden Befehle einfach noch einmal ausgeführt werden. -Git umfasst das Werkzeug `git config`, welches die Möglichkeit bietet, Konfigurationswerte zu verändern. Auf diese Weise können Sie anpassen, wie Git aussieht und arbeitet.(((Git Befehle, config))) +Git umfasst das Werkzeug `git config`, welches die Möglichkeit bietet, Konfigurationswerte zu verändern. Auf diese Weise kannst du anpassen, wie Git aussieht und arbeitet.(((Git Befehle, config))) Die Konfiguration ist an drei verschiedenen Orten gespeichert: 1. Die Datei `[path]/etc/gitconfig`: enthält Werte, die für jeden Benutzer auf dem System und alle seine Repositories gelten. - Wenn Sie die Option `--system` an `git config` übergeben, liest und schreibt sie spezifisch aus dieser Datei. - Da es sich um eine Systemkonfigurationsdatei handelt, benötigen Sie Administrator- oder Superuser-Rechte, um Änderungen daran vorzunehmen. -2. Die Datei `~/.gitconfig` oder `~/.config/git/config`: enthält Werte, die für Sie, den Benutzer, persönlich bestimmt sind. - Sie können Git dazu bringen, diese Datei gezielt zu lesen und zu schreiben, indem Sie die Option `--global` übergeben, und dies betrifft _alle_ der Repositories, mit denen Sie auf Ihrem System arbeiten. -3. Die Datei `config` im Git-Verzeichnis (also `.git/config`) des jeweiligen Repositories, das Sie gerade verwenden: - Sie können Git mit der Option `--local` zwingen, aus dieser Datei zu lesen und in sie zu schreiben, das ist in der Regel die Standardoption. - (Es dürfte Sie nicht überraschen, dass Sie sich irgendwo in einem Git-Repository befinden müssen, damit diese Option ordnungsgemäß funktioniert.) + Wenn du die Option `--system` an `git config` übergibst, liest und schreibt sie aus dieser Datei. + Da es sich um eine Systemkonfigurationsdatei handelt, benötigst du Administrator- oder Superuser-Rechte, um Änderungen daran vorzunehmen. +2. Die Datei `~/.gitconfig` oder `~/.config/git/config`: enthält Werte, die für dich, den Benutzer, persönlich bestimmt sind. + Du kannst Git dazu bringen, diese Datei gezielt zu lesen und zu schreiben, indem du die Option `--global` übergibst. Dies betrifft _alle_ Repositories, mit denen du auf deinem System arbeitest. +3. Die Datei `config` im Git-Verzeichnis (also `.git/config`) des jeweiligen Repositories, das du gerade verwendest: + Du kannst Git mit der Option `--local` zwingen, aus dieser Datei zu lesen und in sie zu schreiben, das ist in der Regel die Standardoption. + (Es dürfte klar sein, dass du dich irgendwo in einem Git-Repository befinden musst, damit diese Option ordnungsgemäß funktioniert.) - Jede Ebene überschreibt Werte der vorherigen Ebene, so dass Werte in `.git/config` diejenigen in `[path]/etc/gitconfig` aushebeln. + Jede Ebene überschreibt Werte der vorherigen Ebene, so dass Werte in `.git/config` diejenigen in `[path]/etc/gitconfig` aushebelt. Auf Windows-Systemen sucht Git nach der Datei `.gitconfig` im `$HOME` Verzeichnis (normalerweise zeigt `$HOME` bei den meisten Systemen auf `C:\Users\$USER`). -Git schaut immer nach `[path]/etc/gitconfig`, auch wenn die sich relativ zu dem MSys-Wurzelverzeichnis befindet, dem Verzeichnis in das Sie Git installiert haben. -Wenn Sie eine Version 2.x oder neuer von Git für Windows verwenden, gibt es auch eine Konfigurationsdatei auf Systemebene unter -`C:\Dokumente und Einstellungen\Alle Benutzer\Anwendungsdaten\Git\config` unter Windows XP und unter `C:\ProgramData\Git\config` unter Windows Vista und neuer. +Git schaut immer nach `[path]/etc/gitconfig`, auch wenn die sich relativ zu dem MSys-Wurzelverzeichnis befindet, dem Verzeichnis in das du Git installiert hast. +Wenn du eine Version 2.x oder neuer von Git für Windows verwendest, gibt es auch eine Konfigurationsdatei auf Systemebene unter `C:\Dokumente und Einstellungen\Alle Benutzer\Anwendungsdaten\Git\config` unter Windows XP und unter `C:\ProgramData\Git\config` unter Windows Vista und neuer. Diese Konfigurationsdatei kann nur von `git config -f ` als Admin geändert werden. -Sie können sich alle Ihre Einstellungen ansehen sehen, wo sie herkommen: +Du kannst dir alle Git Einstellungen ansehen und wo sie herkommen mit: [source,console] ---- $ git config --list --show-origin ---- -==== Ihre Identität +==== Deine Identität -Nachdem Sie Git installiert haben, sollten Sie als allererstes Ihren Namen und Ihre E-Mail-Adresse in Git konfigurieren. -Das ist insofern wichtig, da jeder Git-Commit diese Informationen verwendet und sie unveränderlich in die Commits eingearbeitet werden, die Sie erstellen: +Nachdem du Git installiert hast, solltest du als allererstes deinen Namen und deine E-Mail-Adresse in Git konfigurieren. +Das ist insofern wichtig, da jeder Git-Commit diese Informationen verwendet und sie unveränderlich in die Commits eingearbeitet werden, die du erstellst: [source,console] ---- @@ -43,29 +42,29 @@ $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com ---- -Wie schon erwähnt, brauchen Sie diese Konfiguration nur einmal vorzunehmen, wenn Sie die Option `--global` verwenden. Auf Grund der oben erwähnten Prioritäten gilt das dann für alle Ihre Projekte. -Wenn Sie für ein spezielles Projekt einen anderen Namen oder eine andere E-Mail-Adresse verwenden möchten, können Sie den Befehl ohne die Option `--global` innerhalb des Projektes ausführen. +Wie schon erwähnt, brauchst du diese Konfiguration nur einmal vorzunehmen, wenn du die Option `--global` verwendest. Auf Grund der oben erwähnten Prioritäten gilt das dann für alle deine Projekte. +Wenn du für ein spezielles Projekt einen anderen Namen oder eine andere E-Mail-Adresse verwenden möchtest, kannst du den Befehl ohne die Option `--global` innerhalb des Projektes ausführen. -Viele der grafischen Oberflächen helfen einem bei diesem Schritt, wenn Sie sie zum ersten Mal ausführen. +Viele der grafischen Oberflächen helfen einem bei diesem Schritt, wenn du sie zum ersten Mal ausführst. [[_editor]] -==== Ihr Editor +==== Dein Editor -Jetzt, da Ihre Identität eingerichtet ist, können Sie den Standard-Texteditor konfigurieren, der verwendet wird, wenn Git Sie zum Eingeben einer Nachricht auffordert. +Jetzt, da deine Identität eingerichtet ist, kannst du den Standard-Texteditor konfigurieren, der verwendet wird, wenn Git dich zum Eingeben einer Nachricht auffordert. Normalerweise verwendet Git den Standard-Texteditor des jeweiligen Systems. -Wenn Sie einen anderen Texteditor, z.B. Emacs, verwenden wollen, können Sie das wie folgt festlegen: +Wenn du einen anderen Texteditor, z.B. Emacs, verwenden willst, kannst du das wie folgt festlegen: [source,console] ---- $ git config --global core.editor emacs ---- -Wenn Sie auf einem Windows-System einen anderen Texteditor verwenden möchten, müssen Sie den vollständigen Pfad zu seiner ausführbaren Datei angeben. -Dies kann, je nachdem, wie Ihr Editor eingebunden ist, unterschiedlich sein. +Wenn du auf einem Windows-System einen anderen Texteditor verwenden möchtest, musst du den vollständigen Pfad zu seiner ausführbaren Datei angeben. +Dies kann, je nachdem, wie dein Editor eingebunden ist, unterschiedlich sein. -Im Falle von Notepad++, einem beliebten Programmiereditor, sollten Sie wahrscheinlich die 32-Bit-Version verwenden, da die 64-Bit-Version zum Zeitpunkt der Erstellung nicht alle Plug-Ins unterstützt. -Beim Einsatz auf einem 32-Bit-Windows-System oder einem 64-Bit-Editor auf einem 64-Bit-System geben Sie etwa Folgendes ein: +Im Falle von Notepad++, einem beliebten Programmiereditor, solltest du wahrscheinlich die 32-Bit-Version verwenden, da die 64-Bit-Version zum Zeitpunkt der Erstellung nicht alle Plug-Ins unterstützt. +Beim Einsatz auf einem 32-Bit-Windows-System oder einem 64-Bit-Editor auf einem 64-Bit-System gibst du etwa Folgendes ein: [source,console] ---- @@ -75,22 +74,22 @@ $ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -m [NOTE] ==== Vim, Emacs und Notepad++ sind beliebte Texteditoren, die von Entwicklern häufig auf Unix-basierten Systemen wie Linux und macOS oder einem Windows-System verwendet werden. -Wenn Sie einen anderen Editor oder eine 32-Bit-Version verwenden, finden Sie in <> spezielle Anweisungen, wie Sie Ihren bevorzugten Editor mit Git einrichten können. +Wenn du einen anderen Editor oder eine 32-Bit-Version verwenden, findest du in <> spezielle Anweisungen, wie du deinen bevorzugten Editor mit Git einrichten kannst. ==== [WARNING] ==== -Wenn Sie Git nicht so konfigurieren, dass es Ihren Texteditor verwendet und Sie keine Ahnung davon haben, wie man Vim oder Emacs benutzt, werden Sie ein wenig überfordert sein, wenn diese zum ersten Mal von Git gestartet werden. +Wenn du Git nicht so konfigurierst, dass es deinen Texteditor verwendet und du keine Ahnung davon hast, wie man Vim oder Emacs benutzt, wirst du ein wenig überfordert sein, wenn diese zum ersten Mal von Git gestartet werden. Ein Beispiel auf einem Windows-System könnte ein vorzeitig beendeter Git-Vorgang während einer von Git initiierten Editor-Bearbeitung sein. ==== [[_new_default_branch]] ==== Der standardmäßige Branch-Name -In der Voreinstellung wird Git einen Branch mit dem Namen _master_ erzeugen, wenn Sie ein neues Repository mit `git init` erstellen. -Ab der Git-Version 2.28 können Sie einen abweichenden Namen für den initialen Branch festlegen. +In der Voreinstellung wird Git einen Branch mit dem Namen _master_ erzeugen, wenn du ein neues Repository mit `git init` erstellst. +Ab der Git-Version 2.28 kannst du einen abweichenden Namen für den initialen Branch festlegen. -So konfigurieren Sie _main_ als Vorgabe für den Branch-Namen: +So konfigurierst du _main_ als Vorgabe für den Branch-Namen: [source,console] ---- @@ -99,7 +98,7 @@ $ git config --global init.defaultBranch main ==== Einstellungen überprüfen -Wenn Sie Ihre Konfigurationseinstellungen überprüfen möchten, können Sie mit dem Befehl `git config --list` alle Einstellungen auflisten, die Git derzeit finden kann: +Wenn du deine Konfigurationseinstellungen überprüfen möchtest, kannst du mit dem Befehl `git config --list` alle Einstellungen auflisten, die Git derzeit finden kann: [source,console] ---- @@ -116,7 +115,7 @@ color.diff=auto Manche Parameter werden möglicherweise mehrfach aufgelistet, weil Git denselben Parameter in verschiedenen Dateien (z.B. `[path]/etc/gitconfig` und `~/.gitconfig`) gefunden hat. In diesem Fall verwendet Git dann den jeweils zuletzt aufgelisteten Wert. -Außerdem können Sie mit dem Befehl `git config ` prüfen, welchen Wert Git für einen bestimmten Parameter verwendet:(((Git Befehle, config))) +Außerdem kannst du mit dem Befehl `git config ` prüfen, welchen Wert Git für einen bestimmten Parameter verwendet:(((Git Befehle, config))) [source,console] ---- @@ -126,12 +125,12 @@ John Doe [NOTE] ==== -Da Git möglicherweise den gleichen Wert der Konfigurationsvariablen aus mehr als einer Datei liest, ist es möglich, dass Sie einen unerwarteten Wert für einen dieser Werte haben und nicht wissen, warum. -In solchen Fällen können Sie Git nach dem _Ursprung_ (engl. origin) für diesen Wert fragen, und es wird Ihnen sagen, mit welcher Konfigurationsdatei der Wert letztendlich festgelegt wurde: +Da Git möglicherweise den gleichen Wert der Konfigurationsvariablen aus mehr als einer Datei liest, ist es möglich, dass du einen unerwarteten Wert für einen dieser Werte erhältst und nicht weißt, warum. +In solchen Fällen kannst du Git nach dem _Ursprung_ (engl. origin) für diesen Wert fragen. Git wird dir sagen, mit welcher Konfigurationsdatei der Wert letztendlich festgelegt wurde: [source,console] ---- $ git config --show-origin rerere.autoUpdate file:/home/johndoe/.gitconfig false ---- -==== +==== \ No newline at end of file diff --git a/book/01-introduction/sections/help.asc b/book/01-introduction/sections/help.asc index 40ba356f..be6922ab 100644 --- a/book/01-introduction/sections/help.asc +++ b/book/01-introduction/sections/help.asc @@ -1,7 +1,7 @@ [[_git_help]] === Hilfe finden -Falls Sie einmal Hilfe bei der Anwendung von Git benötigen, gibt es drei Möglichkeiten, die entsprechende Seite aus der Dokumentation (engl. manpage) für jeden Git-Befehl anzuzeigen: +Falls du einmal Hilfe bei der Verwendung von Git benötigst, gibt es drei Möglichkeiten, die entsprechende Seite aus der Dokumentation (engl. manpage) für jeden Git-Befehl anzuzeigen: [source,console] ---- @@ -10,18 +10,18 @@ $ git --help $ man git- ---- -Beispielweise erhalten Sie die Hilfeseite für den Befehl `git config` folgendermaßen:(((Git Befehle, help))) +Beispielweise erhälst du die Hilfeseite für den Befehl `git config` folgendermaßen:(((Git Befehle, help))) [source,console] ---- $ git help config ---- -Diese Befehle sind nützlich, weil Sie sich die Hilfe jederzeit anzeigen lassen können, auch wenn Sie einmal offline sind. -Wenn die Hilfeseiten und dieses Buch nicht ausreichen und Sie persönliche Hilfe brauchen, können Sie einen der Kanäle `#git`, `#github` oder `#gitlab` auf dem Libera-Chat-IRC-Server probieren, der unter https://libera.chat/[^] zu finden ist. -Diese Kanäle sind in der Regel sehr gut besucht. Normalerweise findet sich unter den vielen Anwendern, die oft sehr viel Erfahrung mit Git haben, irgendjemand, der Ihnen weiterhelfen kann.(((IRC-Chat))) +Diese Befehle sind nützlich, weil du dir die Hilfe jederzeit anzeigen lassen kannst, auch wenn du einmal offline bist. +Wenn die Hilfeseiten und dieses Buch nicht ausreichen und du persönliche Hilfe brauchst, kannst du einen der Kanäle `#git`, `#github` oder `#gitlab` auf dem Libera-Chat-IRC-Server probieren, der unter https://libera.chat/[^] zu finden ist. +Diese Kanäle sind in der Regel sehr gut besucht. Normalerweise findet sich unter den vielen Anwendern, die oft sehr viel Erfahrung mit Git haben, irgendjemand, der dir weiterhelfen kann.(((IRC-Chat))) -Wenn Sie nicht die vollständige Manpage-Hilfe benötigen, sondern nur eine kurze Beschreibung der verfügbaren Optionen für einen Git-Befehl, können Sie auch in den kompakteren „Hilfeseiten“ mit der Option `-h` nachschauen, wie in: +Wenn du nicht die vollständige Manpage-Hilfe benötigst, sondern nur eine kurze Beschreibung der verfügbaren Optionen für einen Git-Befehl, kannst du auch in den kompakteren „Hilfeseiten“ mit der Option `-h` nachschauen, wie in: [source,console] ---- @@ -46,5 +46,4 @@ usage: git add [] [--] ... --chmod (+|-)x override the executable bit of the listed files --pathspec-from-file read pathspec from file --pathspec-file-nul with --pathspec-from-file, pathspec elements are separated with NUL character ----- - +---- \ No newline at end of file diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index ecdf9ed9..67e47ad1 100644 --- a/book/01-introduction/sections/installing.asc +++ b/book/01-introduction/sections/installing.asc @@ -1,8 +1,8 @@ === Git installieren -Bevor Sie mit Git loslegen können, muss es natürlich zuerst installiert werden. +Bevor du mit Git loslegen kannst, muss es natürlich zuerst installiert werden. Auch wenn es bereits vorhanden ist, ist es vermutlich eine gute Idee, auf die neueste Version zu aktualisieren. -Sie können es entweder als Paket oder über ein anderes Installationsprogramm installieren oder den Quellcode herunterladen und selbst kompilieren. +Du kannst es entweder als Paket oder über ein anderes Installationsprogramm installieren oder den Quellcode herunterladen und selbst kompilieren. [NOTE] ==== @@ -14,8 +14,8 @@ Auch wenn die meisten Befehle, die wir anwenden werden, auch in älteren Version ==== Installation unter Linux (((Linux, Installation))) -Wenn Sie die grundlegenden Git-Tools unter Linux über ein Installationsprogramm installieren möchten, können Sie das in der Regel über das Paketverwaltungstool der Distribution tun. -Wenn Sie mit Fedora (oder einer anderen eng damit verbundenen RPM-basierten Distribution, wie RHEL oder CentOS) arbeiten, können Sie `dnf` verwenden: +Wenn du die grundlegenden Git-Tools unter Linux über ein Installationsprogramm installieren möchten, kannst du das in der Regel über das Paketverwaltungstool der Distribution tun. +Wenn du mit Fedora (oder einer anderen eng damit verbundenen RPM-basierten Distribution, wie RHEL oder CentOS) arbeitest, kannst du `dnf` verwenden: [source,console] ---- @@ -55,19 +55,19 @@ image::images/git-osx-installer.png[Git macOS installer] Auch für Windows gibt es einige Möglichkeiten zur Installation von Git.(((Windows, Installation))) Eine offizielle Windows-Version findet man direkt auf der Git-Homepage. -Gehen Sie dazu auf https://git-scm.com/download/win[^] und der Download sollte dann automatisch starten. -Man sollte dabei beachten, dass es sich hierbei um das Projekt „Git for Windows“ handelt, welches unabhängig von Git selbst ist. Weitere Informationen hierzu finden Sie unter https://msysgit.github.io/[^]. +Gehe dazu auf https://git-scm.com/download/win[^] und der Download sollte dann automatisch starten. +Man sollte dabei beachten, dass es sich hierbei um das Projekt „Git for Windows“ handelt, welches unabhängig von Git selbst ist. Weitere Informationen hierzu findest du unter https://msysgit.github.io/[^]. -Um eine automatisierte Installation zu erhalten, können Sie das https://chocolatey.org/packages/git[Git Chocolatey Paket^] verwenden. -Beachten Sie, dass das Chocolatey-Paket von der Community gepflegt wird. +Um eine automatisierte Installation zu erhalten, kannst du das https://chocolatey.org/packages/git[Git Chocolatey Paket^] verwenden. +Beachte, dass das Chocolatey-Paket von der Community gepflegt wird. ==== Aus dem Quellcode installieren Viele Leute kompilieren Git auch auf ihrem eigenen Rechner, weil sie damit die jeweils aktuellste Version erhalten. Die vorbereiteten Pakete hinken meist ein wenig hinterher, obwohl Git in den letzten Jahren ausgereifter geworden ist und dies somit wesentlich besser geworden ist. -Wenn Sie Git aus dem Quellcode installieren möchten, benötigen Sie die folgenden Bibliotheken, von denen Git abhängt: autotools, curl, zlib, openssl, expat und libiconv. -Wenn Sie sich beispielsweise auf einem System befinden, das Paketverwaltungen, wie `dnf` (Fedora) oder `apt-get` (ein Debian-basiertes System) hat, können Sie mit einem dieser Befehle die minimalen Abhängigkeiten für die Kompilierung und Installation der Git-Binärdateien installieren: +Wenn du Git aus dem Quellcode installieren möchtest, benötigst du die folgenden Bibliotheken, von denen Git abhängt: autotools, curl, zlib, openssl, expat und libiconv. +Wenn du dich beispielsweise auf einem System befinden, das Paketverwaltungen, wie `dnf` (Fedora) oder `apt-get` (ein Debian-basiertes System) hat, kannst du mit einem dieser Befehle die minimalen Abhängigkeiten für die Kompilierung und Installation der Git-Binärdateien installieren: [source,console] ---- @@ -90,30 +90,30 @@ $ sudo apt-get install asciidoc xmlto docbook2x Benutzer von RHEL und RHEL-Derivaten wie CentOS und Scientific Linux müssen das https://docs.fedoraproject.org/en-US/epel/#how_can_i_use_these_extra_packages[EPEL-Repository aktivieren^], um das Paket `docbook2X` herunterzuladen. ==== -Wenn Sie eine Debian-basierte Distribution (Debian, Ubuntu oder deren Derivate) verwenden, benötigen Sie auch das Paket `install-info`: +Wenn du eine Debian-basierte Distribution (Debian, Ubuntu oder deren Derivate) verwendest, benötigst du auch das Paket `install-info`: [source,console] ---- $ sudo apt-get install install-info ---- -Wenn Sie eine RPM-basierte Distribution (Fedora, RHEL oder deren Derivate) verwenden, benötigen Sie auch das Paket `getopt` (welches auf einer Debian-basierten Distribution bereits installiert ist): +Wenn du eine RPM-basierte Distribution (Fedora, RHEL oder deren Derivate) verwendest, benötigst du auch das Paket `getopt` (welches auf einer Debian-basierten Distribution bereits installiert ist): [source,console] ---- $ sudo dnf install getopt ---- -Wenn Sie Fedora- oder RHEL-Derivate verwenden, müssen Sie wegen der unterschiedlichen Paketnamen zusätzlich einen Symlink erstellen, indem Sie folgenden Befehl ausführen: +Wenn du Fedora- oder RHEL-Derivate verwendest, musst du wegen der unterschiedlichen Paketnamen zusätzlich einen Symlink erstellen, indem du folgenden Befehl: [source,console] ---- $ sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi ---- -aufgrund von binären Namensunterschieden. +aufgrund von binären Namensunterschieden ausführst. -Wenn Sie alle notwendigen Abhängigkeiten installiert haben, können Sie sich als nächstes die jeweils aktuellste Version als Tarball von verschiedenen Stellen herunterladen. +Wenn du alle notwendigen Abhängigkeiten installiert hast, kannst du dir als nächstes die jeweils aktuellste Version als Tarball von verschiedenen Stellen herunterladen. Man findet die Quellen auf der Kernel.org-Website unter https://www.kernel.org/pub/software/scm/git[], oder einen Mirror auf der GitHub-Website unter https://github.com/git/git/releases[^]. Auf der GitHub-Seite ist es einfacher herauszufinden, welches die jeweils aktuellste Version ist. Auf kernel.org dagegen werden auch Signaturen zur Verifikation des Downloads der jeweiligen Pakete zur Verfügung gestellt. @@ -129,9 +129,9 @@ $ make all doc info $ sudo make install install-doc install-html install-info ---- -Nachdem dies erledigt ist, können Sie Git für Updates auch über Git selbst beziehen: +Nachdem dies erledigt ist, kannst du Git für Updates auch über Git selbst beziehen: [source,console] ---- $ git clone https://git.kernel.org/pub/scm/git/git.git ----- +---- \ No newline at end of file diff --git a/book/01-introduction/sections/what-is-git.asc b/book/01-introduction/sections/what-is-git.asc index b75749f6..64bf47e7 100644 --- a/book/01-introduction/sections/what-is-git.asc +++ b/book/01-introduction/sections/what-is-git.asc @@ -2,49 +2,49 @@ === Was ist Git? Also, was ist Git denn nun? -Dies ist ein wichtiger Teil, den es zu beachten gilt, denn wenn Sie verstehen, was Git und das grundlegenden Konzept seiner Arbeitsweise ist, dann wird die effektive Nutzung von Git für Sie wahrscheinlich viel einfacher sein. -Wenn Sie Git erlernen, versuchen Sie, Ihren Kopf von den Dingen zu befreien, die Sie über andere VCSs wissen, wie CVS, Subversion oder Perforce – das wird Ihnen helfen, unangenehme Missverständnisse bei der Verwendung des Tools zu vermeiden. -Auch wenn die Benutzeroberfläche von Git diesen anderen VCSs sehr ähnlich ist, speichert und betrachtet Git Informationen auf eine ganz andere Weise, und das Verständnis dieser Unterschiede hilft Ihnen Unklarheiten bei der Verwendung zu vermeiden.(((Subversion)))(((Perforce))) +Dies ist ein wichtiger Teil, den es zu beachten gilt, denn wenn du verstehst, was Git und das grundlegenden Konzept seiner Arbeitsweise ist, dann wird die effektive Nutzung von Git für dich wahrscheinlich viel einfacher sein. +Wenn du Git erlernst, solltest du versuchen, deinen Kopf von den Dingen zu befreien, die du über andere VCSs, wie CVS, Subversion oder Perforce, weist. Das wird dir helfen, unangenehme Missverständnisse bei der Verwendung des Tools zu vermeiden. +Auch wenn die Benutzeroberfläche von Git den VCSs sehr ähnlich ist, speichert und betrachtet Git Informationen auf eine ganz andere Weise, und das Verständnis dieser Unterschiede hilft dir Unklarheiten bei der Verwendung zu vermeiden.(((Subversion)))(((Perforce))) ==== Snapshots statt Unterschiede Der Hauptunterschied zwischen Git und anderen Versionsverwaltungssystemen (insbesondere auch Subversion und vergleichbaren Systemen) besteht in der Art und Weise wie Git die Daten betrachtet. Konzeptionell speichern die meisten anderen Systeme Informationen als eine Liste dateibasierter Änderungen. -Diese Systeme (CVS, Subversion, Perforce, Bazaar usw.) betrachten die Informationen, die sie verwalten, als eine Reihe von Dateien an denen im Laufe der Zeit Änderungen vorgenommen werden (dies wird allgemein als _deltabasierte_ Versionskontrolle bezeichnet). +Diese Systeme (CVS, Subversion, Perforce, Bazaar usw.) betrachtet die Informationen, die sie verwaltet, als eine Reihe von Dateien an denen im Laufe der Zeit Änderungen vorgenommen werden (dies wird allgemein als _deltabasierte_ Versionskontrolle bezeichnet). .Speichern von Daten als Änderung an einzelnen Dateien auf Basis einer Ursprungsdatei image::images/deltas.png[Storing data as changes to a base version of each file] -Git arbeitet nicht auf diese Art und Weise. +Git arbeitet nicht auf diese Art. Stattdessen betrachtet Git seine Daten eher wie eine Reihe von Schnappschüssen eines Mini-Dateisystems. -Git macht jedes Mal, wenn Sie den Status Ihres Projekts committen, das heißt den gegenwärtigen Status Ihres Projekts als eine Version in Git speichern, ein Abbild von all Ihren Dateien wie sie gerade aussehen und speichert einen Verweis in diesem Schnappschuss. +Git macht jedes Mal, wenn du den Status deines Projekts committest (das heißt den gegenwärtigen Status deines Projekts als eine Version in Git speicherst) ein Abbild von all deinen Dateien wie sie gerade aussehen und speichert einen Verweis in diesem Schnappschuss. Um dies möglichst effizient und schnell tun zu können, kopiert Git unveränderte Dateien nicht, sondern legt lediglich eine Verknüpfung zu der vorherigen Version der Datei an. -Git betrachtet seine Daten eher wie einen *Stapel von Schnappschüssen*. +Git betrachtet seine Daten eher als einen *Stapel von Schnappschüssen*. .Speichern der Daten-Historie eines Projekts in Form von Schnappschüsse image::images/snapshots.png[Git stores data as snapshots of the project over time] Das ist ein wichtiger Unterschied zwischen Git und praktisch allen anderen Versionsverwaltungssystemen. -In Git wurden daher fast alle Aspekte der Versionsverwaltung neu überdacht, die in anderen Systemen mehr oder weniger von ihrer jeweiligen Vorgängergeneration übernommen worden waren. +In Git wurden fast alle Aspekte der Versionsverwaltung neu überdacht, die in anderen Systemen mehr oder weniger von ihrer jeweiligen Vorgängergeneration übernommen worden waren. Git arbeitet im Großen und Ganzen eher wie ein mit einigen unglaublich mächtigen Werkzeugen ausgerüstetes Mini-Dateisystem, statt nur als Versionsverwaltungssystem. Auf einige der Vorteile, die es mit sich bringt, Daten in dieser Weise zu verwalten, werden wir in Kapitel 3, <>, eingehen, wenn wir das Git Branching-Konzept kennenlernen. ==== Fast jede Funktion arbeitet lokal -Die meisten Aktionen in Git benötigen nur lokale Dateien und Ressourcen, um ausgeführt zu werden – im Allgemeinen werden keine Informationen von einem anderen Computer in Ihrem Netzwerk benötigt. -Wenn Sie mit einem CVCS vertraut sind, bei dem die meisten Operationen durch Overhead eine Netzwerk-Latenz haben, dann wird diese Eigenschaft von Git Sie glauben lassen, dass Git von „Gottes Segen“ mit übernatürlichen Kräften bedacht wurde. +Die meisten Aktionen in Git benötigen nur lokale Dateien und Ressourcen, um ausgeführt zu werden – im Allgemeinen werden keine Informationen von einem anderen Computer in deinem Netzwerk benötigt. +Wenn du mit einem CVCS vertraut bist, bei dem die meisten Operationen durch Netzwerk-Latenzen langsam sind, dann wird diese Eigenschaft von Git glauben lassen, dass Git von mit übernatürlichen Kräften bedacht wurde. Die allermeisten Operationen können nahezu ohne jede Verzögerung ausgeführt werden, da die vollständige Historie eines Projekts bereits auf dem jeweiligen Rechner verfügbar ist. Um beispielsweise die Historie des Projekts zu durchsuchen, braucht Git sie nicht von einem externen Server zu holen – es liest diese einfach aus der lokalen Datenbank. Das heißt, die vollständige Projekthistorie ist ohne jede Verzögerung verfügbar. -Wenn man sich die Änderungen einer aktuellen Version einer Datei im Vergleich zu vor einem Monat anschauen möchte, dann kann Git den Stand von vor einem Monat in der lokalen Historie nachschlagen und einen lokalen Vergleich zur vorliegenden Datei durchführen. Für diesen Anwendungsfall benötigt Git keinen externen Server, weder um Dateien dort nachzuschlagen, noch um Unterschiede dort bestimmen zu lassen. +Wenn man sich die Änderungen einer aktuellen Version einer Datei im Vergleich zu der vor einem Monat anschauen möchte, dann kann Git den Stand von vor einem Monat in der lokalen Historie nachschlagen und einen lokalen Vergleich zur vorliegenden Datei durchführen. Für diesen Anwendungsfall benötigt Git keinen externen Server, weder um Dateien dort nachzuschlagen, noch um Unterschiede zu finden. Das bedeutet natürlich außerdem, dass es fast nichts gibt, was man nicht tun kann, nur weil man gerade offline ist oder keinen Zugriff auf ein VPN hat. -Wenn man also gerade im Flugzeug oder Zug ein wenig arbeiten will, kann man problemlos seine Arbeit einchecken und dann, wenn man wieder mit einem Netzwerk verbunden ist, die Dateien auf einen Server hochladen. +Wenn man also gerade im Flugzeug oder Zug ein wenig arbeiten will, kann man problemlos seine Arbeit einchecken und dann, wenn man wieder mit einem Netzwerk verbunden ist, die Dateien auf den Server hochladen. Wenn man zu Hause sitzt, aber der VPN-Client gerade mal wieder nicht funktioniert, kann man immer noch arbeiten. Bei vielen anderen Systemen wäre dies unmöglich oder äußerst kompliziert umzusetzen. -In Perforce können Sie beispielsweise nicht viel tun, wenn Sie nicht mit dem Server verbunden sind; in Subversion und CVS können Sie Dateien bearbeiten, aber Sie können keine Änderungen zu Ihren Daten übertragen (weil die Datenbank offline ist). -Das scheint keine große Sache zu sein, aber Sie werden überrascht sein, was für einen großen Unterschied es machen kann. +In Perforce kannst du beispielsweise nicht viel tun, wenn du nicht mit dem Server verbunden bist; in Subversion und CVS kannst du Dateien bearbeiten, aber du kannst keine Änderungen zu deinen Daten übertragen (weil die Datenbank offline ist). +Das scheint keine große Sache zu sein, aber du wirst überrascht sein, was für einen großen Unterschied das machen kann. ==== Git stellt Integrität sicher @@ -54,7 +54,7 @@ Git basiert auf dieser Funktionalität und sie ist ein integraler Teil der Git-P Man kann Informationen deshalb z.B. nicht während der Übermittlung verlieren oder unwissentlich beschädigte Dateien verwenden, ohne dass Git in der Lage wäre, dies festzustellen. Der Mechanismus, den Git verwendet, um diese Prüfsummen zu erstellen, heißt SHA-1-Hash.(((SHA-1))) -Eine solche Prüfsumme ist eine 40-Zeichen lange Zeichenkette, die aus hexadezimalen Zeichen (0-9 und a-f) besteht und wird von Git aus den Inhalten einer Datei oder Verzeichnisstruktur berechnet. +Eine solche Prüfsumme ist eine 40-Zeichen lange Zeichenkette, die aus hexadezimalen Zeichen (0-9 und a-f) besteht. Sie wird von Git aus den Inhalten einer Datei oder Verzeichnisstruktur berechnet. Ein SHA-1-Hash sieht wie folgt aus: [source] @@ -67,12 +67,12 @@ Tatsächlich speichert Git alles in seiner Datenbank nicht nach Dateinamen, sond ==== Git fügt im Regelfall nur Daten hinzu -Wenn Sie Aktionen in Git durchführen, werden fast alle von ihnen nur Daten zur Git-Datenbank _hinzufügen_. +Wenn du Aktionen in Git durchführen, werden diese fast immer nur Daten zur Git-Datenbank _hinzufügen_. Deshalb ist es sehr schwer, das System dazu zu bewegen, irgendetwas zu tun, das nicht wieder rückgängig zu machen ist, oder dazu, Daten in irgendeiner Form zu löschen. Wie in jedem anderen VCS, kann man in Git Daten verlieren oder durcheinander bringen, solange man sie noch nicht eingecheckt hat. Aber sobald man einen Schnappschuss in Git eingecheckt hat, ist es sehr schwierig, diese Daten wieder zu verlieren, insbesondere wenn man regelmäßig seine lokale Datenbank auf ein anderes Repository hochlädt. Unter anderem deshalb macht es so viel Spaß mit Git zu arbeiten. Man weiß genau, man kann ein wenig experimentieren, ohne befürchten zu müssen, irgendetwas zu zerstören oder durcheinander zu bringen. -Wer sich genauer dafür interessiert, wie Git Daten speichert und wie man Daten, die scheinbar verloren sind, wiederherstellen kann, dem wird das Kapitel 2, <>, ans Herz gelegt. +Wer sich genauer dafür interessiert, wie Git Daten speichert und wie man Daten, die scheinbar verloren sind, wiederherstellen kann, dem sei das Kapitel 2, <>, ans Herz gelegt. ==== Die drei Zustände @@ -83,27 +83,27 @@ Git definiert drei Hauptzustände, in denen sich eine Datei befinden kann: commi * *Staged* bedeutet, dass eine geänderte Datei in ihrem gegenwärtigen Zustand für den nächsten Commit vorgemerkt ist. * *Committed* bedeutet, dass die Daten sicher in der lokalen Datenbank gespeichert sind. -Das führt uns zu den drei Hauptbereichen eines Git-Projekts: dem Verzeichnisbaum, der sogenannten Staging-Area und dem Git-Verzeichnis. +Das führt uns zu den drei Hauptbereichen eines Git-Projekts: dem Verzeichnisbaum (engl. Working Tree), der sogenannten Staging-Area und dem Git-Verzeichnis. .Verzeichnisbaum, Staging-Area und Git-Verzeichnis image::images/areas.png["Working tree, staging area, and Git directory."] -Der Verzeichnisbaum ist ein einzelner Abschnitt einer Version des Projekts. -Diese Dateien werden aus der komprimierten Datenbank im Git-Verzeichnis geholt und auf der Festplatte so abgelegt, damit Sie sie verwenden oder ändern können. +Der Verzeichnisbaum ist ein einzelner Checkout einer Version des Projekts. +Diese Dateien werden aus der komprimierten Datenbank im Git-Verzeichnis geholt und auf der Festplatte so abgelegt, damit du sie verwenden oder ändern kannst. -Die Staging-Area ist in der Regel eine Datei, die sich in Ihrem Git-Verzeichnis befindet und Informationen darüber speichert, was in Ihren nächsten Commit einfließen soll. +Die Staging-Area ist in der Regel eine Datei, die sich in deinem Git-Verzeichnis befindet und Informationen darüber speichert, was in deinem nächsten Commit einfließen soll. Der technische Name im Git-Sprachgebrauch ist „Index“, aber der Ausdruck „Staging-Area“ funktioniert genauso gut. -Im Git-Verzeichnis werden die Metadaten und die Objektdatenbank für Ihr Projekt gespeichert. +Im Git-Verzeichnis werden die Metadaten und die Objektdatenbank für dein Projekt gespeichert. Das ist der wichtigste Teil von Git, dieser Teil wird kopiert, wenn man ein Repository von einem anderen Rechner _klont_. Der grundlegende Git-Arbeitsablauf sieht in etwa so aus: -1. Sie ändern Dateien in Ihrem Verzeichnisbaum. -2. Sie stellen selektiv Änderungen bereit, die Sie bei Ihrem nächsten Commit berücksichtigen möchten, wodurch nur diese Änderungen in den Staging-Bereich aufgenommen werden. -3. Sie führen einen Commit aus, der die Dateien so übernimmt, wie sie sich in der Staging-Area befinden und diesen Snapshot dauerhaft in Ihrem Git-Verzeichnis speichert. +1. Du änderst Dateien in deinem Verzeichnisbaum. +2. Du stellst selektiv Änderungen bereit, die du bei deinem nächsten Commit berücksichtigen möchtest, wodurch nur diese Änderungen in den Staging-Bereich aufgenommen werden. +3. Du führst einen Commit aus, der die Dateien so übernimmt, wie sie sich in der Staging-Area befinden und diesen Snapshot dauerhaft in deinem Git-Verzeichnis speichert. Wenn sich eine bestimmte Version einer Datei im Git-Verzeichnis befindet, wird sie als _committed_ betrachtet. Wenn sie geändert und in die Staging-Area hinzugefügt wurde, gilt sie als für den Commit _vorgemerkt_ (engl. _staged_). Und wenn sie geändert, aber noch nicht zur Staging-Area hinzugefügt wurde, gilt sie als _geändert_ (engl. _modified_). -Im Kapitel 2, <>, werden diese drei Zustände noch näher erläutert und wie man diese sinnvoll einsetzen kann oder alternativ, wie man den Zwischenschritt der Staging-Area überspringen kann. +Im Kapitel 2, <>, werden diese drei Zustände noch näher erläutert und wie man diese sinnvoll einsetzen kann oder alternativ, wie man den Zwischenschritt der Staging-Area überspringen kann. \ No newline at end of file diff --git a/book/introduction.asc b/book/introduction.asc index a84d8365..55f94d80 100644 --- a/book/introduction.asc +++ b/book/introduction.asc @@ -4,59 +4,57 @@ include::translation_note.asc[] == Einleitung -Sie sind im Begriff, viele Stunden mit dem Lesen eines Buches über Git zu verbringen. -Nehmen wir uns eine Minute Zeit, um zu erklären, was wir für Sie bereithalten. -Hier finden Sie eine kurze Zusammenfassung der zehn Kapitel und drei Anhänge dieses Buches. +Du bist im Begriff, viele Stunden mit dem Lesen eines Buches über Git zu verbringen. +Nehmen wir uns eine Minute Zeit, um zu erklären, was wir für dich bereithalten. +Hier findest du eine kurze Zusammenfassung der zehn Kapitel und drei Anhänge dieses Buches. -In *Kapitel 1* werden wir Version Control Systeme (VCSs) und die Grundlagen von Git behandeln – kein technisches Fachwissen, nur das was mit Git verbunden ist, warum es in einem Land voller VCSs entstanden ist, was es auszeichnet und warum so viele Menschen es benutzen. -Dann werden wir beschreiben, wie Sie Git herunterladen und zum ersten Mal einrichten können, wenn Sie es noch nicht auf Ihrem System installiert haben. +In *Kapitel 1* werden wir Version Control Systeme (VCSs) und die Grundlagen von Git behandeln – kein technisches Zeug: was Git ist, warum es in einem Land voller VCSs überhaupt entstanden ist, was es auszeichnet und warum so viele Menschen es benutzen. +Dann werden wir beschreiben, wie du Git herunterladen und initial einrichten kannst, wenn du es noch nicht auf deinem System installiert hast. -In *Kapitel 2* gehen wir auf die grundlegende Git-Verwendung ein – wie Sie Git in den 80% der Fälle verwenden, denen Sie am häufigsten begegnen. -Nachdem Sie dieses Kapitel gelesen haben, sollten Sie in der Lage sein, ein Repository zu klonen, zu sehen, was in der Verlaufshistorie des Projekts passiert ist, Dateien zu modifizieren und mit Anpassungen beizutragen. -Wenn das Buch zu diesem Zeitpunkt spontan in Flammen aufgeht, sollten Sie in der Zeit, die Sie brauchen, um sich ein weiteres Exemplar zu holen, bereits ziemlich versiert im Umgang mit Git sein. +In *Kapitel 2* gehen wir auf die grundlegende Git-Verwendung ein – wie du Git in den 80% der Fälle verwendest, die dir wahrscheinlich am häufigsten begegnen werden. +Nachdem du dieses Kapitel gelesen haben, solltest du in der Lage sein, ein Repository zu klonen, zu sehen, was in seiner Verlaufshistorie passiert ist, Dateien zu modifizieren und Änderungen beizutragen. +Wenn das Buch zu diesem Zeitpunkt spontan in Flammen aufgeht, solltest du in der Zeit, die du brauchst, um dir ein weiteres Exemplar zu holen, bereits ziemlich versiert im Umgang mit Git sein. In *Kapitel 3* geht es um das Branching-Modell von Git, das oft als Gits Killer-Funktion beschrieben wird. -Hier erfahren Sie, was Git wirklich von der Masse abhebt. -Wenn Sie das Kapitel zu Ende gebracht haben, werden Sie vielleicht in einem ruhigen Moment darüber nachdenken, wie sie bisher ohne das Branching von Git leben konnten. +Hier erfährst du, was Git wirklich von der Masse abhebt. +Wenn du das Kapitel zu Ende gebracht hast, wirst du vielleicht in einem ruhigen Moment darüber nachdenken, wie du bisher ohne Gits Branching hast Leben können (du wirst keine Antwort finden :-)). *Kapitel 4* befasst sich mit Git auf dem Server. -Mit diesem Kapitel wenden wir uns an diejenigen von Ihnen, die Git innerhalb Ihrer Organisation oder auf Ihrem eigenen persönlichen Server für die gemeinsame Entwicklung einrichten möchten. -Wir werden auch verschiedene Hosting-Optionen erörtern, falls Sie es vorziehen, dass jemand anderes diese Aufgabe für Sie übernimmt. +Mit diesem Kapitel wenden wir uns an diejenigen von euch, die Git innerhalb Ihrer Organisation oder auf Ihrem eigenen persönlichen Server für die gemeinsame Entwicklung einrichten möchten. +Wir werden auch verschiedene Hosting-Optionen erörtern, falls du es vorziehst, dass jemand anderes diese Aufgabe für dich übernimmt. -*Kapitel 5* geht ausführlich auf verschiedene dezentrale Workflows ein und wie man sie mit Git realisiert. -Wenn Sie dieses Kapitel durchgearbeitet haben, sollten Sie in der Lage sein, professionell mit mehreren Remote-Repositorys zu arbeiten, Git über E-Mail zu verwenden und geschickt mit zahlreichen Remote-Branches und beigesteuerten Patches zu hantieren. +*Kapitel 5* geht ausführlich auf verschiedene dezentrale Workflows ein und wie man sie mit Git realisieren kann. +Wenn du dieses Kapitel durchgearbeitet hast, solltest du in der Lage sein, professionell mit mehreren Remote-Repositorys zu arbeiten, Git über E-Mail zu verwenden und geschickt mit zahlreichen Remote-Branches und beigesteuerten Patches zu hantieren. *Kapitel 6* befasst sich detailliert mit dem GitHub-Hosting-Service und dem Tooling. -Wir behandeln die Anmeldung und Verwaltung eines Kontos, die Erstellung und Nutzung von Git-Repositorys, gemeinsame Workflows, um zu Projekten beizutragen und Beiträge für Ihre Projekte anzunehmen, die Programmoberfläche von GitHub und viele kleine Tipps, die Ihnen das tägliche Arbeiten im Allgemeinen erleichtern. +Wir behandeln die Anmeldung und Verwaltung eines Kontos, die Erstellung und Nutzung von Git-Repositorys, Git-Workflows, um zu Projekten beizutragen und Beiträge für deine Projekte anzunehmen, die Programmoberfläche von GitHub und viele kleine Tipps, die dir das tägliche Arbeiten im Allgemeinen erleichtern. *Kapitel 7* befasst sich mit anspruchsvollen Git-Befehlen. - Hier erfahren Sie mehr über Themen wie das Beherrschen des „furchterregenden“ Reset-Befehls, die Verwendung der Binärsuche zur Identifizierung von Fehlern, die Bearbeitung des Verlaufs, die detaillierte Auswahl der Revision und vieles mehr. - Dieses Kapitel wird Ihr Wissen über Git abrunden, so dass Sie ein echter Meister werden. + Hier erfährst du mehr über Themen wie das Beherrschen des „furchterregenden“ Reset-Befehls, die Verwendung der Binärsuche zur Identifizierung von Fehlern, die Bearbeitung des Verlaufs, die detaillierte Auswahl der Revision und vieles mehr. + Dieses Kapitel wird dein Wissen über Git perfektionieren, so dass du zu ein echter Meister wirst. *Kapitel 8* behandelt die Konfiguration Ihrer individuellen Git-Umgebung. -Dazu gehört die Einrichtung von Hook-Skripten zur Durchsetzung oder Unterstützung angepasster Regeln und die Verwendung von Konfigurationseinstellungen für die Benutzerumgebung, damit Sie so arbeiten können, wie sie es sich vorstellen. -Wir befassen uns auch mit der Erstellung eigener Skripte zur Durchsetzung einer benutzerdefinierten Commit-Richtlinie. +Dazu gehört die Einrichtung von Hook-Skripten zur Umsetzung oder Unterstützung eigener Regeln und die Verwendung von Konfigurationseinstellungen für die Benutzerumgebung, damit du so arbeiten kannst, wie du es dir vorstellst. +Wir befassen uns auch mit der Erstellung eigener Skripte zur Umsetzung einer benutzerdefinierten Commit-Richtlinie. *Kapitel 9* beschäftigt sich mit Git und anderen VCS-Systemen. Dazu gehört die Verwendung von Git in einer Subversion-Umgebung (SVN-Umgebung) und die Umwandlung von Projekten aus anderen VCSs nach Git. -Viele Unternehmen verwenden immer noch SVN und haben nicht vor, etwas zu ändern, aber an dieser Stelle haben Sie die unglaubliche Leistungsfähigkeit von Git kennengelernt. -Dieses Kapitel zeigt Ihnen, wie Sie damit umgehen können, wenn Sie noch einen SVN-Server verwenden müssen. -Wir besprechen auch, wie man Projekte aus unterschiedlichen Systemen importiert, falls Sie alle davon überzeugt haben, den Sprung zu wagen. +Viele Unternehmen verwenden immer noch SVN und haben nicht vor, etwas zu ändern. Du hast jedoch die unglaubliche Leistungsfähigkeit von Git kennengelernt. Dieses Kapitel zeigt dir, wie du damit umgehen kannst, wenn du noch einen SVN-Server verwenden musst. +Wir besprechen auch, wie man Projekte aus unterschiedlichen Systemen importiert, wenn du dann (hoffentlich) alle davon überzeugt hast, den Sprung nach Git zu wagen. *Kapitel 10* vertieft die dunklen und zugleich wundervollen Tiefen der Git-Interna. -Jetzt, da Sie alles über Git wissen und es mit Macht und Eleganz bedienen können, können Sie weiter darüber reden, wie Git seine Objekte speichert, was das Objektmodell ist, Einzelheiten zu Packfiles, Server-Protokollen und vielem mehr. -Im gesamten Buch werden wir auf Abschnitte dieses Kapitels Bezug nehmen. -Falls Sie an diesem Punkt das Bedürfnis haben, tiefer in die technischen Details einzutauchen (und so sind wie wir), sollten Sie vielleicht zuerst Kapitel 10 lesen. -Das überlassen wir ganz Ihnen. +Jetzt, da du alles über Git weißt und es mit Macht und großer Eleganz bedienen kannst, kannst du weiter darüber reden, wie Git seine Objekte speichert, was das Objektmodell ist, Einzelheiten zu Packfiles, Server-Protokollen und vielem mehr. +Im gesamten Buch werden wir auf Abschnitte dieses Kapitels Bezug nehmen. Falls du an diesem Punkt das Bedürfnis hast, tiefer in die technischen Details einzutauchen (so wie wir), solltest du vielleicht zuerst Kapitel 10 lesen. +Das überlassen wir ganz dir. In *Anhang A* schauen wir uns eine Reihe von Beispielen für den Git-Einsatz in verschiedenen speziellen Anwendungsumgebungen an. -Wir befassen uns mit einer Vielzahl verschiedener GUIs und Entwicklungs-Umgebungen, in denen Sie Git einsetzen könnten. -Wenn Sie an einem Überblick über die Verwendung von Git in Ihrer Shell, Ihrer IDE oder Ihrem Texteditor interessiert sind, schauen Sie hier nach. +Wir befassen uns mit einer Vielzahl verschiedener GUIs und Entwicklungs-Umgebungen, in denen du Git einsetzen kannst. +Wenn du an einem Überblick über die Verwendung von Git in deiner Shell, deiner IDE oder deinem Texteditor interessiert bist, schaue hier nach. In *Anhang B* erkunden wir das Scripting und die Erweiterung von Git durch Tools wie libgit2 und JGit. -Wenn Sie an der Entwicklung komplexer, schneller und benutzerdefinierter Tools interessiert sind und einen Low-Level-Git-Zugang benötigen, können Sie hier nachlesen, wie diese Szene ausschaut. +Wenn du an der Entwicklung komplexer, schneller und benutzerdefinierter Tools interessiert bist und einen Low-Level-Git-Zugang benötigst, kannst du hier nachlesen, wie so etwas functioniert. -Schließlich gehen wir in *Anhang C* alle wichtigen Git-Befehle einzeln durch und wiederholen, wo wir sie in dem Buch behandelt haben und wie wir sie genutzt haben. -Wenn Sie wissen möchten, wo in dem Buch wir einen bestimmten Git-Befehl verwendet haben, können Sie ihn hier nachschlagen. +Schließlich gehen wir in *Anhang C* alle wichtigen Git-Befehle einzeln durch und wiederholen, wo wir sie im Buch behandelt haben und wie wir sie genutzt haben. +Wenn du wissen möchtest, wo in dem Buch wir einen bestimmten Git-Befehl verwendet haben, kannst du ihn hier nachschlagen. -Lassen Sie uns beginnen. +Lass uns beginnen. \ No newline at end of file diff --git a/book/preface_ben.asc b/book/preface_ben.asc index ac7b4333..e7aa836d 100644 --- a/book/preface_ben.asc +++ b/book/preface_ben.asc @@ -5,8 +5,8 @@ Die erste Ausgabe dieses Buches war der Grund, warum ich mich für Git begeister Es war mein Einstieg in eine Form der Softwareentwicklung, die sich natürlicher anfühlte als alles andere, das ich zuvor gesehen hatte. Ich war bis dahin mehrere Jahre lang Entwickler gewesen, doch jetzt war die richtige Wendung, die mich auf einen viel interessanteren Weg führte als den, auf dem ich bisher unterwegs war. -Jetzt, Jahre später, bin ich ein Teil einer bedeutenden Git-Implementierung. Ich habe für das größte Git-Hosting-Unternehmen gearbeitet und ich bin durch die ganze Welt gereist, um Menschen Git beizubringen. -Als Scott mich fragte, ob ich Interesse hätte, an der zweiten Ausgabe des Buches mitzuarbeiten, musste ich nicht einmal darüber nachdenken. +Jetzt, Jahre später, trage ich etwas zu einer bedeutenden Git-Implementierung bei. Ich habe für das größte Git-Hosting-Unternehmen gearbeitet und ich bin durch die ganze Welt gereist, um Menschen Git beizubringen. +Als Scott mich fragte, ob ich Interesse hätte, an der zweiten Ausgabe des Buches mitzuarbeiten, musste ich nicht lange darüber nachdenken. Es war mir eine große Freude und ein Privileg, an diesem Buch mitzuwirken. -Ich hoffe, es wird Ihnen genauso helfen wie mir. +Ich hoffe, es wird euch genauso helfen wie mir. diff --git a/book/preface_schacon.asc b/book/preface_schacon.asc index 610e6313..07e64808 100644 --- a/book/preface_schacon.asc +++ b/book/preface_schacon.asc @@ -3,13 +3,13 @@ Herzlich willkommen bei der zweiten Auflage von Pro Git. Seit die erste Auflage vor fast vier Jahren veröffentlicht wurde, hat sich eine Menge in der Welt von Git verändert und doch sind viele wichtige Dinge gleich geblieben. -Das Kernteam von Git stellt sicher, und das machen sie ziemlich gut, dass die grundlegenden Befehle und Struktur abwärtskompatibel bleiben. Und doch gab es ein paar bedeutende Ergänzungen in Git und Weiterentwicklungen rund um die Git-Community. +Das Kernteam von Git stellt sicher, und das machen sie ziemlich gut, dass die grundlegenden Befehle und Struktur abwärtskompatibel bleiben. Und doch gab es ein paar bedeutende Ergänzungen in Git und andere Weiterentwicklungen rund um die Git-Community. In der zweiten Auflage des Buches sollen diese Änderungen behandelt werden. Außerdem wurden viele Passagen aktualisiert, so dass vor allem neue Git Benutzer leichter einsteigen können. Zu der Zeit, als ich die erste Edition geschrieben habe, war Git relativ schwierig zu bedienen und kaum benutzerfreundlich. -Es richtete sich eher an die fortgeschrittenen Anwender. +Es richtete sich eher an fortgeschrittenen Anwender. In einigen Communities wurde es immer beliebter, aber es war lange nicht so allgegenwärtig, wie es heute ist. -Inzwischen verwendet nahezu jede im Open Source Bereich tätige Community das Werkzeug. +Inzwischen verwendet nahezu jede im Open Source Bereich tätige Community Git. Es gab unglaubliche Fortschritte auf Windows-Betriebssystemen, zahlreiche grafische Oberflächen für alle Plattformen wurden veröffentlicht und die Integration in Entwicklungsumgebungen und im Geschäftsbereich wurde verbessert. Das hätte ich mir vor vier Jahren nicht vorstellen können. In dieser neuen Auflage möchte ich besonders die zahlreichen, neu erschlossenen Bereiche der Git Community thematisieren. @@ -21,7 +21,7 @@ Während ich dieses Vorwort schreibe, kündigt GitHub unser 10-millionstes, geho Man kann es gut oder schlecht finden, aber GitHub hat große Teile der Open Source Community verändert, wie ich es mir in der Zeit, als ich das erste Buch geschrieben habe, in meinen kühnsten Träumen nicht hätte vorstellen können. In der ersten Auflage von Pro Git habe ich ein kurzes Kapitel über GitHub verfasst. Ich wollte damit zeigen, wie Git Hosting aussehen kann. Ich habe mich beim Schreiben des Kapitels aber nie richtig wohl gefühlt. -Ich mochte es nicht, dass ich über etwas schreibe, was aus einer Community heraus entstanden ist und in das meine Firma involviert ist. +Ich mochte nicht, dass ich über etwas schreibe, was aus einer Community heraus entstanden ist und in das meine Firma involviert ist. Ich mag diesen Interessenkonflikt immer noch nicht, aber die Bedeutung von GitHub in der Git Community ist unverkennbar. Ich habe mich deshalb dazu entschlossen, dass angesprochene Kapitel umzuschreiben und statt einem Beispiel für Git Hosting möchte ich genauer erklären, was GitHub ist und wie man es effektiv nutzen kann. Wenn man vor hat, sich mit Git zu beschäftigen und man weiß, wie GitHub funktioniert, hilft es einem sehr gut, ein Teil einer riesigen Gemeinschaft zu werden. Das kann sehr wertvoll sein und schlussendlich ist es dann auch egal, für welchen Git Hosting Partner man sich für seinen eigenen Code entscheidet. @@ -32,4 +32,4 @@ Deshalb habe ich die meisten Beispiele angepasst und statt SSH wird jetzt HTTP v Es war großartig dabei zuzuschauen, wie sich Git die letzten paar Jahre weiterentwickelt hat, von einem doch eher obskuren Versionskontrollsystem zu einem dominierenden Versionskontrollsystem im Open Source und Geschäftsbereich. Ich bin glücklich, wie es bisher mit Pro Git gelaufen ist und dass es einer der wenigen technischen Bücher auf dem Markt ist, welches sowohl ziemlich erfolgreich als auch uneingeschränkt Open Source ist. -Ich hoffe, Sie haben viel Spaß mit der neuen Auflage von Pro Git. +Ich hoffe, du hast viel Spaß mit der neuen Auflage von Pro Git. \ No newline at end of file diff --git a/book/translation_note.asc b/book/translation_note.asc index 488a7eb9..e22fc3b6 100644 --- a/book/translation_note.asc +++ b/book/translation_note.asc @@ -4,10 +4,10 @@ Die vorliegende Übersetzung des englischen Original-Textes wurde ausschließlic Wir bitten um Nachsicht, falls die eine oder andere Passage nicht sonderlich elegant übersetzt wurde. -Wir ermuntern jedem, der einen Fehler entdeckt oder eine Verbesserung vorschlagen kann, dazu im deutschen Reposority entweder einen https://github.com/progit/progit2-de/pulls[Pull-Request] oder ein https://github.com/progit/progit2-de/issues[Issue] zu starten. +Wir ermuntern jedem, der einen Fehler entdeckt oder eine Verbesserung vorschlagen kann dazu, im deutschen Repository entweder einen https://github.com/progit/progit2-de/pulls[Pull-Request] oder ein https://github.com/progit/progit2-de/issues[Issue] zu starten. ==== Aktualität ==== Da auch die Übernahme von Änderungen im englischen Original-Text nur von Zeit zu Zeit erfolgt, kann es vorkommen, dass der deutsche Text auf einer etwas älteren Version der englischen Version basiert. -Falls Sie im deutschen Buch Unklarheiten finden sollten, dann ist es ratsam, zum Vergleich immer im https://git-scm.com/book/en/v2[englischen Buch] nachzuschlagen. +Falls du im deutschen Buch Unklarheiten finden solltest, dann ist es ratsam, zum Vergleich immer im https://git-scm.com/book/en/v2[englischen Buch] nachzuschlagen. diff --git a/ch01-getting-started.asc b/ch01-getting-started.asc index efce1f8c..08681f62 100644 --- a/ch01-getting-started.asc +++ b/ch01-getting-started.asc @@ -2,9 +2,8 @@ == Erste Schritte In diesem Kapitel geht es um den Einstieg in Git. -Wir erklären zunächst einige Hintergrundinformationen zu Versionskontrolltools, gehen dann dazu über, wie Sie Git auf Ihrem System zum Laufen bringen und wie Sie es schließlich so einrichten, dass Sie damit arbeiten können. -Am Ende dieses Kapitels sollten Sie verstehen, wozu Git gut ist und weshalb man es verwenden sollte und Sie sollten in der Lage sein, mit Git loslegen zu können. -Am Ende dieses Kapitels sollten Sie verstehen, warum es Git gibt, warum Sie es verwenden sollten und gut gerüstet sein, um die ersten Schritte mit Git zu machen. +Wir erklären zunächst einige Hintergrundinformationen zu Versionskontrolltools, gehen dann dazu über, wie du Git auf deinem System zum Laufen bringst und wie du es schließlich so einrichtest, dass du damit arbeiten kannst. +Am Ende dieses Kapitels solltest du verstehen, wozu Git gut ist und weshalb man es verwenden sollte. Du solltest dann in der Lage sein, mit deiner Arbeit in Git loslegen zu können. include::book/01-introduction/sections/about-version-control.asc[] @@ -22,6 +21,6 @@ include::book/01-introduction/sections/help.asc[] === Zusammenfassung -Sie sollten nun ein grundlegendes Verständnis davon haben, was Git ist und wie es sich von anderen zentralisierten Versionskontrollsystemen unterscheidet, die Sie möglicherweise zuvor verwendet haben. -Sie sollten jetzt auch eine funktionierende Version von Git auf Ihrem System haben, die mit Ihrer persönlichen Identität eingerichtet ist. +Du solltest nun ein grundlegendes Verständnis davon haben, was Git ist und wie es sich von anderen zentralisierten Versionskontrollsystemen unterscheidet, die du möglicherweise zuvor verwendet hast. +Du solltest nun auch eine funktionierende Installation von Git auf deinem System haben, die mit deiner persönlichen Identität eingerichtet ist. Es ist jetzt an der Zeit, einige Git-Grundlagen zu erlernen.