Translated the first file distributed-workflows.asc to german

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

@@ -1,90 +1,79 @@
-=== Distributed Workflows
+=== Verteilter Workflow
 
 (((workflows)))
-In contrast with Centralized Version Control Systems (CVCSs), the distributed nature of Git allows you to be far more flexible in how developers collaborate on projects.
-In centralized systems, every developer is a node working more or less equally with a central hub.
-In Git, however, every developer is potentially both a node and a hub; that is, every developer can both contribute code to other repositories and maintain a public repository on which others can base their work and which they can contribute to.
-This presents a vast range of workflow possibilities for your project and/or your team, so we'll cover a few common paradigms that take advantage of this flexibility.
-We'll go over the strengths and possible weaknesses of each design; you can choose a single one to use, or you can mix and match features from each.
+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 Knoten, der mehr oder weniger gleichermaßen mit einem zentralen System arbeitet.
+In Git ist jedoch jeder Entwickler möglicherweise sowohl ein Knoten als auch ein 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 Vielzahl von Workflow-Möglichkeiten für Ihr Projekt und / oder Ihrem Team, sodass wir einige gängige Paradigmen behandeln, die diese Flexibilität nutzen.
+Wir werden die Stärken und möglichen Schwächen der einzelnen Designs untersuchen. Sie können ein einzelnes auswählen oder Features aus jeder kombinieren.
 
-==== Centralized Workflow
+==== Zentralisierter Workflow
 
 (((workflows, centralized)))
-In centralized systems, there is generally a single collaboration model -- the centralized workflow.
-One central hub, or _repository_, can accept code, and everyone synchronizes their work with it.
-A number of developers are nodes -- consumers of that hub -- and synchronize with that centralized location.
+In zentralisierten Systemen gibt es im Allgemeinen ein einziges Kollaborationsmodell - den zentralisierten Workflow.
+Ein zentraler Hub oder _Repository_ kann Code akzeptieren und jeder synchronisiert seine Arbeit mit ihm.
+Eine Reihe von Entwicklern sind Knoten - Verbraucher dieses Hubs - und synchronisieren mit diesem zentralisierten Standort.
 
 .Centralized workflow.
-image::images/centralized_workflow.png[Centralized workflow.]
+image::images/centralized_workflow.png[Zentralisierter Workflow.]
 
-This means that if two developers clone from the hub and both make changes, the first developer to push their changes back up can do so with no problems.
-The second developer must merge in the first one's work before pushing changes up, so as not to overwrite the first developer's changes.
-This concept is as true in Git as it is in Subversion(((Subversion))) (or any CVCS), and this model works perfectly well in Git.
+Dies bedeutet, dass, wenn zwei Entwickler vom Hub klonen und beide Änderungen vornehmen, der erste Entwickler, der die Änderungen zurückgespielt hat, dies problemlos tun kann.
+Der zweite Entwickler muss die Arbeit des ersten Entwicklers zusammenführen, bevor Änderungen übernommen werden, 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 Modell funktioniert in Git perfekt.
 
-If you are already comfortable with a centralized workflow in your company or team, you can easily continue using that workflow with Git.
-Simply set up a single repository, and give everyone on your team push access; Git won't let users overwrite each other.
+Wenn Sie bereits mit einem zentralisierten Workflow in Ihrem Unternehmen oder Team vertraut sind, können Sie diesen Workflow problemlos mit Git weiterverwenden.
+Richten Sie einfach ein einziges Repository ein und gewähren Sie allen Mitgliedern Ihres Teams Push-Zugriff. Git lässt nicht zu, dass Benutzer sich gegenseitig überschreiben.
 
-Say John and Jessica both start working at the same time.
-John finishes his change and pushes it to the server.
-Then Jessica tries to push her changes, but the server rejects them.
-She is told that she's trying to push non-fast-forward changes and that she won't be able to do so until she fetches and merges.
-This workflow is attractive to a lot of people because it's a paradigm that many are familiar and comfortable with.
+Sagen wir, John und Jessica fangen beide zur gleichen Zeit an zu arbeiten. John beendet seine Änderung und schiebt sie zum Server. Dann versucht Jessica, ihre Änderungen zu pushen, 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 gefetched und gemerged hat.
+Dieser Workflow ist für viele Menschen sehr ansprechend, weil er ein Paradigma ist, mit dem viele bekannt und vertraut sind.
 
-This is also not limited to small teams.
-With Git's branching model, it's possible for hundreds of developers to successfully work on a single project through dozens of branches simultaneously.
+Dies ist auch nicht auf kleine Teams beschränkt.
+Mit dem Branching Model von Git ist es Hunderten von Entwicklern möglich, ein einzelnes Projekt über Dutzende von Branches gleichzeitig erfolgreich zu bearbeiten.
 
 [[_integration_manager]]
 ==== Integration-Manager Workflow
 
 (((workflows, integration manager)))
-Because Git allows you to have multiple remote repositories, it's possible to have a workflow where each developer has write access to their own public repository and read access to everyone else's.
-This scenario often includes a canonical repository that represents the ``official'' project.
-To contribute to that project, you create your own public clone of the project and push your changes to it.
-Then, you can send a request to the maintainer of the main project to pull in your changes.
-The maintainer can then add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository.
-The process works as follows (see <<wfdiag_b>>):
-
-1.  The project maintainer pushes to their public repository.
-2.  A contributor clones that repository and makes changes.
-3.  The contributor pushes to their own public copy.
-4.  The contributor sends the maintainer an email asking them to pull changes.
-5.  The maintainer adds the contributor's repository as a remote and merges locally.
-6.  The maintainer pushes merged changes to the main repository.
+
+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 kanonisches Repository, das das "offizielle" Projekt darstellt.
+Um zu diesem Projekt beizutragen, erstellen Sie Ihren eigenen öffentlichen Klon des Projekts und pushen Ihre Änderungen darauf.
+Anschließend können Sie eine Anforderung an den Betreuer des Hauptprojekts senden, um Ihre Änderungen zu übernehmen (pull).
+Der Betreuer kann dann Ihr Repository als Remote hinzufügen, Ihre Änderungen lokal testen, sie in ihrem Branch mergen und in ihr Repository zurück pushen.
+Der Prozess funktioniert wie folgt (siehe <<wfdiag_b>>):
+
+1. Die Projekt Betreuer pushen zu ihrem öffentlichen Repository.
+2. Ein Mitwirkender klont dieses Repository und nimmt Änderungen vor.
+3. Der Mitwirkende pusht auf seine eigene öffentliche Kopie.
+4. Der Mitwirkende sendet dem Betreuer eine E-Mail mit der Aufforderung, Änderungen zu übernehmen (Pull Request).
+5. Der Betreuer fügt das Repository des Mitwirkenden als Remote hinzu und merged es lokal zusammen.
+6. Der Betreuer pusht die zusammengeführten Änderungen an das Hauptrepository.
 
 [[wfdiag_b]]
 .Integration-manager workflow.
-image::images/integration-manager.png[Integration-manager workflow.]
+image::images/integration-manager.png[Integration-Manager Workflow.]
 
 (((forking)))
-This is a very common workflow with hub-based tools like GitHub or GitLab, where it's easy to fork a project and push your changes into your fork for everyone to see.
-One of the main advantages of this approach is that you can continue to work, and the maintainer of the main repository can pull in your changes at any time.
-Contributors don't have to wait for the project to incorporate their changes -- each party can work at their own pace.
+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 zu pushen, 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.
 
-==== Dictator and Lieutenants Workflow
+==== Diktator und Leutnants Workflow
 
 (((workflows, dictator and lieutenants)))
-This is a variant of a multiple-repository workflow.
-It's generally used by huge projects with hundreds of collaborators; one famous example is the Linux kernel.
-Various integration managers are in charge of certain parts of the repository; they're called _lieutenants_.
-All the lieutenants have one integration manager known as the benevolent dictator.
-The benevolent dictator pushes from his directory to a reference repository from which all the collaborators need to pull.
-The process works like this (see <<wfdiag_c>>):
-
-1.  Regular developers work on their topic branch and rebase their work on top of `master`.
-    The `master` branch is that of the reference repository to which the dictator pushes.
-2.  Lieutenants merge the developers' topic branches into their `master` branch.
-3.  The dictator merges the lieutenants' `master` branches into the dictator's `master` branch.
-4.  Finally, the dictator pushes that `master` branch to the reference repository so the other developers can rebase on it.
+Dies ist eine Variante eines Workflows mit mehreren Repositorys. Es 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, den wohlwollenden Diktator. Der wohlwollende Diktator pusht von seinem Verzeichnis in ein Referenz-Repository, aus dem alle Mitarbeiter pullen müssen. Der Prozess funktioniert wie folgt (siehe <<wfdiag_c>>):
+
+1. Entwickler arbeiten regelmäßig an ihrem Topic Branch und rebasen ihre Arbeit auf `master`. Der `Master`-Branch ist der des Referenz-Repositorys, in das der Diktator pusht.
+2. Die Leutnants fassen die Topic Branches der Entwickler zu ihrem `Master`-Branch zusammen.
+3. Der Diktator merged die `Master`-Branch 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 rebasen können.
 
 [[wfdiag_c]]
 .Benevolent dictator workflow.
-image::images/benevolent-dictator.png[Benevolent dictator workflow.]
+image::images/benevolent-dictator.png[Wohlwollender Diktator Workflow.]
 
-This kind of workflow isn't common, but can be useful in very big projects, or in highly hierarchical environments.
-It allows the project leader (the dictator) to delegate much of the work and collect large subsets of code at multiple points before integrating them.
+Diese Art von Workflow ist nicht üblich, kann jedoch in sehr großen Projekten oder in sehr hierarchischen Umgebungen hilfreich sein.
+Es ermöglicht dem Projektleiter (dem Diktator), einen Großteil der Arbeit zu delegieren und große Teilmengen von Code an mehreren Stellen zu sammeln, bevor sie integriert werden.
 
-==== Workflows Summary
+==== Zusammenfassung der Workflows
 
-These are some commonly used workflows that are possible with a distributed system like Git, but you can see that many variations are possible to suit your particular real-world workflow.
-Now that you can (hopefully) determine which workflow combination may work for you, we'll cover some more specific examples of how to accomplish the main roles that make up the different flows.
-In the next section, you'll learn about a few common patterns for contributing to a project.
+Dies sind einige häufig verwendete Workflows, die mit einem verteilten System wie Git möglich sind. Allerdings sind auch viele Variationen möglich sind, um Ihren eigenen Arbeitsabläufen gerecht zu werden. Nachdem Sie (hoffentlich) bestimmen können, welche Workflow-Kombination für Sie geeignet ist, werden wir einige spezifischere Beispiele für die Ausführung der Hauptfunktionen behandeln, aus denen die verschiedenen Abläufe bestehen. Im nächsten Abschnitt erfahren Sie mehr über einige gängige Muster, um zu einem Projekt etwas beizutragen.