Merge pull request #26 from max123kl/chapter-09-6

Kapitel 9 komplett übersetzt

Author: max123kl

book/02-git-basics/sections/getting-a-repository.asc

@@ -38,7 +38,7 @@ $ git init
 
 Der Befehl erzeugt ein Unterverzeichnis `.git`, in dem alle relevanten Git Repository Daten enthalten sind, also ein Git Repository Grundgerüst.
 Zu diesem Zeitpunkt werden noch keine Dateien in Git versioniert.
-(In Kapitel 10, <<ch10-git-internals#ch10-git-internals,Git Internas>>, finden Sie weitere Informationen, welche Dateien im `.git` Verzeichnis enthalten sind und was ihre Aufgabe ist.)(((Git Befehle, init)))
+(In Kapitel 10, <<ch10-git-internals#ch10-git-internals,Git Interna>>, finden Sie weitere Informationen, welche Dateien im `.git` Verzeichnis enthalten sind und was ihre Aufgabe ist.)(((Git Befehle, init)))
 
 Wenn Sie bereits existierende Dateien versionieren möchten (und es sich nicht nur um ein leeres Verzeichnis handelt), dann sollten Sie den aktuellen Stand in einem initialen Commit starten.
 Mit dem Befehl `git add` legen Sie fest, welche Dateien versioniert werden sollen und mit dem Befehl `git commit` erzeugen Sie einen neuen Commit:

book/04-git-server/sections/protocols.asc

@@ -29,7 +29,7 @@ $ git clone file:///srv/git/project.git
 Git funktioniert etwas anders, wenn Sie `file://` explizit am Anfang der URL angeben.
 Wenn Sie nur den Pfad angeben, versucht Git, Hardlinks zu verwenden oder die benötigten Dateien direkt zu kopieren.
 Wenn Sie `file://` angeben, löst Git Prozesse aus, die normalerweise zum Übertragen von Daten über ein Netzwerk verwendet werden, was im Allgemeinen viel weniger effizient ist.
-Der Hauptgrund für die Angabe des Präfix `file://` ist, wenn Sie eine saubere Kopie des Repositorys mit fremden Referenzen oder weggelassenen Objekten wünschen – in der Regel nach einem Import aus einem anderen VCS oder ähnlichem (siehe <<ch10-git-internals#ch10-git-internals,Git Internas>> für Wartungsaufgaben.
+Der Hauptgrund für die Angabe des Präfix `file://` ist, wenn Sie eine saubere Kopie des Repositorys mit fremden Referenzen oder weggelassenen Objekten wünschen – in der Regel nach einem Import aus einem anderen VCS oder ähnlichem (siehe <<ch10-git-internals#ch10-git-internals,Git Interna>> für Wartungsaufgaben.
 Wir werden hier den normalen Pfad verwenden, denn das ist fast immer schneller.
 
 Um ein lokales Repository zu einem bestehenden Git-Projekt hinzuzufügen, kann so vorgegangen werden:
@@ -113,7 +113,7 @@ $ git clone https://example.com/gitproject.git
 ----
 
 In diesem speziellen Fall verwenden wir den Pfad `/var/www/htdocs`, der für Apache-Installationen üblich ist, Sie können aber jeden statischen Webserver verwenden – legen Sie einfach das leere Repository in seinen Pfad.
-Die Git-Daten werden als einfache statische Dateien bereitgestellt (siehe Kapitel <<ch10-git-internals#ch10-git-internals,Git Internas>> für Bedienungsdetails).
+Die Git-Daten werden als einfache statische Dateien bereitgestellt (siehe Kapitel <<ch10-git-internals#ch10-git-internals,Git Interna>> für Bedienungsdetails).
 
 Im Allgemeinen würden Sie sich entweder einen Smart HTTP-Server zum Lesen und Schreiben betreiben oder die Dateien einfach als schreibgeschützt im Dumb-Modus zur Verfügung stellen.
 Seltener wird ein Mix aus beiden Diensten angeboten.

book/05-distributed-git/sections/distributed-workflows.asc

@@ -1,47 +1,47 @@
 === Verteilter Arbeitsablauf
 
 (((workflows)))
-Im Gegensatz zu CVCSs (Centralized Version Control Systems - Zentrale Versionsverwaltungs Systeme) können Sie dank der verteilten Struktur von Git die Zusammenarbeit von Entwicklern in Projekten wesentlich flexibler gestalten. 
+Im Gegensatz zu CVCSs (Centralized Version Control Systems - Zentrale Versionsverwaltungs Systeme) können Sie dank der verteilten Struktur von Git die Zusammenarbeit von Entwicklern in Projekten wesentlich flexibler gestalten.
 In zentralisierten Systemen ist jeder Entwickler ein gleichwertiger Netzknoten, der mehr oder weniger gleichermaßen mit einem zentralen System arbeitet.
-In Git ist jedoch jeder Entwickler potentiell beides -  sowohl Netzknoten als auch zentrales System. Das heißt, jeder Entwickler kann sowohl Code für andere Repositorys bereitstellen als auch ein öffentliches Repository verwalten, auf dem andere ihre Arbeit aufbauen und zu dem sie beitragen können. 
-Dies bietet eine Fülle von möglichen Arbeitsabläufen (engl. Workflows) für Ihr Projekt und/oder Ihrem Team, sodass wir einige gängige Paradigmen behandeln, welche die Vorteile dieser Flexibilität nutzen. 
+In Git ist jedoch jeder Entwickler potentiell beides -  sowohl Netzknoten als auch zentrales System. Das heißt, jeder Entwickler kann sowohl Code für andere Repositorys bereitstellen als auch ein öffentliches Repository verwalten, auf dem andere ihre Arbeit aufbauen und zu dem sie beitragen können.
+Dies bietet eine Fülle von möglichen Arbeitsabläufen (engl. Workflows) für Ihr Projekt und/oder Ihrem Team, sodass wir einige gängige Paradigmen behandeln, welche die Vorteile dieser Flexibilität nutzen.
 Wir werden die Stärken und möglichen Schwächen der einzelnen Entwürfe eingehen. Sie können einen einzelnen davon auswählen, um ihn zu nutzen, oder Sie können die Funktionalitäten von allen miteinander kombinieren.
 
 ==== Zentralisierter Arbeitsablauf
 
 (((workflows, centralized)))
-In zentralisierten Systemen gibt es im Allgemeinen ein einziges Modell für die Zusammenarbeit - den zentralisierten Arbeitsablauf. 
+In zentralisierten Systemen gibt es im Allgemeinen ein einziges Modell für die Zusammenarbeit - den zentralisierten Arbeitsablauf.
 Ein zentraler Hub oder _Repository_ kann Quelltext akzeptieren und alle Beteiligten synchronisieren ihre Arbeit damit.
 Eine Reihe von Entwicklern sind Netznoten - Nutzer dieses Hubs - und synchronisieren ihre Arbeit mit diesem einen, zentralen Punkt.
 
 .Zentralisierter Arbeitsablauf.
 image::images/centralized_workflow.png[Zentralisierter Arbeitsablauf.]
 
-Dies bedeutet, wenn zwei Entwickler ein Repository vom Hub klonen und beide Änderungen vornehmen, der erste Entwickler, der die Änderungen zurückgespielt hat, dies problemlos tun kann. 
-Der zweite Entwickler muss jedoch die Arbeit des ersten Entwicklers bei sich einfließen lassen (mergen), bevor seine Änderungen aufgenommen werden können, damit die Änderungen des ersten Entwicklers nicht überschrieben werden. 
+Dies bedeutet, wenn zwei Entwickler ein Repository vom Hub klonen und beide Änderungen vornehmen, der erste Entwickler, der die Änderungen zurückgespielt hat, dies problemlos tun kann.
+Der zweite Entwickler muss jedoch die Arbeit des ersten Entwicklers bei sich einfließen lassen (mergen), bevor seine Änderungen aufgenommen werden können, damit die Änderungen des ersten Entwicklers nicht überschrieben werden.
 Dieses Konzept ist in Git genauso wahr wie in Subversion(((Subversion))) (oder ein anderes beliebiges CVCS), und dieses Konzept funktioniert in Git wunderbar.
 
-Wenn Sie bereits mit einem zentralisierten Arbeitsablauf in Ihrem Unternehmen oder Team vertraut sind, können Sie diesen Ablauf problemlos mit Git weiterverwenden. 
+Wenn Sie bereits mit einem zentralisierten Arbeitsablauf in Ihrem Unternehmen oder Team vertraut sind, können Sie diesen Ablauf problemlos mit Git weiterverwenden.
 Richten Sie einfach ein einziges Repository ein und gewähren Sie allen Mitgliedern Ihres Teams Schreib-Zugriff (push). Git lässt nicht zu, dass Benutzer sich gegenseitig überschreiben.
 
-Sagen wir, John und Jessica fangen beide zur gleichen Zeit mit ihrer Arbeit an. 
-John beendet seine Änderung und lädt diese zum Server hoch. 
-Dann versucht Jessica, ihre Änderungen hochzuladen, aber der Server lehnt sie ab. 
-Ihr wird gesagt, dass sie versucht, Änderungen „non-fast-forward“ zu pushen, und dass sie dies erst tun kann, wenn sie sie bestehende Änderungen abgeholt und mit ihrer lokalen Kopie zusammengeführt hat. 
+Sagen wir, John und Jessica fangen beide zur gleichen Zeit mit ihrer Arbeit an.
+John beendet seine Änderung und lädt diese zum Server hoch.
+Dann versucht Jessica, ihre Änderungen hochzuladen, aber der Server lehnt sie ab.
+Ihr wird gesagt, dass sie versucht, Änderungen „non-fast-forward“ zu pushen, und dass sie dies erst tun kann, wenn sie sie bestehende Änderungen abgeholt und mit ihrer lokalen Kopie zusammengeführt hat.
 Dieser Workflow ist für viele Menschen sehr ansprechend, weil er ein bewährtes Modell ist, mit dem viele bereits bekannt und vertraut sind.
 
-Diese Vorgehensweise ist nicht auf kleine Teams beschränkt. 
+Diese Vorgehensweise ist nicht auf kleine Teams beschränkt.
 Mit dem Verzweigungs-Modell (Branching-Modell) von Git ist es Hunderten von Entwicklern möglich, ein einzelnes Projekt über Dutzende von Branches gleichzeitig erfolgreich zu bearbeiten.
 
 [[_integration_manager]]
 ==== Arbeitsablauf mit Integrationsmanager
 
 (((workflows, integration manager)))
 
-Da Sie in Git über mehrere Remote-Repositorys verfügen können, ist ein Workflow möglich, bei dem jeder Entwickler Schreibzugriff auf sein eigenes, öffentliches Repository und Lesezugriff auf die Repositorys aller anderen Entwickler hat. 
-Dieses Szenario enthält häufig ein zentrales Repository, das das „offizielle“ Projekt darstellt. 
-Um zu diesem Projekt beizutragen, erstellen Sie Ihren eigenen öffentlichen Klon des Projekts und laden Ihre Änderungen dort hoch. 
-Anschließend können Sie eine Anforderung an den Betreuer des Hauptprojekts senden, um Ihre Änderungen zu übernehmen (Pull Request). 
+Da Sie in Git über mehrere Remote-Repositorys verfügen können, ist ein Workflow möglich, bei dem jeder Entwickler Schreibzugriff auf sein eigenes, öffentliches Repository und Lesezugriff auf die Repositorys aller anderen Entwickler hat.
+Dieses Szenario enthält häufig ein zentrales Repository, das das „offizielle“ Projekt darstellt.
+Um zu diesem Projekt beizutragen, erstellen Sie Ihren eigenen öffentlichen Klon des Projekts und laden Ihre Änderungen dort hoch.
+Anschließend können Sie eine Anforderung an den Betreuer des Hauptprojekts senden, um Ihre Änderungen zu übernehmen (Pull Request).
 Der Betreuer kann dann Ihr Repository als Remote hinzufügen, Ihre Änderungen lokal testen, diese in seinem Branch einfließen und in sein öffentliches Repository hochladen.
 Der Prozess funktioniert wie folgt (siehe <<wfdiag_b>>):
 
@@ -57,35 +57,35 @@ Der Prozess funktioniert wie folgt (siehe <<wfdiag_b>>):
 image::images/integration-manager.png[Arbeitsablauf mit Integrationsmanager.]
 
 (((forking)))
-Dies ist ein sehr häufiger Workflow mit Hub-basierten Tools wie GitHub oder GitLab, bei dem es einfach ist, ein Projekt zu „forken“ und Ihre Änderungen in Ihren Fork hochzuladen, damit jeder sie sehen kann. 
-Einer der Hauptvorteile dieses Ansatzes besteht darin, dass Sie weiterarbeiten können und der Verwalter des Haupt-Repositorys Ihre Änderungen jederzeit übernehmen kann. 
+Dies ist ein sehr häufiger Workflow mit Hub-basierten Tools wie GitHub oder GitLab, bei dem es einfach ist, ein Projekt zu „forken“ und Ihre Änderungen in Ihren Fork hochzuladen, damit jeder sie sehen kann.
+Einer der Hauptvorteile dieses Ansatzes besteht darin, dass Sie weiterarbeiten können und der Verwalter des Haupt-Repositorys Ihre Änderungen jederzeit übernehmen kann.
 Die Mitwirkenden müssen nicht warten, bis das Projekt ihre Änderungen übernommen hat - jede Partei kann in ihrem eigenen Tempo arbeiten.
 
-==== Arbeitsablauf mit Diktator und Leutnante
+==== Arbeitsablauf mit Diktator und Leutnants
 
 (((workflows, dictator and lieutenants)))
-Dies ist eine Variante eines Workflows mit vielen Repositorys. 
-Sie wird im Allgemeinen von großen Projekten mit Hunderten von Mitarbeitern verwendet. Ein berühmtes Beispiel ist der Linux-Kernel. 
-Verschiedene Integrationsmanager sind für bestimmte Teile des Repositorys verantwortlich. Sie heißen _Leutnante_. 
-Alle Leutnante haben einen Integrationsmanager, der als der wohlwollende Diktator (benevolent dictator) bezeichnet wird. 
+Dies ist eine Variante eines Workflows mit vielen Repositorys.
+Sie wird im Allgemeinen von großen Projekten mit Hunderten von Mitarbeitern verwendet. Ein berühmtes Beispiel ist der Linux-Kernel.
+Verschiedene Integrationsmanager sind für bestimmte Teile des Repositorys verantwortlich. Sie heißen _Leutnants_.
+Alle Leutnants haben einen Integrationsmanager, der als der wohlwollende Diktator (benevolent dictator) bezeichnet wird.
 Der wohlwollende Diktator pusht von seinem Verzeichnis in ein Referenz-Repository, aus dem alle Beteiligten ihre eigenen Repositorys aktualisieren müssen.
 Dieser Prozess funktioniert wie folgt (siehe <<wfdiag_c>>):
 
-1. Entwickler arbeiten regelmäßig an ihrem Themen Branch und reorganisieren (rebasen) ihre Arbeit auf `master`. 
+1. Entwickler arbeiten regelmäßig an ihrem Themen Branch und reorganisieren (rebasen) ihre Arbeit auf `master`.
    Der `master`-Branch ist der des Referenz-Repositorys, in das der Diktator pusht.
-2. Die Leutnante fassen die Themen Branches der Entwickler mit ihrem `master`-Branch zusammen.
-3. Der Diktator führt die `master`-Branches der Leutnante in den `master`-Branch des Diktators zusammen.
+2. Die Leutnants fassen die Themen Branches der Entwickler mit ihrem `master`-Branch zusammen.
+3. Der Diktator führt die `master`-Branches der Leutnants in den `master`-Branch des Diktators zusammen.
 4. Schließlich pusht der Diktator diesen `master` -Branch in das Referenz-Repository, damit die anderen Entwickler darauf einen Rebase durchführen können.
 
 [[wfdiag_c]]
 .Arbeitsablauf mit wohlwollendem Diktator.
 image::images/benevolent-dictator.png[Arbeitsablauf mit wohlwollendem Diktator.]
 
-Diese Art von Arbeitsablauf ist nicht weit verbreitet, kann jedoch in sehr großen Projekten oder in sehr hierarchischen Umgebungen hilfreich sein. 
+Diese Art von Arbeitsablauf ist nicht weit verbreitet, kann jedoch in sehr großen Projekten oder in sehr hierarchischen Umgebungen hilfreich sein.
 Dies ermöglicht dem Projektleiter (dem Diktator), einen Großteil der Arbeit zu delegieren und große Teilbereiche von Quelltext an mehreren Stellen zu sammeln, bevor diese integriert werden.
 
 ==== Zusammenfassung
 
-Dies sind einige häufig verwendete Workflows, die mit einem verteilten System wie Git möglich sind. Allerdings sind auch viele Variationen möglich, um Ihren eigenen Arbeitsabläufen gerecht zu werden. 
-Jetzt, da Sie (hoffentlich) bestimmen können, welche Kombination von Arbeitsabläufen bei Ihnen funktionieren würde, werden wir einige spezifischere Beispiele davon betrachten, wie man die Hauptaufgaben durchführen kann, welche die unterschiedliche Abläufe ausmachen. 
+Dies sind einige häufig verwendete Workflows, die mit einem verteilten System wie Git möglich sind. Allerdings sind auch viele Variationen möglich, um Ihren eigenen Arbeitsabläufen gerecht zu werden.
+Jetzt, da Sie (hoffentlich) bestimmen können, welche Kombination von Arbeitsabläufen bei Ihnen funktionieren würde, werden wir einige spezifischere Beispiele davon betrachten, wie man die Hauptaufgaben durchführen kann, welche die unterschiedliche Abläufe ausmachen.
 Im nächsten Abschnitt erfahren Sie etwas über gängige Formen der Mitarbeit an einem Projekt.

book/08-customizing-git/sections/policy.asc

@@ -1,5 +1,5 @@
 [[_an_example_git_enforced_policy]]
-=== An Example Git-Enforced Policy
+=== Beispiel für Git-forcierte Regeln
 
 (((policy example)))
 In this section, you'll use what you've learned to establish a Git workflow that checks for a custom commit message format, and allows only certain users to modify certain subdirectories in a project.