From e5dab51a8dae59319b58e51534d0ce24e8b09ed1 Mon Sep 17 00:00:00 2001 From: pastatopf Date: Mon, 9 Sep 2019 20:02:51 +0200 Subject: [PATCH 01/14] Final review of file ch05-distributed-git.asc for german translation --- ch05-distributed-git.asc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ch05-distributed-git.asc b/ch05-distributed-git.asc index 0a6100e3..007497d8 100644 --- a/ch05-distributed-git.asc +++ b/ch05-distributed-git.asc @@ -2,9 +2,9 @@ == Verteiltes Git (((distributed git))) -Nachdem Sie ein Git Remote-Repository eingerichtet haben, in dem alle Entwickler ihren Code teilen können, und Sie mit den grundlegenden Git-Befehlen in einem lokalen Workflow vertraut sind, werden Sie einige der verteilten Workflows verwenden, die Git Ihnen bereitstellt. +Nachdem Sie ein entferntes Git Repository eingerichtet haben, in dem alle Entwickler ihren Code teilen können, und Sie mit den grundlegenden Git-Befehlen in einem lokalen Arbeitsablauf vertraut sind, werden Sie einige der verteilten Arbeitsabläufe verwenden, die Git Ihnen ermöglicht. -In diesem Kapitel erfahren Sie, wie Sie mit Git in einer verteilten Umgebung als Mitwirkender und Integrator arbeiten. Das heißt, Sie lernen, wie Sie Code erfolgreich in ein Projekt einbringen und es Ihnen und dem Projektbetreuer so einfach wie möglich machen. Außerdem lernen Sie, wie Sie ein Projekt erfolgreich verwalten, in dem mehrere Entwicklern Inhalte beisteuern. +In diesem Kapitel erfahren Sie, wie Sie mit Git in einer verteilten Umgebung als Mitwirkender und Integrator arbeiten. Das heißt, Sie lernen, wie Sie Quelltext erfolgreich zu einem Projekt beisteuern und es Ihnen und dem Projektbetreuer so einfach wie möglich machen. Außerdem lernen Sie, wie Sie ein Projekt erfolgreich verwalten, in dem mehrere Entwicklern Inhalte beisteuern. include::book/05-distributed-git/sections/distributed-workflows.asc[] @@ -14,5 +14,5 @@ include::book/05-distributed-git/sections/maintaining.asc[] === Zusammenfassung -Sie sollten sich nun ziemlich wohl dabei fühlen, in einem Git Projekt mitzuwirken, Ihr eigenes Projekt zu pflegen oder die Beiträge anderer Benutzer zu integrieren. +Sie sollten sich nun vertraut damit sein, in einem Git Projekt mitzuwirken, Ihr eigenes Projekt zu pflegen oder die Beiträge anderer Entwickler zu integrieren. Herzlichen Glückwunsch, sie sind nun ein erfolgreichen Git-Entwickler! Im nächsten Kapitel erfahren Sie, wie Sie den größten und beliebtesten Git-Hosting-Dienst, GitHub, verwenden. From 84d9b5661de3d79d7effaae621d59a2f0f62cdf0 Mon Sep 17 00:00:00 2001 From: pastatopf Date: Mon, 9 Sep 2019 21:39:47 +0200 Subject: [PATCH 02/14] Translated book/05-distributed-git/sections/distributed-workflows.asc to german --- .../sections/distributed-workflows.asc | 92 ++++++++++++------- 1 file changed, 60 insertions(+), 32 deletions(-) diff --git a/book/05-distributed-git/sections/distributed-workflows.asc b/book/05-distributed-git/sections/distributed-workflows.asc index 51e9ce4d..74133481 100644 --- a/book/05-distributed-git/sections/distributed-workflows.asc +++ b/book/05-distributed-git/sections/distributed-workflows.asc @@ -1,63 +1,91 @@ -=== Verteilte Workflows +=== 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. 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, welche die Vorteile dieser Flexibilität nutzen. Wir werden die Stärken und möglichen Schwächen der einzelnen Designs untersuchen. Sie können ein einzelnes Design auswählen oder Eigenschaften aus diesen kombinieren. +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. +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 Workflow +==== Zentralisierter Arbeitsablauf (((workflows, centralized))) -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 - Nutzer dieses Hubs - und synchronisieren ihre Arbeit mit diesem zentralisierten Standort. +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 Workflow. -image::images/centralized_workflow.png[Zentralisierter Workflow.] +.Zentralisierter Arbeitsablauf. +image::images/centralized_workflow.png[Zentralisierter Arbeitsablauf.] -Dies bedeutet, 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 (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 Modell funktioniert in Git wunderbar. +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 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 Schreib-Zugriff (push). Git lässt nicht zu, dass Benutzer sich gegenseitig überschreiben. +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 an zu arbeiten. John beendet seine Änderung und pusht 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 bestehende Änderungen abgeholt (gefetched) und mit ihrer lokalen Kopie vereint (gemergt) hat. Dieser Workflow ist für viele Menschen sehr ansprechend, weil er ein Paradigma ist, mit dem viele bereits bekannt und vertraut sind. +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. Mit dem Branching Model von Git ist es Hunderten von Entwicklern möglich, ein einzelnes Projekt über Dutzende von Branches gleichzeitig erfolgreich zu bearbeiten. +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]] -==== Integration-Manager Workflow +==== 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 anerkanntes 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 Request). 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. +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 <>): -1. Die Projekt Betreuer pushen zu ihrem eigenen, öffentlichen Repository. +1. Die Projekt Betreuer laden Arbeit ihr eigenes, öffentlichen Repository hoch. 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. +3. Der Mitwirkende lädt diese in sein eigenes öffentliches Repository hoch. +4. Der Mitwirkende sendet dem Betreuer eine E-Mail mit der Aufforderung, die Änderungen zu übernehmen (Pull Request). +5. Der Betreuer fügt das Repository des Mitwirkenden als Remote hinzu und führt die Änderungen lokal zusammen. +6. Der Betreuer lädt die zusammengeführten Änderungen in das Haupt-Repository hoch. [[wfdiag_b]] -.Integration-Manager Workflow. -image::images/integration-manager.png[Integration-Manager Workflow.] +.Arbeitsablauf mit Integrationsmanager. +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 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. +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. -==== Diktator und Leutnants Workflow +==== Arbeitsablauf mit Diktator und Leutnante (((workflows, dictator and lieutenants))) -Dies ist eine Variante eines Workflows mit mehreren Repositorys. Er 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, 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 <>): - -1. Entwickler arbeiten regelmäßig an ihrem Topic Branch und reorganisieren (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. +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. +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 <>): + +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. +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]] -.Wohlwollender Diktator Workflow. -image::images/benevolent-dictator.png[Wohlwollender Diktator Workflow.] +.Arbeitsablauf mit wohlwollendem Diktator. +image::images/benevolent-dictator.png[Arbeitsablauf mit wohlwollendem Diktator.] -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. +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. 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. \ No newline at end of file +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. From e7ad1b0db7a6f4467769ae2d480686982b53a56a Mon Sep 17 00:00:00 2001 From: pastatopf Date: Tue, 10 Sep 2019 21:05:18 +0200 Subject: [PATCH 03/14] Translated book/05-distributed-git/sections/contributing.asc to german --- TRANSLATION_NOTES_DE.asc | 87 +++-- .../sections/contributing.asc | 308 ++++++++++++------ status.json | 6 +- 3 files changed, 262 insertions(+), 139 deletions(-) diff --git a/TRANSLATION_NOTES_DE.asc b/TRANSLATION_NOTES_DE.asc index 99f8bb33..b58eae3a 100644 --- a/TRANSLATION_NOTES_DE.asc +++ b/TRANSLATION_NOTES_DE.asc @@ -60,28 +60,27 @@ Bitte erfinden Sie keine neue deutsche Übersetzung, sondern orientieren Sie sic |============================================================================== |Englisch|Deutsch |Branch| -Branch; Singular: der Branch; Plural: die Branches; Alternativ kann auch die deutsche Übersetzung „Zweig“ verwendet werden +Branch; Singular: der Branch; Plural: die Branches; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung „Zweig“ verwendet werden. |Branchname| Branchname; Singular: der Branchname; Plural: die Branchnamen -|To clone| -Klonen; Ein Repository klonen +|to clone| +klonen; er/sie klont; wir klonen |Clone| -Klon; Singular: der Klon; Plural: – +Klon; Singular: der Klon; Plural: die Klone |Commit| Commit; Singular: der Commit; Plural: die Commits -|To commit| -Committen; er/sie committet; wir committen; Alternativ: Einchecken +|to commit| +committen; er/sie committet; wir committen; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung „einchecken“ verwendet werden. |Commit date| -Commit-Datum; Singular: das Commit-Datum; Plural: die Commit-Daten; Alternativ: -Datum eines Commits +Commit-Datum; Singular: das Commit-Datum; Plural: die Commit-Daten; Alternativ: Datum eines Commits |Commit id| -Commit-ID; Singular: die Commit-ID; Plural: die Commit-IDs; Alternativ: -Commit-Referenz +Commit-ID; Singular: die Commit-ID; Plural: die Commit-IDs |Commit message| -Commit-Beschreibung; Singular: die Commit-Beschreibung; Plural: die Commit-Beschreibungen; -Alternativ: die Commit-Nachricht +Commit-Beschreibung; Singular: die Commit-Beschreibung; Plural: die Commit-Beschreibungen; Alternativ: die Commit-Nachricht +|Contributor| +Mitwirkender |Diff| -Diff; Singular: der Diff; Plural: die Diffs; Alternativ: der Vergleich, Ausgabe eines Vergleichs +Diff; Singular: der Diff; Plural: die Diffs; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung 'Vergleich oder Ausgabe eines Vergleichs' verwendet werden. |============================================================================== === E – J @@ -90,9 +89,21 @@ Diff; Singular: der Diff; Plural: die Diffs; Alternativ: der Vergleich, Ausgabe |============================================================================== |Englisch|Deutsch |HEAD| -HEAD; Singular: der HEAD; Plural: –; Oft kann HEAD ohne Artikel verwendet werden +HEAD; Singular: der HEAD; Plural: die HEADs; Oft kann HEAD ohne Artikel verwendet werden +|Feature| +Singular: das Thema; Plural: die Eigenschaften +|to fetch| +fetchen; er/sie fetcht; wir fetchen; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung 'abholen' verwendet werden +|to fork| +forken; er/sie forkt; wir forken; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung 'abspalten' verwendet werden +|Fork| +Fork; Singular: der Fork; Plural: die Fork; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung 'Abspaltung' verwendet werden je nach Kontext +|Issue| +Problem |Index| -Staging-Area; Singular: die Staging-Area; Alternativ: der Index +Staging-Area; Singular: die Staging-Area; Plural: die Staging-Areas; Alternativ: der Index +|Integrator| +Integrator |============================================================================== === K – Q @@ -100,10 +111,20 @@ Staging-Area; Singular: die Staging-Area; Alternativ: der Index [width="100%", frame="topbot", options="header,footer"] |============================================================================== |Englisch|Deutsch +|Lieutenant| +der Leutnant; Plural: die Leutnante +|Maintainer| +Projektbetreuer +|to maintain| +betreuen |to merge| -mergen, auch zusammenführen oder verschmelzen -|Merging| -Merging +mergen; er/sie mergt; wir mergen; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung "zusammenführen oder verschmelzen" verwendet werden. +|to pull| +pullen; er/sie pullt; wir pullen; Deutsch: übernehmen +|Pull Request| +Pull Request; Singular: der Pull Request; Plural: die Pull Requests +|to push| +pushen; er/sie pusht; wir pushen; Deutsch: hochladen |============================================================================== @@ -112,8 +133,8 @@ Merging [width="100%", frame="topbot", options="header,footer"] |============================================================================== |Englisch|Deutsch -|remote| -entfernt, auch extern (je nach Kontext) oder Remote-... +|to rebase| +rebasen; er/sie rebaset, wir rebasen; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung "reorganisieren oder restrukturieren" verwendet werden. |Repository| Repository; Singular: das Repository; Plural: die Repositorys; **Nicht** Repositor**ie**s, siehe hierzu auch link:http://www.duden.de/sprachwissen/sprachratgeber/crashkurs--in-25-schritten-zur-neuen-rechtschreibung[folgender Link] @@ -121,20 +142,24 @@ siehe hierzu auch link:http://www.duden.de/sprachwissen/sprachratgeber/crashkurs Remote-Repository; Singular: das Remote-Repository; Plural: die Remote-Repositorys |SHA1 hash| SHA1 Hash; Singular: der SHA1 Hash; Plural: die SHA1 Hashes +|to share| +teilen |Snapshot| -Snapshot; Singular: der Snapshot; Plural: die Snapshots; Alternativ kann auch Schnappschuss verwendet werden, häufiger verwendet man allerdings den englischen Begriff +Snapshot; Singular: der Snapshot; Plural: die Snapshots; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung "Schnappschuss" verwendet werden. +|to squah| +squashen; er/sie squasht, wir squashen; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung „komprimieren“ verwendet werden. |to stage| -zum Commit vormerken; zur Staging-Area hinzufügen -|staged| -zum Commit vorgemerkt; zur Staging-Area hinzugefügt +stagen; er/sie stagt; wir stagen; Deutsch zum Commit vormerken; zur Staging-Area hinzufügen |Staging area| Staging-Area; Alternativ: Index |stash| Stash; Singular: der Stash; Plural: die Stashes |to stash| -zum Stash hinzufügen, auch bunkern (ev. mit Hinweis: engl. stashed, je nach Kontext) +stashen; er/sie stasht; wir stashen; Deutsch: zum Stash hinzufügen, auch bunkern (ev. mit Hinweis: engl. stashed, je nach Kontext) +|Topic| +Thema; Singular: das Thema; Plural: die Themen |to track| -versionieren; Zur Versionsverwaltung hinzufügen, auch verfolgen (ev. mit Hinweis: engl. tracked, je nach Kontext) +track; er/sie trackt; wir tracken; Deutsch: versionieren; Zur Versionsverwaltung hinzufügen, auch verfolgen (ev. mit Hinweis: engl. tracked, je nach Kontext) |============================================================================== === U – Z @@ -142,10 +167,12 @@ versionieren; Zur Versionsverwaltung hinzufügen, auch verfolgen (ev. mit Hinwei [width="100%", frame="topbot", options="header,footer"] |============================================================================== |Englisch|Deutsch -|To unstage| -Aus der Staging-Area entfernen -|Version control| -Versionsverwaltung; Singular: die Versionsverwaltung; Prinzipiell ist auch Versionskontrolle möglich, allerdings wird heutzutage meist der Begriff Versionsverwaltung verwendet +|to unstage| +unstagen; er/sie unstagt; wir unstagen; Deutsch: Aus der Staging-Area entfernen +|Version control (system)| +Versionsverwaltung System; Singular: die Versionsverwaltung (bzw. das Versionsverwaltungs System; Prinzipiell ist auch Versionskontrolle möglich, allerdings wird heutzutage meist der Begriff Versionsverwaltung verwendet +|Workflow| +Arbeitsablauf |working tree| Verzeichnisbaum |============================================================================== diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 58035b67..918fc87c 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -1,41 +1,65 @@ [[_contributing_project]] -=== In einem Projekt mitwirken +=== An einem Projekt mitwirken (((contributing))) -Die Hauptschwierigkeit bei der Beschreibung, wie man an einem Projekt mitwirkt, sind die zahlreichen Varianten, wie man das machen könnte. Da Git sehr flexibel ist, können die Personen auf viele Arten zusammenarbeiten. Es ist nicht einfach zu beschreiben, wie Sie dazu beitragen sollen, da jedes Projekt ein wenig anders ist. Einige der wichtigen Unbekannten sind die Anzahl der aktiven Mitwirkenden, der ausgewählte Workflow, Ihre Zugriffsberechtigung und möglicherweise auch die Methode, wie externe Beiträge verwaltet werden sollen. - -Die erste Unbekannte ist die Anzahl der aktiven Mitwirkenden - wie viele Benutzer tragen aktiv Code zu diesem Projekt bei und wie oft? In vielen Fällen haben Sie zwei oder drei Entwickler mit ein paar Commits pro Tag oder möglicherweise weniger für etwas untätigere Projekte. Bei größeren Unternehmen oder Projekten kann die Anzahl der Entwickler in die Tausende gehen, wobei jeden Tag Hunderte oder Tausende von Commits getätigt werden können. Dies ist wichtig, da mit der Anzahl der Entwickler auch die Anzahl der zu lösenden Problemen steigt um ihren Code weiterhin ordnungsgemäß auszuführen oder um ihn einfach nur zusammenzuführen. Von Ihnen übermittelte Änderungen können durch Arbeiten, die während Ihrer Arbeit oder während Ihrer Änderungen genehmigt oder eingearbeitet wurden, veraltet sein oder schwer beschädigt werden. Wie können Sie Ihren Code konsistent auf dem neuesten Stand und Ihre Commits gültig halten? - -Die nächste Unbekannte ist der für das Projekt verwendete Workflow. Ist er zentralisiert, wobei jeder Entwickler den gleichen Schreibzugriff auf die Haupt Codelinie hat? Verfügt das Projekt über einen Betreuer oder Integrationsmanager, der alle Patches überprüft? Sind alle Patches von Fachleuten geprüft und genehmigt? Sind Sie in diesen Prozess involviert? Ist ein Leutnant System vorhanden und müssen Sie Ihre Arbeit zuerst bei Ihnen einreichen? - -Die nächste Unbekannte ist Ihr Zugriffsberechtigung. Der Workflow, der erforderlich ist, um zu einem Projekt beizutragen, unterscheidet sich erheblich, wenn Sie Schreibzugriff auf das Projekt haben, von dem, wenn Sie diesen nicht haben. Wenn Sie keinen Schreibzugriff haben, wie bevorzugt das Projekt die Annahme von beigetragener Arbeit? Gibt es überhaupt eine Strategie? Wie viel Arbeit steuern Sie auf einen Schlag bei? Wie oft tragen Sie etwas bei? - -All diese Fragen können sich darauf auswirken, wie Sie effektiv zu einem Projekt beitragen und welche Workflows bevorzugt oder überhaupt für sie verfügbar sind. Wir werden jeden dieser Aspekte in einer Reihe von Anwendungsfällen behandeln und von einfach zu komplex wechseln. Sie sollten in der Lage sein, anhand dieser Beispiele die spezifischen Workflows zu konstruieren, die Sie in der Praxis benötigen. +Die größte Schwierigkeit bei der Beschreibung, wie man an einem Projekt mitwirkt, sind die zahlreichen Varianten, wie man das geschehen könnte. +Da Git sehr flexibel ist, können die Personen auf viele Arten zusammenarbeiten. Es ist nicht einfach zu beschreiben, wie Sie dazu beitragen sollen, da jedes Projekt ein wenig anders ist. +Einige der wichtigen Unbekannten sind die Anzahl der aktiven Mitwirkenden, der ausgewählte Arbeitsablauf, Ihre Zugriffsberechtigung und möglicherweise auch die Methode, wie externe Beiträge verwaltet werden sollen. + +Die erste Unbekannte ist die Anzahl der aktiven Mitwirkenden - wie viele Benutzer tragen aktiv Quelltext zu diesem Projekt bei und wie oft? +In vielen Fällen haben Sie zwei oder drei Entwickler mit ein paar Commits pro Tag oder möglicherweise weniger für etwas untätigere Projekte. +Bei größeren Unternehmen oder Projekten kann die Anzahl der Entwickler in die Tausende gehen, wobei jeden Tag Hunderte oder Tausende von Commits getätigt werden können. +Das ist deshalb von Bedeutung, da Sie mit einer wachsenden Anzahl von Entwicklern auch sicherstellen müssen, dass sich der Code problemlos anwenden lässt und leicht zusammengeführt werden kann. +Von Ihnen übermittelte Änderungen können durch Arbeiten, die während Ihrer Arbeit oder während Ihrer Änderungen genehmigt oder eingearbeitet wurden, veraltet sein oder schwer beschädigt werden. +Wie können Sie Ihren Quelltext konsistent auf dem neuesten Stand halten und dafür sorgen, dass Ihre Commits gültig sind? + +Die nächste Unbekannte ist der für das Projekt verwendete Arbeitsablauf. +Ist er zentralisiert, wobei jeder Entwickler den gleichen Schreibzugriff auf die Hauptentwicklungslinie hat? +Verfügt das Projekt über einen Betreuer oder Integrationsmanager, der alle Patches überprüft? +Sind alle Patches von Fachleuten geprüft und genehmigt? +Sind Sie selbst in diesen Prozess involviert? +Ist ein Leutnant System vorhanden und müssen Sie Ihre Arbeit zuerst bei diesen einreichen? + +Die nächste Unbekannte ist Ihre Zugriffsberechtigung. +Der erforderliche Arbeitsablauf, um zu einem Projekt beizutragen, unterscheidet sich erheblich, wenn Sie Schreibzugriff auf das Projekt haben, als wenn Sie diesen nicht haben. +Wenn Sie keinen Schreibzugriff haben, wie bevorzugt das Projekt die Annahme von beigetragener Arbeit? +Gibt es überhaupt eine Richtlinie? +Wie umfangreich sind die Änderungen, die Sie jeweils beisteuern? +Wie oft tragen Sie etwas bei? + +All diese Fragen können sich darauf auswirken, wie Sie effektiv zu einem Projekt beitragen und welche Arbeitsabläufe bevorzugt oder überhaupt für sie verfügbar sind. +Wir werden jeden dieser Aspekte in einer Reihe von Anwendungsfällen behandeln, wobei wir mit simplen Beispielen anfangen und später komplexere Szenarios besprechen. Sie sollten in der Lage sein, anhand dieser Beispiele die spezifischen Arbeitsabläufe zu erstellen, die Sie in der Praxis benötigen. [[_commit_guidelines]] -==== Richtlinien zur Zusammenführung (Commit) +==== Richtlinien zur Zusammenführung (engl. Commits) -Bevor wir uns mit den spezifischen Anwendungsfällen befassen, finden Sie hier einen kurzen Hinweis zu Commit-Nachrichten. Ein guter Leitfaden zum Erstellen von Commits und das Befolgen desselbigen, erleichtert die Arbeit mit Git und die Zusammenarbeit mit anderen erheblich. Das Git-Projekt selber enthält ein Dokument, in dem einige nützliche Tipps zum Erstellen von Commits für die Übermittlung von Patches aufgeführt sind. Sie finden diese Tipps im Git-Quellcode in der Datei `Documentation/SubmittingPatches`. +Bevor wir uns mit den spezifischen Anwendungsfällen befassen, finden Sie hier einen kurzen Hinweis zu Commit-Nachrichten. +Ein guter Leitfaden zum Erstellen von Commits und das Befolgen desselbigen, erleichtert die Arbeit mit Git und die Zusammenarbeit mit anderen erheblich. +Das Git-Projekt selber enthält ein Dokument, in dem einige nützliche Tipps zum Erstellen von Commits für die Übermittlung von Patches aufgeführt sind. Sie finden diese Tipps im Git-Quellcode in der Datei `Documentation/SubmittingPatches`. (((git commands, diff, check))) -Ihre Einsendungen sollten keine Leerzeichenfehler enthalten. Git bietet eine einfache Möglichkeit, dies zu überprüfen. Führen Sie vor dem Commit `git diff --check` aus, um mögliche Leerzeichenfehler zu identifizieren und diese für Sie aufzulisten. +Ihre Einsendungen sollten keine Leerzeichenfehler enthalten. +Git bietet eine einfache Möglichkeit, dies zu überprüfen. Führen Sie vor dem Commit `git diff --check` aus, um mögliche Leerzeichenfehler zu identifizieren und diese für Sie aufzulisten. .Ausgabe von `git diff --check`. image::images/git-diff-check.png[Ausgabe von `git diff --check`.] -Wenn Sie diesen Befehl vor dem committen ausführen, können Sie feststellen, ob Leerzeichen Probleme auftreten, die andere Entwickler stören könnten. +Wenn Sie diesen Befehl vor einem Commit ausführen, können Sie feststellen, ob Leerzeichen Probleme auftreten, die andere Entwickler stören könnten. Als Nächstes, versuchen Sie, aus jedem Commit einen logisch getrennten Satz von Änderungen zu machen. Wenn Sie können, versuchen Sie, Ihre Änderungen leicht verdaulich zu machen - arbeiten Sie nicht ein ganzes Wochenende an fünf verschiedenen Themen und übermitteln Sie dann all diese Änderungen in einem massiven Commit am Montag. Auch wenn Sie am Wochenende keine Commits durchführen, nutzen Sie am Montag die Staging Area, um Ihre Änderungen aufzuteilen in wenigstens einen Commit für jeden Teilaspekt mit jeweils einer sinnvollen Nachricht. -Wenn einige der Änderungen die selbe Datei modifizieren, benutzen Sie die Anweisung `git add --patch`, um Dateien partiell zur Staging Area hinzuzufügen (detailiert dargestellt im Abschnitt <>). +Wenn einige der Änderungen dieselbe Datei modifizieren, benutzen Sie die Anweisung `git add --patch`, um Dateien partiell zur Staging Area hinzuzufügen (detailliert dargestellt im Abschnitt <>). Der Schnappschuss vom Projekt an der Spitze des Branches ist der Selbe, ob Sie einen oder fünf Commits durchgeführt haben, solange nur all die Änderungen irgendwann hinzugefügt werden. Versuchen Sie also, die Dinge zu vereinfachen für Ihre Entwicklerkollegen, die Ihre Änderungen begutachten müssen. Dieser Ansatz macht es außerdem einfacher, einen Satz von Änderungen zu entfernen oder rückgängig zu machen, falls das später nötig wäre. <> beschreibt eine Reihe nützlicher Git-Tricks zum Umschreiben des Verlaufs oder um interaktiv Dateien zur Staging Area hinzuzufügen. Verwenden Sie diese Werkzeuge, um einen sauberen und leicht verständlichen Verlauf aufzubauen, bevor Sie Ihre Arbeit jemand anderem schicken. -Als letztes darf die Commit-Nachricht nicht vergessen werden. Macht man es sich zur Gewohnheit, qualitativ hochwertige Commit-Nachrichten zu erstellen, erleichtert dies die Verwendung und die Zusammenarbeit mit Git erheblich. In der Regel sollten Ihre Nachrichten mit einer einzelnen Zeile beginnen, die nicht länger als 50 Zeichen ist. Diese sollte ihre Änderungen kurz beschreiben. Darauf folgen eine leere Zeile und eine ausführliche Erläuterung. Für das Git-Projekt ist es erforderlich, dass die ausführliche Erläuterung Ihre Motivation für die Änderung enthält. Außerdem sollte das Ergebnis ihre Implementierung mit dem vorherigen Verhalten des Projekts verglichen wird. Dies ist eine gute Richtlinie, die befolgt werden sollte. -Schreiben Sie Ihre Commit-Nachricht im Imperativ: "Behebe das Problem" und nicht "Problem wurde behoben". +Als letztes darf die Commit-Nachricht nicht vergessen werden. +Macht man es sich zur Gewohnheit, qualitativ hochwertige Commit-Nachrichten zu erstellen, erleichtert dies die Verwendung und die Zusammenarbeit mit Git erheblich. +In der Regel sollten Ihre Nachrichten mit einer einzelnen Zeile beginnen, die nicht länger als 50 Zeichen ist. Diese sollte ihre Änderungen kurz und bündig beschreiben. Darauf folgen eine leere Zeile und eine ausführliche Erläuterung. +Für das Git-Projekt ist es erforderlich, dass die ausführliche Erläuterung Ihre Motivation für die Änderung enthält. Außerdem sollte das Ergebnis ihre Implementierung mit dem vorherigen Verhalten des Projekts gegenüber gestellt werden. Dies ist eine gute Richtlinie, an die man sich halten sollte. +Es empfiehlt sich außerdem, die Gegenwartsform des Imperativs in diesen Nachrichten zu benutzen. Mit anderen Worten, verwenden Sie Anweisungen. Anstatt „Ich habe Test hinzugefügt für“ oder „Tests hinzufügend für“ benutzen Sie „Füge Tests hinzu für“. Hier ist eine https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[E-Mail-Vorlage, die ursprünglich von Tim Pope geschrieben wurde]: [source,text] @@ -49,10 +73,6 @@ welche die Zusammenfassung vom Text trennt ist von entscheidender Bedeutung (es sei denn, Sie lassen den Textkörper ganz weg). Werkzeuge wie rebase können durcheinander kommen, wenn Sie diese Trennung nicht einhalten. -Schreiben Sie Ihre Commit-Nachricht im Imperativ: "Behebe das Problem" und -nicht "Problem wurde behoben". Diese Konvention stimmt mit den durch -`git merge` und `git revert` generierten Commit-Nachrichten überein. - Weitere Absätze folgen nach Leerzeilen. - Aufzählungszeichen sind auch in Ordnung @@ -62,26 +82,34 @@ Weitere Absätze folgen nach Leerzeilen. Aufzählungen werden Leerzeilen eingefügt. Diese Konventionen variieren jedoch. -- Verwenden Sie einen hängenden Einzug + Verwenden Sie einen hängenden Einzug ---- -Wenn alle ihre Commit-Nachrichten diesem Modell folgen, wird es für Sie und die Entwickler, mit denen Sie zusammenarbeiten, viel einfacher. Das Git-Projekt selber enthält gut formatierte Commit-Meldungen. Versuchen Sie, `git log --no-merges` auszuführen, um zu sehen, wie ein gut formatierter Commit-Verlauf des Projekts aussieht. +Wenn alle ihre Commit-Nachrichten diesem Modell folgen, wird es für Sie und die Entwickler, mit denen Sie zusammenarbeiten, viel einfacher sein. +Das Git-Projekt selber enthält gut formatierte Commit-Nachrichten. Versuchen Sie, `git log --no-merges` auszuführen, um zu sehen, wie ein gut formatierter Commit-Verlauf des Projekts aussieht. [NOTE] .Tun sie das, was wir sagen und nicht das, was wir tun. ==== Der Kürze halber haben viele der Beispiele in diesem Buch keine gut formatierten Commit-Nachrichten. Stattdessen verwenden wir einfach die Option `-m`, um `git commit` auszuführen. -Kurz gesagt, tun Sie was wir sagen und nicht was wir tun. +Kurz gesagt, tun Sie es wie wir es sagen und nicht wie wir es tun. ==== [[_private_team]] -==== Kleine, private Teams +==== Kleines, privates Team (((contributing, private small team))) -Das einfachste Setup, auf das Sie wahrscheinlich stoßen werden, ist ein privates Projekt mit einem oder zwei anderen Entwicklern. Privat bedeutet in diesem Zusammenhang "closed source" - es ist für die Außenwelt nicht zugänglich. Sie und die anderen Entwickler haben alle Schreibzugriff (Push-Zugriff) auf das Repository. +Das einfachste Setup, auf das Sie wahrscheinlich stoßen werden, ist ein privates Projekt mit einem oder zwei anderen Entwicklern. +Privat bedeutet in diesem Zusammenhang "closed source" - es ist für die Außenwelt nicht öffentlich zugänglich. +Sie und die anderen Entwickler haben alle Schreibzugriff (Push-Zugriff) auf das Repository. -In dieser Umgebung können Sie einem Workflow folgen, der dem ähnelt, den Sie mit Subversion oder einem anderen zentralisierten System ausführen würden. Sie haben immer noch die Vorteile von Dingen wie Offline-Commit und ein wesentlich einfacheres Verzweigen (Branching) und Zusammenführen (Merging) Model, aber der Workflow kann sehr ähnlich sein. Der Hauptunterschied besteht darin, dass Merging zur Commit Zeit clientseitig stattfindet und nicht auf dem Server. Mal sehen, wie es aussehen könnte, wenn zwei Entwickler beginnen, mit einem gemeinsam genutzten Repository zusammenzuarbeiten. Der erste Entwickler, John, klont das Repository, nimmt eine Änderung vor und commitet es lokal. (Die Protokollnachrichten wurden in diesen Beispielen durch `...` ersetzt, um sie etwas zu verkürzen.) +In dieser Umgebung können Sie einem Arbeitsablauf folgen, der dem ähnelt, den Sie mit Subversion oder einem anderen zentralisierten System ausführen würden. +Sie haben immer noch die Vorteile von Dingen wie Offline-Commit und ein wesentlich einfacheres Verzweigungs- (engl.branching) und Zusammenführungsmodel (engl. merging), aber der Arbeitsablauf kann sehr ähnlich sein. +Hauptunterschied ist, dass das Zusammenführen eher auf der Client-Seite stattfindet als auf dem Server beim Durchführen eines Commits. +Mal sehen, wie es aussehen könnte, wenn zwei Entwickler beginnen, mit einem gemeinsam genutzten Repository zusammenzuarbeiten. +Der erste Entwickler, John, klont das Repository, nimmt eine Änderung vor und commitet es lokal. +(Die Protokollnachrichten wurden in diesen Beispielen durch `...` ersetzt, um sie etwas zu verkürzen.) [source,console] ---- @@ -96,7 +124,7 @@ $ git commit -am 'remove invalid default value' 1 files changed, 1 insertions(+), 1 deletions(-) ---- -Der zweite Entwickler, Jessica, macht dasselbe -- sie klont das Repository und commitet eine Änderung: +Die zweite Entwicklerin, Jessica, tut dasselbe -- sie klont das Repository, ändert etwas und führt einen Commit durch. [source,console] ---- @@ -111,7 +139,7 @@ $ git commit -am 'add reset task' 1 files changed, 1 insertions(+), 0 deletions(-) ---- -Nun pusht Jessica ihre Änderungen zum Server. Das funktioniert problemlos: +Nun lädt Jessica ihre Änderungen auf den Server hoch. Das funktioniert problemlos: [source,console] ---- @@ -122,9 +150,12 @@ To jessica@githost:simplegit.git 1edee6b..fbff5bc master -> master ---- -Die letzte Zeile der obigen Ausgabe zeigt eine nützliche Rückmeldung der Push Operation. Das Grundformat ist ` .. fromref -> toref`, wobei `oldref` die alte Referenz bedeutet, `newref` die neue Referenz bedeutet, `fromref` der Name der lokalen Referenz ist, die übertragen wird, und `toref` ist der Name der entfernten Referenz, die aktualisiert werden soll. Eine ähnliche Ausgabe finden Sie weiter unten in den Diskussionen. Wenn Sie also ein grundlegendes Verständnis der Bedeutung dieser Angaben haben, dann können Sie die verschiedenen Zustände der Repositorys besser verstehen. Weitere Informationen dazu finden Sie in der Dokumentation für https://git-scm.com/docs/git-push[git-push]. +Die letzte Zeile der obigen Ausgabe zeigt eine nützliche Rückmeldung der Push Operation. +Das Grundformat ist ` .. fromref -> toref`, wobei `oldref` die alte Referenz bedeutet, `newref` die neue Referenz bedeutet, `fromref` der Name der lokalen Referenz ist, die übertragen wird, und `toref` ist der Name der entfernten Referenz, die aktualisiert werden soll. +Eine ähnliche Ausgabe finden Sie weiter unten in den Diskussionen. Wenn Sie also ein grundlegendes Verständnis der Bedeutung dieser Angaben haben, dann können Sie die verschiedenen Zustände der Repositorys besser verstehen. +Weitere Informationen dazu finden Sie in der Dokumentation für https://git-scm.com/docs/git-push[git-push]. -Wenn wir mit diesem Beispiel fortfahren, nimmt John einige Änderungen vor, schreibt sie in sein lokales Repository und versucht, sie auf denselben Server zu übertragen: +Wenn wir mit diesem Beispiel fortfahren, nimmt John einige Änderungen vor, schreibt sie in sein lokales Repository und versucht, sie auf den gleichen Server zu übertragen: [source,console] ---- @@ -135,9 +166,12 @@ To john@githost:simplegit.git error: failed to push some refs to 'john@githost:simplegit.git' ---- -In diesem Fall scheitert Johns Push an Jessicas früherem Push mit _ihren_ Änderungen. Dies ist wichtig zu verstehen, wenn Sie an Subversion gewöhnt sind. Wie Sie sicherlich bemerkt haben, haben die beiden Entwickler nicht dieselbe Datei bearbeitet. Obwohl Subversion eine solche Zusammenführung automatisch auf dem Server durchführt, wenn verschiedene Dateien bearbeitet werden, müssen Sie bei Git die Commits _zuerst_ lokal zusammenführen. Mit anderen Worten, John muss zuerst Jessicas Änderungen abrufen und in seinem lokalen Repository zusammenführen, bevor er wiederrum seine Push-Vorgänge ausführen kann. +John ist es nicht gestattet, seine Änderungen hochzuladen, weil Jessica vorher _ihre_ hochgeladen hat. +Dies ist wichtig zu verstehen, wenn Sie an Subversion gewöhnt sind. Wie Sie sicherlich bemerkt haben, haben die beiden Entwickler nicht dieselbe Datei bearbeitet. +Obwohl Subversion eine solche Zusammenführung automatisch auf dem Server durchführt, wenn verschiedene Dateien bearbeitet werden, müssen Sie bei Git die Commits _zuerst_ lokal zusammenführen. +Mit anderen Worten, John muss zuerst Jessicas Änderungen abrufen und in seinem lokalen Repository zusammenführen, bevor ihm das Hochladen gestattet wird. -Als ersten Schritt holt John, Jessicas Änderungen (dies holt nur Jessicas Änderungen, es mergt sie noch nicht mit Johns Änderungen): +Als ersten Schritt holt John, Jessicas Änderungen (dies holt nur Jessicas Änderungen, diese werden noch nicht mit Johns Änderungen zusammengeführt): [source,console] ---- @@ -149,10 +183,10 @@ From john@githost:simplegit Zu diesem Zeitpunkt sieht Johns lokales Repository ungefähr so aus: -.Johns abweichender Verlauf. -image::images/small-team-1.png[Johns abweichender Verlauf.] +.Johns abzweigender Verlauf. +image::images/small-team-1.png[Johns abzweigender Verlauf.] -Jetzt kann John, Jessicas abgeholte Änderungen, zu seiner eigenen lokalen Änderungen zusammenführen: +Jetzt kann John, Jessicas abgeholte Änderungen, zu seinen eigenen lokalen Änderungen zusammenführen: [source,console] ---- @@ -162,12 +196,12 @@ Merge made by the 'recursive' strategy. 1 files changed, 1 insertions(+), 0 deletions(-) ---- -Solange diese lokale Zusammenführung reibungslos verläuft, sieht der aktualisierte Verlauf von John nun folgendermaßen aus: +Wenn diese lokale Zusammenführung reibungslos verläuft, sieht der aktualisierte Verlauf von John nun folgendermaßen aus: .Johns Repository nach der Zusammenführung `origin/master`. image::images/small-team-2.png[Johns Repository nach der Zusammenführung `origin/master`.] -Zu diesem Zeitpunkt möchte John möglicherweise diesen neuen Code testen, um sicherzustellen, dass sich keine der Arbeiten von Jessica auf seine auswirkt. Solange alles in Ordnung scheint, kann er die neu zusammengeführten Änderungen schließlich auf den Server übertragen: +Zu diesem Zeitpunkt möchte John möglicherweise diesen neuen Code testen, um sicherzustellen, dass sich keine der Arbeiten von Jessica auf seine auswirkt. Wenn alles in Ordnung ist, kann er die neu zusammengeführten Änderungen schließlich auf den Server übertragen: [source,console] ---- @@ -179,15 +213,16 @@ To john@githost:simplegit.git Am Ende sieht Johns Commit-Verlauf so aus: -.Johns Verlauf nach pushen zum `origin` server. -image::images/small-team-3.png[Johns Verlauf nach pushen zum `origin` server.] +.Johns Verlauf nach Hochladen auf den `origin`-Server. +image::images/small-team-3.png[Johns Verlauf nach Hochladen auf den `origin`-Server.] -In der Zwischenzeit hat Jessica einen neuen Branch mit dem Namen `issue54` erstellt und drei Commits auf diesem Branch vorgenommen. Sie hat Johns Änderungen noch nicht abgerufen, daher sieht ihr Commit-Verlauf folgendermaßen aus: +In der Zwischenzeit hat Jessica einen neuen Branch mit dem Namen `issue54` erstellt und drei Commits auf diesem Branch vorgenommen. +Sie hat Johns Änderungen noch nicht abgerufen, daher sieht ihr Commit-Verlauf folgendermaßen aus: -.Jessicas topic branch. -image::images/small-team-4.png[Jessicas topic branch.] +.Jessicas Themen Branch. +image::images/small-team-4.png[Jessicas Themen Branch.] -Nun erfährt Jessica, dass John einige neue Arbeiten auf den Server gepusht hat und sie möchte sich diese ansehen. Sie kann alle neuen Inhalte von dem Server abrufen über die sie noch nicht verfügt: +Nun erfährt Jessica, dass John einige neue Arbeiten auf den Server geschoben hat und sie möchte sich diese ansehen. Sie kann alle neuen Inhalte von dem Server abrufen über die sie noch nicht verfügt: [source,console] ---- @@ -198,12 +233,14 @@ From jessica@githost:simplegit fbff5bc..72bbc59 master -> origin/master ---- -Dies zieht die Arbeit runter (Pull), die John in der Zwischenzeit gepusht hat. Jessicas Verlauf sieht jetzt so aus: +Dies zieht die Arbeit herunter (Pull), die John in der Zwischenzeit hochgeladen hat. +Jessicas Verlauf sieht jetzt so aus: -.Jessicas Verlauf nach dem ziehen von Johns Änderungen. -image::images/small-team-5.png[Jessicas Verlauf nach dem ziehen von Johns Änderungen.] +.Jessicas Verlauf nach dem Abholen von Johns Änderungen. +image::images/small-team-5.png[Jessicas Verlauf nach dem Abholen von Johns Änderungen.] -Jessica denkt, dass ihr Themen Branch nun fertig ist. Sie möchte jedoch wissen, welchen Teil von Johns abgerufenen Arbeiten sie in ihre Arbeit einbinden muss, damit sie pushen kann. Sie führt "git log" aus, um das herauszufinden: +Jessica denkt, dass ihr Themen Branch nun fertig ist. Sie möchte jedoch wissen, welchen Teil von Johns abgerufenen Arbeiten sie in ihre Arbeit einbinden muss, damit sie hochladen kann. +Sie führt `git log` aus, um das herauszufinden: [source,console] ---- @@ -215,13 +252,15 @@ Date: Fri May 29 16:01:27 2009 -0700 remove invalid default value ---- -Die Syntax `issue54..origin/master` ist ein Logfilter, der Git auffordert, nur die Commits anzuzeigen, die sich im letzterem Branch befinden (in diesem Fall `origin/master`) und nicht im ersten Branch (in diesem Fall `issue54`). Wir werden diese Syntax in <> genauer erläutern. +Die Syntax `issue54..origin/master` ist ein Logfilter, der Git anweist, nur die Commits anzuzeigen, die sich im letzterem Branch befinden (in diesem Fall `origin/master`) und nicht im ersten Branch (in diesem Fall `issue54`). +Wir werden diese Syntax in <> genauer erläutern. -Aus der obigen Ausgabe können wir sehen, dass es einen einzigen Commit gibt, den John gemacht hat, welchen Jessica nicht in ihre lokale Arbeit eingebunden hat. Wenn sie `origin/master` zusammenführt, ist dies der einzige Commit, der ihre lokale Arbeit verändert. +Aus der obigen Ausgabe können wir sehen, dass es einen einzigen Commit gibt, den John gemacht hat, welchen Jessica nicht in ihre lokale Arbeit eingebunden hat. +Wenn sie `origin/master` zusammenführt, ist dies der einzige Commit, der ihre lokale Arbeit verändert. -Jetzt kann Jessica ihre Arbeit in ihrem Master Branch zusammenführen, Johns Arbeit (`origin/master`) in ihrem `master`-Branch zusammenführen und dann wieder auf den Server pushen. +Jetzt kann Jessica ihre Arbeit in ihrem Master Branch zusammenführen, Johns Arbeit (`origin/master`) in ihrem `master`-Branch zusammenführen und dann wieder auf den Server hochladen. -Als erstes wechselt Jessica (nachdem sie alle Änderungen in ihrem Themen Branch `issue54` commitet hat) zurück zu ihrem Master Branch, um die Integration all dieser Arbeiten vorzubereiten: +Als erstes wechselt Jessica (nachdem sie alle Änderungen in ihrem Themen Branch `issue54` commitet hat) zurück zu ihrem `master`-Branch, um diese Integration vorzubereiten: [source,console] ---- @@ -230,7 +269,9 @@ Switched to branch 'master' Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. ---- -Jessica kann entweder `origin/master` oder `issue54` mit ihrem lokalem `master` zusammenführen - beide sind ihrem `master` vorgelagert. Daher spielt die Reihenfolge keine Rolle. Der finale Schnappschuss sollte unabhängig von der gewählten Reihenfolge identisch sein. Nur der Verlauf wird anders sein. Sie beschließt, zuerst den Branch `issue54` zusammenzuführen: +Jessica kann entweder `origin/master` oder `issue54` mit ihrem lokalem `master` zusammenführen - beide sind ihrem `master` vorgelagert. Daher spielt die Reihenfolge keine Rolle. +Der finale Schnappschuss sollte unabhängig von der gewählten Reihenfolge identisch sein. Nur der Verlauf wird anders sein. +Sie beschließt, zuerst den Branch `issue54` zusammenzuführen: [source,console] ---- @@ -242,7 +283,8 @@ Fast forward 2 files changed, 6 insertions(+), 1 deletions(-) ---- -Es treten keine Probleme auf. Wie Sie sehen, handelte es sich um eine einfache Schnellvorlauf (Fast-Forward) Zusammenführung. Jessica schließt nun den lokalen Zusammenführungsprozess ab, indem sie Johns zuvor abgerufene Arbeit zusammenführt, die sich im Zweig `origin/master` befindet: +Es treten keine Probleme auf. Wie Sie sehen, handelte es sich um einen einfachen Schnellvorlauf Zusammenführung (engl. Fast-Forward). +Jessica schließt nun den lokalen Zusammenführungsprozess ab, indem sie Johns zuvor abgerufene Arbeit zusammenführt, die sich im Branch `origin/master` befindet: [source,console] ---- @@ -258,7 +300,7 @@ Alles kann sauber zusammengeführt werden. Jessicas Verlauf sieht nun so aus: .Jessicas Verlauf nach Zusammenführung mit Johns Änderungen. image::images/small-team-6.png[Jessicas Verlauf nach Zusammenführung mit Johns Änderungen.] -Jetzt ist `origin/master` über Jessicas `master`-Branch erreichbar, sodass sie erfolgreich pushen kann (vorausgesetzt, John hat in der Zwischenzeit keine weiteren Änderungen gepusht): +Jetzt ist `origin/master` über Jessicas `master`-Branch erreichbar, sodass sie erfolgreich pushen kann (vorausgesetzt, John hat in der Zwischenzeit keine weiteren Änderungen hochgeladen): [source,console] ---- @@ -268,25 +310,33 @@ To jessica@githost:simplegit.git 72bbc59..8059c15 master -> master ---- -Jeder Entwickler hat ein paar Mal committet und die Arbeit des anderen erfolgreich zusammengeführt. +Jeder Entwickler hat einige Commits durchgeführt und die Arbeit des jeweils anderen erfolgreich zusammengeführt. -.Jessicas Verlauf nach pushen aller Änderungen auf den Server. -image::images/small-team-7.png[Jessicas Verlauf nach pushen aller Änderungen auf den Server.] +.Jessicas Verlauf nach hochladen aller Änderungen auf den Server. +image::images/small-team-7.png[Jessicas Verlauf nach hochladen aller Änderungen auf den Server.] -Das ist einer der einfachsten Workflows. Sie arbeiten eine Weile (in der Regel in einem Themen Branch) und führen diese Arbeiten in Ihrem Branch `master` zusammen, sobald sie für die Integration bereit sind. Wenn Sie diese Arbeit teilen möchten, rufen Sie Ihren `master` von `origin/master` ab und führen ihn zusammen, falls er sich geändert hat. Anschließend pushen sie ihn in den `master` Branch auf dem Server. Die allgemeine Reihenfolge sieht in etwa so aus: +Das ist einer der einfachsten Arbeitsabläufe. +Sie arbeiten eine Weile (in der Regel in einem Themen Branch) und führen diese Arbeiten in Ihrem Branch `master` zusammen, sobald sie für die Integration bereit sind. +Wenn Sie diese Arbeit teilen möchten, rufen Sie Ihren `master` von `origin/master` ab und führen ihn zusammen, falls er sich geändert hat. Anschließend pushen sie ihn in den `master` Branch auf dem Server. +Die allgemeine Reihenfolge sieht in etwa so aus: -. Allgemeine Abfolge von Ereignissen für einen einfachen Git-Workflow mit mehreren Entwicklern. -image::images/small-team-flow.png[Allgemeine Abfolge von Ereignissen für einen einfachen Git-Workflow mit mehreren Entwicklern.] +. Allgemeine Abfolge von Ereignissen für einen einfachen Arbeitsablauf mit mehreren Entwicklern. +image::images/small-team-flow.png[Allgemeine Abfolge von Ereignissen für einen einfachen Arbeitsablauf mit mehreren Entwicklern.] -==== Geführtes und geschlossenes Team +==== Geführtes, privates Team (((contributing, private managed team))) -In diesem Szenario sehen Sie sich die Rollen der Mitwirkenden in einer größeren, geschlossenen Gruppe an. Sie lernen, wie Sie in einer Umgebung arbeiten, in der kleine Gruppen an Features zusammenarbeiten. Anschließend werden diese teambasierten Beiträge von einer anderen Partei integriert. +In diesem Szenario sehen Sie sich die Rollen der Mitwirkenden in einem größeren, geschlossenen Team an. +Sie lernen, wie Sie in einer Umgebung arbeiten, in der kleine Gruppen an der Entwicklung einzelner Funktonen zusammenarbeiten. Anschließend werden diese teambasierten Beiträge von einem anderen Beteiligten integriert. -Nehmen wir an, John und Jessica arbeiten gemeinsam an einem Feature (nennen wir dieses `FeatureA`), während Jessica und Josie, ein dritter Entwickler, an einem zweiten Feature arbeiten (sagen wir `FeatureB`). In diesem Fall verwendet das Unternehmen eine Art Integration-Manager-Workflow. Bei diesem kann die Arbeit der einzelnen Gruppen nur von bestimmten Beteiligten integriert werden. Der Master-Branch des Haupt Repositorys kann nur von diesen Beteiligten aktualisiert werden kann. In diesem Szenario werden alle Arbeiten in teambasierten Branches ausgeführt und später von den Integratoren zusammengeführt. +Nehmen wir an, John und Jessica arbeiten gemeinsam an einem Feature (nennen wir dieses `FeatureA`), während Jessica und Josie, eine dritte Entwicklerin, an einem zweiten Feature arbeiten (sagen wir `FeatureB`). +In diesem Fall verwendet das Unternehmen einen Arbeitsablauf mit Integrationsmanager. Bei diesem kann die Arbeit der einzelnen Gruppen nur von bestimmten Beteiligten integriert werden. Der Master-Branch des Haupt Repositorys kann nur von diesen Beteiligten aktualisiert werden kann. +In diesem Szenario werden alle Arbeiten in teambasierten Branches ausgeführt und später vom Integrationsmanager zusammengeführt. -Folgen wir Jessicas Workflow, während sie an ihren beiden Features tätig ist und parallel mit zwei verschiedenen Entwicklern in dieser Umgebung arbeitet. Wir nehmen an, sie hat ihr Repository bereits geklont. Zuerst beschließt sie an `featureA` zu arbeiten. Sie erstellt einen neuen Branch für das Feature und führt dort einige Änderungen aus: +Folgen wir Jessicas Arbeitsablauf, während sie an ihren beiden Features tätig ist und parallel mit zwei verschiedenen Entwicklern in dieser Umgebung arbeitet. +Wir nehmen an, sie hat ihr Repository bereits geklont. Zuerst beschließt sie an `featureA` zu arbeiten. +Sie erstellt einen neuen Branch für das Feature und führt dort einige Änderungen aus: [source,console] ---- @@ -299,7 +349,8 @@ $ git commit -am 'add limit to log function' 1 files changed, 1 insertions(+), 1 deletions(-) ---- -Zu diesem Zeitpunkt muss sie ihre Arbeit mit John teilen, also pusht sie ihre `featureA` Branch Commits auf den Server. Jessica hat keinen Push-Zugriff auf den `master` Branch, nur die Integratoren haben das. Sie muss daher auf einen anderen Branch pushen, um mit John zusammenzuarbeiten: +Zu diesem Zeitpunkt muss sie ihre Arbeit mit John teilen, also lädt sie ihre `featureA` Branch Commits auf den Server hoch. +Jessica hat keinen Push-Zugriff auf den `master` Branch, nur die Integrationsmanager haben das. Sie muss daher auf einen anderen Branch hochladen, um mit John zusammenzuarbeiten: [source,console] ---- @@ -309,7 +360,9 @@ To jessica@githost:simplegit.git * [new branch] featureA -> featureA ---- -Jessica schickt John eine E-Mail, um ihm mitzuteilen, dass sie einige Arbeiten in einen Branch mit dem Namen `featureA` gepusht hat. Er kann sie sich jetzt ansehen. Während sie auf Rückmeldung von John wartet, beschließt Jessica, mit Josie an `featureB` zu arbeiten. Zunächst startet sie einen neuen Feature-Branch, der auf dem `master` Branch des Servers basiert: +Jessica schickt John eine E-Mail, um ihm mitzuteilen, dass sie einige Arbeiten in einen Branch mit dem Namen `featureA` hochgeladen hat. Er kann sie sich jetzt ansehen. +Während sie auf Rückmeldung von John wartet, beschließt Jessica, mit Josie an `featureB` zu arbeiten. +Zunächst startet sie einen neuen Feature-Branch, der auf dem `master` Branch des Servers basiert: [source,console] ---- @@ -338,7 +391,9 @@ Jessicas Repository sieht nun folgendermaßen aus: .Jessicas initialer Commit Verlauf. image::images/managed-team-1.png[Jessicas initialer Commit Verlauf.] -Sie ist bereit, ihre Arbeit zu pushen, erhält jedoch eine E-Mail von Josie, dass ein Branch mit einigen anfänglichen `featureB` Aufgaben bereits als `featureBee` Branch auf den Server übertragen wurde. Jessica muss diese Änderungen mit ihren eigenen zusammenführen, bevor sie ihre Arbeit auf den Server übertragen kann. Jessica holt sich zuerst Josies Änderungen mit `git fetch`: +Sie ist bereit, ihre Arbeit hochzuladen, erhält jedoch eine E-Mail von Josie, dass ein Branch mit einigen anfänglichen `featureB` Aufgaben bereits als `featureBee` Branch auf den Server übertragen wurde. +Jessica muss diese Änderungen mit ihren eigenen zusammenführen, bevor sie ihre Arbeit auf den Server übertragen kann. +Jessica holt sich zuerst Josies Änderungen mit `git fetch`: [source,console] ---- @@ -359,7 +414,8 @@ Merge made by the 'recursive' strategy. 1 files changed, 4 insertions(+), 0 deletions(-) ---- -Zu diesem Zeitpunkt möchte Jessica die gesamte zusammengeführte Arbeit an `featureB` zurück auf den Server übertragen. Jedoch möchte sie nicht einfach ihren eigenen Branch `featureB` übertragen. Da Josie bereits einen Upstream Branch `featureBee` gestartet hat, möchte Jessica auf diesen Zweig pushen, was sie auch folgendermaßen tut: +Nun möchte Jessica die gesamte zusammengeführte Arbeit an `featureB` zurück auf den Server übertragen. Jedoch möchte sie nicht einfach ihren eigenen Branch `featureB` übertragen. +Da Josie bereits einen Upstream Branch `featureBee` gestartet hat, möchte Jessica auf diesen Zweig hochladen, was sie auch folgendermaßen tut: [source,console] ---- @@ -369,9 +425,12 @@ To jessica@githost:simplegit.git fba9af8..cd685d1 featureB -> featureBee ---- -Dies wird als _refspec_ bezeichnet. Unter <> finden Sie eine detailliertere Beschreibung der Git-Refspecs und der verschiedenen Dinge, die Sie damit ausführen können. Beachten Sie auch die `-u` Option. Dies ist die Abkürzung für `--set-upstream`, mit der die Branches so konfiguriert werden, dass sie später leichter gepusht und gepullt werden können. +Dies wird als _refspec_ bezeichnet. +Unter <> finden Sie eine detailliertere Beschreibung der Git-Refspecs und der verschiedenen Möglichkeiten, die Sie damit haben. +Beachten Sie auch die `-u` Option. Dies ist die Abkürzung für `--set-upstream`, mit der die Branches so konfiguriert werden, dass sie später leichter gepusht und gepullt werden können. -Plötzlich erhält Jessica eine E-Mail von John, der ihr mitteilt, dass er einige Änderungen am Branch `featureA` vorgenommen hat, an dem sie zusammenarbeiten. Er bittet Jessica, sie sich anzusehen. Wieder führt Jessica ein einfaches `git fetch` durch, um _alle_ neue Inhalte vom Server abzurufen, einschließlich (natürlich) Johns neuester Arbeit: +Als nächstes erhält Jessica eine E-Mail von John, der ihr mitteilt, dass er einige Änderungen am Branch `featureA` vorgenommen hat, an dem sie zusammenarbeiten. Er bittet Jessica, sie sich anzusehen. +Wieder führt Jessica ein einfaches `git fetch` durch, um _alle_ neue Inhalte vom Server abzurufen, einschließlich (natürlich) Johns neuester Arbeit: [source,console] ---- @@ -393,7 +452,7 @@ Date: Fri May 29 19:57:33 2009 -0700 changed log output to 30 from 25 ---- -Wenn Jessica gefällt, was sie sieht, kann sie Johns neue Arbeit in ihrer lokalen `featureA` Branch zusammenführen: +Wenn ihr Johns neue Arbeit gefällt, kann sie sie mit ihrem lokalen Branch `featureA` zusammenführen: [source,console] ---- @@ -406,7 +465,7 @@ Fast forward 1 files changed, 9 insertions(+), 1 deletions(-) ---- -Schließlich möchte Jessica noch ein paar geringfügige Änderungen an dem gesamten, zusammengeführten Inhalt vornehmen. Sie kann diese Änderungen vornehmen, sie in ihren lokalen Branch `featureA` comitten und das Endergebnis zurück auf den Server pushen. +Schließlich möchte Jessica noch ein paar geringfügige Änderungen an dem gesamten, zusammengeführten Inhalt vornehmen. Sie kann diese Änderungen vornehmen, sie in ihren lokalen Branch `featureA` comitten und das Endergebnis zurück auf den Server übertragen. [source,console] ---- @@ -424,23 +483,31 @@ Jessicas commit Verlauf sieht nun in etwa so aus: .Jessicas Verlauf nach committen auf einem Feature Branch. image::images/managed-team-2.png[Jessicas Verlauf nach committen auf einem Feature Branch.] -Irgendwann informieren Jessica, Josie und John die Integratoren, dass die Branches `featureA` und `featureBee` auf dem Server für die Integration in die Hauptlinie bereit sind. Nachdem die Integratoren diese Branches in der Hauptlinie zusammengeführt haben, holt ein Abruf den neuen Zusammenführungs-Commit ab, sodass der Verlauf wie folgt aussieht: +Irgendwann informieren Jessica, Josie und John die Integratoren, dass die Branches `featureA` und `featureBee` auf dem Server für die Integration in die Hauptlinie bereit sind. +Nachdem die Integratoren diese Branches in der Hauptlinie zusammengeführt haben, holt ein Abruf den neuen Zusammenführungs-Commit ab, sodass der Verlauf wie folgt aussieht: .Jessicas Verlauf nach Zusammenführung ihrer beiden Themen Branches. image::images/managed-team-3.png[Jessicas Verlauf nach Zusammenführung ihrer beiden Themen Branches.] -Viele Gruppen wechseln zu Git, da mehrere Teams parallel arbeiten können und die verschiedenen Arbeitsbereiche zu einem späteren Zeitpunkt zusammengeführt werden können. Die Fähigkeit kleinerer Untergruppen eines Teams, über entfernte Niederlassungen zusammenzuarbeiten ohne das gesamte Team einbeziehen oder behindern zu müssen, ist ein großer Vorteil von Git. Die Vorgehensweise für den Workflow, den Sie hier gesehen haben, sieht in etwa so aus: +Viele Teams wechseln zu Git, da sie parallel arbeiten können und die verschiedenen Entwicklungslinien zu einem späteren Zeitpunkt zusammengeführt werden können. +Ein großer Vorteil von Git besteht darin, dass man in kleinen Untergruppen eines Teams über entfernte Branches zusammenarbeiten kann, ohne notwendigerweise das gesamte Team zu involvieren oder zu behindern. +Die Vorgehensweise dieses Arbeitsablaufes, sieht in etwa so aus: -.Grundlegende Vorgehensweise für den geführten Team Workflow. -image::images/managed-team-flow.png[Grundlegende Vorgehensweise für den geführten Team Workflow.] +.Grundlegende Vorgehensweise bei einem geführten Team. +image::images/managed-team-flow.png[Grundlegende Vorgehensweise bei einem geführten Team.] [[_public_project]] -==== Abgespaltene (Forked), öffentliche Projekte +==== Verteiltes, öffentliches Projekt (((contributing, public small project))) -An öffentlichen Projekten mitzuwirken ist ein wenig anders. Da Sie nicht die Berechtigung haben, Branches im Projekt direkt zu aktualisieren, müssen Sie ihre Arbeit auf andere Weise an die Betreuer weiterleiten. In diesem ersten Beispiel wird beschrieben, wie Sie auf Git Hosts, die einfaches forken unterstützen, via forking mitwirken können. Viele Hosting-Sites unterstützen dies (einschließlich GitHub, BitBucket, repo.or.cz und andere) und viele Projektbetreuer erwarten diesen Beitragsstil. Der nächste Abschnitt befasst sich mit Projekten, die bereitgestellte Patches bevorzugt per E-Mail akzeptieren. +An öffentlichen Projekten mitzuwirken ist ein wenig anders. +Da Sie nicht die Berechtigung haben, Branches im Projekt direkt zu aktualisieren, müssen Sie ihre Arbeit auf andere Weise an die Projektbetreuer weiterleiten. +In diesem ersten Beispiel wird beschrieben, wie Sie auf Git Hosts, die einfaches „Forking“ unterstützen, via „Forking“ mitwirken können. +Viele Hosting-Sites unterstützen dies (einschließlich GitHub, BitBucket, repo.or.cz und andere) und viele Projektbetreuer erwarten diese Art der Mitarbeit. +Der nächste Abschnitt befasst sich mit Projekten, die bereitgestellte Patches bevorzugt per E-Mail akzeptieren. -Zunächst möchten Sie wahrscheinlich das Haupt-Repository klonen, einen Branch für den Patch oder die Patch Serien erstellen, die Sie beitragen möchten, und dort Ihre Arbeit erledigen. Der Prozess sieht im Grunde so aus: +Zunächst möchten Sie wahrscheinlich das Hauptrepository klonen, einen Branch für den Patch oder die Patch Serien erstellen, die Sie beisteuern möchten, und dort Ihre Arbeit erledigen. +Der Prozess sieht im Grunde so aus: [source,console] ---- @@ -458,16 +525,20 @@ $ git commit Sie können `rebase -i` verwenden, um Ihre Arbeit auf ein einzelnes Commit zu reduzieren. Sie können auch die Änderungen in den Commits neu anordnen, damit der Betreuer den Patch einfacher überprüfen kann - siehe <> für weitere Informationen zum interaktiven Rebasing. ==== -Wenn Ihre Arbeit am Branch abgeschlossen ist und Sie bereit sind, sie an die Betreuer weiterzuleiten, wechseln Sie zur ursprünglichen Projektseite. Dort klicken Sie auf die Schaltfläche `Fork`, um Ihren eigenen schreibbaren Fork des Projekts zu erstellen. Anschließend müssen Sie diese Repository-URL als neue Remote-Adresse Ihres lokalen Repositorys hinzufügen. Nennen wir es in diesem Beispiel `myfork`: +Wenn Ihre Arbeit am Branch abgeschlossen ist und Sie bereit sind, sie an die Betreuer weiterzuleiten, wechseln Sie zur ursprünglichen Projektseite. Dort klicken Sie auf die Schaltfläche `Fork`, um Ihren eigenen schreibbaren Fork des Projekts zu erstellen. +Anschließend müssen Sie diese Repository-URL als neue Remote-Adresse Ihres lokalen Repositorys hinzufügen. Nennen wir es in diesem Beispiel `myfork`: [source,console] ---- $ git remote add myfork ---- -Anschließend müssen Sie Ihre neue Arbeit in dieses Repository pushen. Es ist am einfachsten, den Branch, an dem Sie arbeiten, in Ihr geforktes Repository zu pushen, anstatt diese Arbeit in Ihrem Master-Branch zusammenzuführen und diesen zu pushen. Der Grund dafür ist, dass Sie Ihren Master-Branch nicht zurückspulen müssen, wenn Ihre Arbeit nicht akzeptiert oder teilweise ausgewählt (cherry-pick) wurde (die Git-Operation zum `cherry-pick` wird ausführlicher in <> behandelt). Wenn die Betreuer Ihre Arbeit `mergen`, `rebasen` oder `cherry-picken`, erhalten Sie ihre Arbeit sowieso zurück, wenn Sie aus dem Repository der Betreuer pullen. +Anschließend müssen Sie Ihre neue Arbeit in dieses Repository hochladen. +Es ist am einfachsten, den Branch, an dem Sie arbeiten, in Ihr geforktes Repository hochzuladen, anstatt diese Arbeit in Ihrem Master-Branch zusammenzuführen und diesen hochzuladen. +Der Grund dafür ist, dass Sie Ihren `master`-Branch nicht zurücksetzen müssen, wenn Ihre Arbeit nicht akzeptiert bzw. nur teilweise ausgewählt (cherry-pick) wurde (die Git-Operation zum `cherry-pick` wird ausführlicher in <> behandelt). +Wenn die Betreuer Ihre Arbeit per `mergen`, `rebase` oder `cherry-pick` übernehmen, erhalten Sie ihre Arbeit sowieso zurück, wenn Sie aus dem Repository der Betreuer pullen. -Auf jedem Fall können Sie Ihre Arbeit pushen mit: +Auf jedem Fall können Sie Ihre Arbeit hochladen mit: [source,console] ---- @@ -475,9 +546,11 @@ $ git push -u myfork featureA ---- (((git commands, request-pull))) -Sobald Ihre Arbeit an Ihren Fork des Repositorys gepusht wurde, müssen Sie den Betreuern des ursprünglichen Projekts mitteilen, dass Sie Änderungen haben, die sie zusammenführen möchten. Dies wird oft als _Pull Request_ bezeichnet. Sie generieren eine solche Anfrage entweder über die Website - GitHub hat einen eigenen Pull-Request-Mechanismus, den wir in <> behandeln werden, oder Sie können den Befehl `git request-pull` ausführen und die nachfolgende Ausgabe manuell per E-Mail an den Projektbetreuer senden. +Sobald Ihre Arbeit an Ihren Fork des Repositorys hochgeladen wurde, müssen Sie den Betreuern des ursprünglichen Projekts mitteilen, dass Sie Änderungen haben, die sie zusammenführen möchten. +Dies wird oft als _Pull Request_ bezeichnet. Sie generieren eine solche Anfrage entweder über die Website - GitHub hat einen eigenen „Pull-Request-Mechanismus“, den wir in <> behandeln werden, oder Sie können den Befehl `git request-pull` ausführen und die nachfolgende Ausgabe manuell per E-Mail an den Projektbetreuer senden. -Der Befehl `git request-pull` verwendet den Basis Branch, in den Ihr Themen Branch gepullt werden soll. Außerdem wird die Git-Repository-URL angegeben aus dem er gepullt werden solle. Er erstellt damit eine Zusammenfassung aller Änderungen, die Sie pullen möchten. Wenn bspw. Jessica an John eine Pull Request senden möchte und sie zwei Commits für den Themen Branch ausgeführt hat, den sie gerade gepusht hat, kann sie Folgendes ausführen: +Der Befehl `git request-pull` verwendet den Basis Branch, in den Ihr Themen Branch abgelegt werden soll. Außerdem wird die Git-Repository-URL angegeben aus dem er gezogen werden soll. Er erstellt damit eine Zusammenfassung aller Änderungen, um deren Übernahme Sie bitten. +Wenn bspw. Jessica an John eine Pull Request senden möchte und sie zwei Commits für den gerade hochgeladenen Themen Branch ausgeführt hat, kann sie folgendes ausführen: [source,console] ---- @@ -498,9 +571,11 @@ Jessica Smith (2): 1 files changed, 9 insertions(+), 1 deletions(-) ---- -Diese Ausgabe kann an den Betreuer gesendet werden. Sie teilt ihm mit, von wo die Arbeit gebranched wurde, fasst die Commits zusammen und identifiziert, von wo die neue Arbeit abgerufen werden soll. +Diese Ausgabe kann an den Betreuer gesendet werden. Sie teilt ihm mit, von wo die Arbeit gebranched wurde, fasst die Commits zusammen und gibt an, von wo die neue Arbeit abgerufen werden soll. -Bei einem Projekt, für das Sie nicht der Betreuer sind, ist es im Allgemeinen einfacher, einen Branch wie `master` zu haben, der immer `origin/master` verfolgt. Ihre Arbeit können Sie dann in Themen Branches erledigen, die Sie einfach verwerfen können, wenn ihre Änderungen abgelehnt werden. Durch das Isolieren von Änderungen in Themen Branches wird es für Sie auch einfacher, Ihre Arbeit neu zu strukturieren. falls sich das Haupt-Repositorys in der Zwischenzeit weiter bewegt hat und Ihre Commits nicht mehr sauber angewendet werden können. Wenn Sie beispielsweise ein zweites Thema an das Projekt senden möchten, arbeiten Sie nicht weiter an dem Branch, den Sie gerade gepusht haben. Beginnen Sie erneut im `master` Branch des Haupt-Repositorys: +Bei einem Projekt, für das Sie nicht der Betreuer sind, ist es im Allgemeinen einfacher, einen Branch wie `master` zu haben, der immer `origin/master` verfolgt. Ihre Arbeit können Sie dann in Themen Branches erledigen, die Sie einfach verwerfen können, wenn ihre Änderungen abgelehnt werden. +Durch das Isolieren von Änderungen in Themen Branches wird es für Sie auch einfacher, Ihre Arbeit neu zu strukturieren. Falls sich das Haupt-Repositorys in der Zwischenzeit weiter entwickelt hat und Ihre Commits nicht mehr sauber angewendet werden können. +Wenn Sie beispielsweise ein zweites Thema an das Projekt senden möchten, arbeiten Sie nicht weiter an dem Branch, den Sie gerade hochgeladen haben. Beginnen Sie erneut im `master` Branch des Haupt-Repositorys: [source,console] ---- @@ -513,12 +588,12 @@ $ git request-pull origin/master myfork $ git fetch origin ---- -Jetzt ist jedes Ihrer Themen in einem Silo enthalten, ähnlich wie bei einer Patch-Warteschlange. Dieses können Sie umarbeiten, zurücksetzen oder ändern, ohne dass die Themen sich gegenseitig stören oder voneinander abhängig sind. +Jetzt ist jedes Ihrer Themen in einer Art Silo enthalten, ähnlich wie bei einer Patch-Warteschlange. Dieses können Sie umarbeiten, zurücksetzen oder ändern, ohne dass die Themen sich gegenseitig stören oder voneinander abhängig sind. -.Initialer commit Verlauf mit `featureB` Änderungen. -image::images/public-small-1.png[Initialer commit Verlauf mit `featureB` Änderungen.] +.Initialer Commit Verlauf mit `featureB` Änderungen. +image::images/public-small-1.png[Initialer Commit Verlauf mit `featureB` Änderungen.] -Nehmen wir an, der Projektbetreuer hat eine Reihe weiterer Patches gepullt und Ihren ersten Branch ausprobiert, der jedoch nicht mehr ordnungsgemäß zusammengeführt werden kann. +Nehmen wir an, der Projektbetreuer hat eine Reihe weiterer Patches übernommen und Ihren ersten Branch einfließen lassen, der jedoch nicht mehr ordnungsgemäß zusammengeführt werden kann. In diesem Fall können Sie versuchen, diesen Branch auf `origin/master' zu reorganisieren, die Konflikte für den Betreuer zu lösen und Ihre Änderungen erneut zu übermitteln: [source,console] @@ -528,15 +603,18 @@ $ git rebase origin/master $ git push -f myfork featureA ---- -Dadurch wird Ihr Verlauf so umgeschrieben, dass er jetzt folgendermaßen aussieht <>. +Dadurch wird Ihr Verlauf so umgeschrieben, sodass er jetzt folgendermaßen aussieht <>. [[psp_b]] .Commit Verlauf nach `featureA` Änderungen. image::images/public-small-2.png[Commit Verlauf nach `featureA` Änderungen.] -Da Sie den Branch reorganisiert haben, müssen Sie das `-f` für Ihren Push-Befehl angeben, um den `featureA` Branch auf dem Server mit einen Commit ersetzen zu können, der kein Nachfolger von diesem ist. Eine Alternative wäre, diese neue Arbeit in einen anderen Branch auf dem Server zu pushen (beispielsweise als `featureAv2`). +Da Sie den Branch reorganisiert haben, müssen Sie das `-f` für Ihren Push-Befehl angeben, um den `featureA` Branch auf dem Server mit einen Commit ersetzen zu können, der nicht vom gegenwärtig letzten Commit des entfernten Branches abstammt. +Eine Alternative wäre, diese neue Arbeit in einen anderen Branch auf dem Server hochzuladen (beispielsweise als `featureAv2`). -Schauen wir uns ein weiteres mögliches Szenario an: Der Betreuer hat sich die Arbeit in Ihrem zweiten Branch angesehen und mag ihr Konzept, möchte aber, dass Sie ein Implementierungsdetail ändern. Sie nutzen diese Gelegenheit, um ihre Arbeit zusätzlich aus dem aktuellen Master-Branches des Projekts zu verlagern. Sie starten einen neuen Branch, der auf den aktuellen Branch `origin/master` basiert und fassen die Änderungen an `featureB` dort zusammen. Anschließend lösen sie etwaige Konflikte, machen die Implementierungsänderungen und pushen diese Arbeiten als neuen Branch: +Schauen wir uns ein weiteres mögliches Szenario an: Der Betreuer hat sich die Arbeit in Ihrem zweiten Branch angesehen und mag ihr Konzept, möchte aber, dass Sie ein Implementierungsdetail ändern. +Sie nutzen diese Gelegenheit, um Ihre Änderungen zu verschieben, damit diese auf dem aktuellen `master` Branch des Projektes basieren. +Sie starten einen neuen Branch, der auf den aktuellen Branch `origin/master` basiert und fassen die Änderungen an `featureB` dort zusammen. Dabei lösen sie etwaige Konflikte, machen die Implementierungsänderungen und laden diese Arbeiten als neuen Branch hoch: (((git commands, merge, squash))) [source,console] @@ -548,7 +626,9 @@ $ git commit $ git push myfork featureBv2 ---- -Mit der Option `--squash` wird die gesamte Arbeit an dem zusammengeführten Branch in einen Änderungssatz gedrückt. Dadurch wird ein Repository-Status erzeugt, als ob eine echte Zusammenführung stattgefunden hätte, ohne dass tatsächlich ein Merge-Commit durchgeführt wurde. Dies bedeutet, dass Ihr zukünftiger Commit nur einen übergeordneten Vorgänger hat. Das erlaubt ihnen alle Änderungen aus einem anderen Branch einzuführen und weitere Änderungen vorzunehmen, bevor Sie den neuen Commit aufnehmen. Auch die Option `--no-commit` kann nützlich sein, um den Merge-Commit im Falle des Standard-Merge-Prozesses zu verzögern. +Mit der Option `--squash` wird die gesamte Arbeit an dem zusammengeführten Branch in einen Änderungssatz komprimiert. Dadurch wird ein Repository-Status erzeugt, als ob eine echter Commit stattgefunden hätte, ohne dass tatsächlich ein Merge-Commit durchgeführt wurde. +Dies bedeutet, dass Ihr zukünftiger Commit nur einen übergeordneten Vorgänger hat. Das erlaubt ihnen alle Änderungen aus einem anderen Branch einzuführen und weitere Änderungen vorzunehmen, bevor Sie den neuen Commit aufnehmen. +Auch die Option `--no-commit` kann nützlich sein, um den Merge-Commit im Falle des Standard-Merge-Prozesses zu verzögern. Nun können Sie den Betreuer darüber informieren, dass Sie die angeforderten Änderungen vorgenommen haben und dass er diese Änderungen in Ihrem Branch `featureBv2` findet. @@ -559,9 +639,12 @@ image::images/public-small-3.png[Commit Verlauf nach getaner `featureBv2` Arbeit ==== Öffentliche Projekte via Email (((contributing, public large project))) -Viele Projekte haben fest definierte Prozesse, um Änderungen anzunehmen. Sie müssen die spezifischen Regeln dieser Projekte kennen, da sie sich oft unterscheiden. Da es viele alte und große Projekte gibt, die Änderungen über eine Entwickler-Mailingliste akzeptieren, werden wir jetzt solch ein Beispiel durchgehen. +Viele Projekte haben fest definierte Prozesse, um Änderungen entgegenzunehmen. Sie müssen die spezifischen Regeln dieser Projekte kennen, da sie sich oft unterscheiden. +Da es viele alte und große Projekte gibt, die Änderungen über eine Entwickler-Mailingliste akzeptieren, werden wir jetzt solch ein Beispiel durchgehen. -Der Workflow ähnelt dem vorherigen Anwendungsfall: Sie erstellen Themen Branches für jede Patch Serie, an der Sie arbeiten. Der Unterschied besteht darin, wie Sie diese an das Projekt senden. Anstatt das Projekt zu forken und auf Ihre eigene beschreibbare Version zu pushen, generieren Sie E-Mail-Versionen jeder Commit-Serie und senden sie per E-Mail an die Entwickler-Mailingliste: +Der Workflow ähnelt dem vorherigen Anwendungsfall: Sie erstellen Themen Branches für jede Patch Serie, an der Sie arbeiten. +Der Unterschied besteht darin, wie Sie diese Änderungen an das Projekt senden. +Anstatt das Projekt zu forken und auf Ihr eigenes geforktes Repository hochzuladen, generieren Sie E-Mail-Versionen jeder Commit-Serie und senden diese per E-Mail an die Entwickler-Mailingliste: [source,console] ---- @@ -573,7 +656,9 @@ $ git commit ---- (((git commands, format-patch))) -Jetzt haben Sie zwei Commits, die Sie an die Mailingliste senden könnten. Sie verwenden `git format-patch`, um die mbox-formatierten Dateien zu generieren, die Sie anschließend per E-Mail an die Mailingliste senden. Dabei wird jedes Commit in eine E-Mail-Nachricht umgewandelt. Die erste Zeile der Commit-Nachricht wird als Betreff verwendet. Der Rest der Commit-Nachricht plus den Patch, den der Commit einführt wird als Mail-Körper verwendet. Der Vorteil daran ist, dass durch das Anwenden eines Patches aus einer mit `format-patch` erstellten E-Mail alle Commit-Informationen ordnungsgemäß erhalten bleiben. +Jetzt haben Sie zwei Commits, die Sie an die Mailingliste senden können. +Sie verwenden `git format-patch`, um die mbox-formatierten Dateien zu generieren, die Sie anschließend per E-Mail an die Mailingliste senden. Dabei wird jedes Commit in eine E-Mail-Nachricht umgewandelt. Die erste Zeile der Commit-Nachricht wird als Betreff verwendet. Der Rest der Commit-Nachricht plus den Patch, den der Commit einführt wird als Mail-Körper verwendet. +Der Vorteil daran ist, dass durch das Anwenden eines Patches aus einer mit `format-patch` erstellten E-Mail alle Commit-Informationen ordnungsgemäß erhalten bleiben. [source,console] ---- @@ -582,7 +667,9 @@ $ git format-patch -M origin/master 0002-changed-log-output-to-30-from-25.patch ---- -Der Befehl `format-patch` gibt die Namen der von ihm erstellten Patch-Dateien aus. Die `-M` Option weist Git an, nach Umbenennungen zu suchen. Die Dateien sehen am Ende folgendermaßen aus: +Der Befehl `format-patch` gibt die Namen der von ihm erstellten Patch-Dateien aus. +Die `-M` Option weist Git an, nach Umbenennungen zu suchen. +Die Dateien sehen am Ende folgendermaßen aus: [source,console] ---- @@ -615,12 +702,17 @@ index 76f47bc..f9815f1 100644 2.1.0 ---- -Sie können diese Patch-Dateien auch bearbeiten, um weitere Informationen für die E-Mail-Liste hinzuzufügen, die nicht in der Commit-Nachricht angezeigt werden sollen. Wenn Sie Text zwischen der Zeile `---` und dem Beginn des Patches (der Zeile `diff --git`) einfügen, können die Entwickler diesen Text lesen. Der Inhalt wird jedoch vom Patch-Vorgang ignoriert. +Sie können diese Patch-Dateien auch bearbeiten, um weitere Informationen für die E-Mail-Liste hinzuzufügen, die nicht in der Commit-Nachricht angezeigt werden sollen. +Wenn Sie Text zwischen der Zeile `---` und dem Beginn des Patches (der Zeile `diff --git`) einfügen, können die Entwickler diesen Text lesen. Der Inhalt wird jedoch vom Patch-Vorgang ignoriert. -Um dies per E-Mail an eine Mailingliste zu senden, können Sie die Datei entweder an eine Mail anhängen oder über ein Befehlszeilenprogramm senden. Das Einfügen von Text führt häufig zu Formatierungsproblemen, insbesondere bei "intelligenten" Clients, bei denen Zeilenumbrüche und andere Leerzeichen nicht ordnungsgemäß beibehalten werden. Glücklicherweise bietet Git ein Tool, mit dem Sie ordnungsgemäß formatierte Patches über IMAP senden können, was für Sie möglicherweise einfacher ist. Wir zeigen Ihnen, wie Sie einen Patch über Google Mail senden. Dies ist der E-Mail-Agent, den wir am besten kennen. Detaillierte Anweisungen für eine Reihe von Mail-Programmen finden Sie am Ende der oben genannten Datei `Documentation/SubmittingPatches` im Git-Quellcode. +Um dies nun per E-Mail an eine Mailingliste zu senden, können Sie die Datei entweder an eine Mail anhängen oder über ein Befehlszeilenprogramm direkt versenden. +Das Einfügen von Text führt häufig zu Formatierungsproblemen, insbesondere bei „intelligenten“ Clients, bei denen Zeilenumbrüche und andere Leerzeichen nicht ordnungsgemäß beibehalten werden. +Glücklicherweise bietet Git ein Tool, mit dem Sie ordnungsgemäß formatierte Patches über IMAP senden können, was einfacher für Sie sein könnte. +Wir zeigen Ihnen, wie Sie einen Patch über Google Mail senden. Dies ist der E-Mail-Agent, mit dem wur uns am besten auskennen. Detaillierte Anweisungen für eine Reihe von anderen Mail-Programmen finden Sie am Ende der oben genannten Datei `Documentation/SubmittingPatches` im Git-Quellcode. (((git commands, config)))(((email))) -Zuerst müssen Sie den Abschnitt imap in Ihrer `~/.gitconfig` Datei einrichten. Sie können jeden Wert separat mit einer Reihe von `git config` Befehlen festlegen oder manuell hinzufügen. Am Ende sollte Ihre Konfigurationsdatei ungefähr so aussehen: +Zuerst müssen Sie den Abschnitt imap in Ihrer `~/.gitconfig` Datei einrichten. +Sie können jeden Wert separat mit einer Reihe von `git config` Befehlen festlegen oder manuell hinzufügen. Am Ende sollte Ihre Konfigurationsdatei ungefähr so aussehen: [source,ini] ---- @@ -633,7 +725,8 @@ Zuerst müssen Sie den Abschnitt imap in Ihrer `~/.gitconfig` Datei einrichten. sslverify = false ---- -Wenn Ihr IMAP-Server kein SSL verwendet, sind die letzten beiden Zeilen wahrscheinlich nicht erforderlich. Der Hostwert lautet dann `imap://` anstelle von `imaps://`. Wenn dies eingerichtet ist, können Sie `git imap-send` verwenden, um die Patch-Reihe im Ordner `Entwürfe` des angegebenen IMAP-Servers abzulegen: +Wenn Ihr IMAP-Server kein SSL verwendet, sind die letzten beiden Zeilen wahrscheinlich nicht erforderlich. Der Hostwert lautet dann `imap://` anstelle von `imaps://`. +Wenn dies eingerichtet ist, können Sie `git imap-send` verwenden, um die Patch-Reihe im Ordner `Entwürfe` des angegebenen IMAP-Servers abzulegen: [source,console] ---- @@ -647,7 +740,8 @@ sending 2 messages Zu diesem Zeitpunkt sollten Sie in der Lage sein, in Ihren Entwurfsordner zu wechseln und dort das Feld An der generierten Email in die Mailinglist-Adresse zu ändern, an die Sie den Patch senden wollen. Möglicherweise wollen sie auch den Betreuer oder die Person in Kopie nehmen, die für diesen Abschnitt verantwortlich ist. Anschließend können sie die Mail versenden. -Sie können die Patches auch über einen SMTP-Server senden. Wie zuvor können Sie jeden Wert separat mit einer Reihe von `git config` Befehlen festlegen oder manuell im Abschnitt sendemail in Ihrer `~/.gitconfig` Datei hinzufügen: +Sie können die Patches auch über einen SMTP-Server senden. +Wie zuvor können Sie jeden Wert separat mit einer Reihe von `git config` Befehlen festlegen oder manuell im Abschnitt sendemail in Ihrer `~/.gitconfig` Datei hinzufügen: [source,ini] ---- @@ -671,7 +765,7 @@ Who should the emails be sent to? jessica@example.com Message-ID to be used as In-Reply-To for the first email? y ---- -Git gibt anschließend für jeden Patch, den Sie senden, eine Reihe von Protokollinformationen aus, die in etwa so aussehen: +Git gibt anschließend für jeden Patch, den Sie versenden, eine Reihe von Protokollinformationen aus, die in etwa so aussehen: [source,text] ---- @@ -693,4 +787,6 @@ Result: OK ==== Zusammenfassung -In diesem Abschnitt wurden eine Reihe gängiger Workflows für den Umgang mit verschiedenen Arten von Git-Projekten behandelt. Außerdem wurden einige neue Tools vorgestellt, die Sie bei der Verwaltung dieser Prozesse unterstützen. Als Nächstes erfahren Sie, wie Sie auf der anderen Seite arbeiten: als Verwalter (Maintainer) eines Git-Projektes. Sie lernen, wie man sich als wohlwollender Diktator oder Integrationsmanager verhält. \ No newline at end of file +In diesem Abschnitt wurden eine Reihe gängiger Arbeitsabläufe für den Umgang mit verschiedenen Arten von Git-Projekten behandelt. Außerdem wurden einige neue Tools vorgestellt, die Sie bei der Verwaltung dieser Prozesse unterstützen. +Als Nächstes erfahren Sie, wie Sie auf der anderen Seite arbeiten: als Verwalter (Maintainer) eines Git-Projektes. +Sie lernen, wie man sich als wohlwollender Diktator oder Integrationsmanager korrekt arbeitet. \ No newline at end of file diff --git a/status.json b/status.json index 0f5a07ac..60e6bd47 100644 --- a/status.json +++ b/status.json @@ -45,9 +45,9 @@ "sections/smart-http.asc": 0 }, "05-distributed-git": { - "1-distributed-git.asc": 0, - "sections/contributing.asc": 0, - "sections/distributed-workflows.asc": 0, + "1-distributed-git.asc": 100, + "sections/contributing.asc": 100, + "sections/distributed-workflows.asc": 100, "sections/maintaining.asc": 0 }, "06-github": { From 54b55dc18168f7b387ff38372869f3bbe110e43d Mon Sep 17 00:00:00 2001 From: pastatopf Date: Thu, 12 Sep 2019 12:24:57 +0200 Subject: [PATCH 04/14] Translated book/05-distributed-git/sections/maintaining.asc to german --- TRANSLATION_NOTES_DE.asc | 6 +- .../sections/maintaining.asc | 108 +++++++++--------- 2 files changed, 62 insertions(+), 52 deletions(-) diff --git a/TRANSLATION_NOTES_DE.asc b/TRANSLATION_NOTES_DE.asc index b58eae3a..4cde5bc2 100644 --- a/TRANSLATION_NOTES_DE.asc +++ b/TRANSLATION_NOTES_DE.asc @@ -59,6 +59,8 @@ Bitte erfinden Sie keine neue deutsche Übersetzung, sondern orientieren Sie sic [width="100%", frame="topbot", options="header,footer"] |============================================================================== |Englisch|Deutsch +|to apply| +anwenden |Branch| Branch; Singular: der Branch; Plural: die Branches; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung „Zweig“ verwendet werden. |Branchname| @@ -78,7 +80,7 @@ Commit-ID; Singular: die Commit-ID; Plural: die Commit-IDs |Commit message| Commit-Beschreibung; Singular: die Commit-Beschreibung; Plural: die Commit-Beschreibungen; Alternativ: die Commit-Nachricht |Contributor| -Mitwirkender +Mitwirkender; Beitragender |Diff| Diff; Singular: der Diff; Plural: die Diffs; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung 'Vergleich oder Ausgabe eines Vergleichs' verwendet werden. |============================================================================== @@ -119,6 +121,8 @@ Projektbetreuer betreuen |to merge| mergen; er/sie mergt; wir mergen; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung "zusammenführen oder verschmelzen" verwendet werden. +|Patch| +Änderung oder auch Patch |to pull| pullen; er/sie pullt; wir pullen; Deutsch: übernehmen |Pull Request| diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 44cab806..60d2eac6 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -1,59 +1,61 @@ -=== Maintaining a Project +=== Ein Projekt verwalten (((maintaining a project))) -In addition to knowing how to contribute effectively to a project, you'll likely need to know how to maintain one. -This can consist of accepting and applying patches generated via `format-patch` and emailed to you, or integrating changes in remote branches for repositories you've added as remotes to your project. -Whether you maintain a canonical repository or want to help by verifying or approving patches, you need to know how to accept work in a way that is clearest for other contributors and sustainable by you over the long run. +Sie müssen nicht nur wissen, wie Sie effektiv zu einem Projekt etewas beitragen, sondern auch wissen, wie Sie ein Projekt verwalten. +Sie müssen bspw. wissen wie sie Patches akzeptieren und anwenden, die über `format-patch` generiert und per E-Mail an Sie gesendet wurden. Weiterhin sollten sie wissen wie sie Änderungen in Remote-Branches für Repositorys integrieren, die Sie als Remotes zu Ihrem Projekt hinzugefügt haben. +Unabhängig davon, ob Sie ein zentrales Repository verwalten oder durch Überprüfen oder Genehmigen von Patches helfen möchten, müssen Sie wissen, wie Sie die Arbeit auf eine Weise akzeptieren, die für andere Mitwirkende transparent und auf lange Sicht auch nachhaltig ist. -==== Working in Topic Branches +==== Arbeiten in Themen Branches (((branches, topic))) -When you're thinking of integrating new work, it's generally a good idea to try it out in a _topic branch_ -- a temporary branch specifically made to try out that new work. -This way, it's easy to tweak a patch individually and leave it if it's not working until you have time to come back to it. -If you create a simple branch name based on the theme of the work you're going to try, such as `ruby_client` or something similarly descriptive, you can easily remember it if you have to abandon it for a while and come back later. -The maintainer of the Git project tends to namespace these branches as well -- such as `sc/ruby_client`, where `sc` is short for the person who contributed the work. -As you'll remember, you can create the branch based off your `master` branch like this: +Wenn man vor hat, neuen Quelltext zu integrieren, ist es im Allgemeinen eine gute Idee, sie in einem _Topic Branch_ auszuprobieren - einem temporären Branch, der speziell zum Ausprobieren dieser neuen Änderungen erstellt wurde. +Auf diese Weise ist es einfach, einen Patch einzeln zu optimieren und ihn nicht weiter zu bearbeiten, wenn er nicht funktioniert, bis Sie Zeit haben, sich wieder damit zu befassen. +Sie sollten einen einfachen Branchnamen erstellen, der auf dem Thema der Arbeit basiert, die Sie durchführen, wie z.B. `ruby_client` oder etwas ähnlich sprechendes. Dann können Sie sich später leichter daran erinnern, falls Sie den Branch für eine Weile haben ruhen lassen und später daran weiter arbeiten. +Der Betreuer des Git-Projekts neigt auch dazu, diese Branches mit einem Namespace zu versehen - wie z. B. `sc/ruby_client`, wobei `sc` für die Person steht, die die Arbeit beigesteuert hat. +Wie Sie sich erinnern werden, können Sie den Branch basierend auf Ihrem `master`-Branch wie folgt erstellen: [source,console] ---- $ git branch sc/ruby_client master ---- -Or, if you want to also switch to it immediately, you can use the `checkout -b` option: +Wenn sie anschliessend sofort zum neuen Branch wechseln möchten, können Sie auch die Option `checkout -b` verwenden: [source,console] ---- $ git checkout -b sc/ruby_client master ---- -Now you're ready to add the contributed work that you received into this topic branch and determine if you want to merge it into your longer-term branches. +Jetzt können Sie die eingereichte Arbeit zu diesem Branch hinzufügen und festlegen, ob Sie ihn mit Ihren bestehenden Branches zusammenführen möchten. [[_patches_from_email]] -==== Applying Patches from Email +==== Anwenden von Änderungen aus E-Mails (((email, applying patches from))) -If you receive a patch over email that you need to integrate into your project, you need to apply the patch in your topic branch to evaluate it. -There are two ways to apply an emailed patch: with `git apply` or with `git am`. +Wenn Sie einen Patch per E-Mail erhalten, den Sie in Ihr Projekt integrieren müssen, müssen Sie den Patch in Ihrer Themen Branch anwenden, damit sie ihn prüfen können. +Es gibt zwei Möglichkeiten, einen per E-Mail versendeten Patch anzuwenden: mit `git apply` oder mit` git am`. -===== Applying a Patch with apply +===== Änderungen mit `apply` anwenden (((git commands, apply))) If you received the patch from someone who generated it with `git diff` or some variation of the Unix `diff` command (which is not recommended; see the next section), you can apply it with the `git apply` command. Assuming you saved the patch at `/tmp/patch-ruby-client.patch`, you can apply the patch like this: +Wenn Sie den Patch von jemandem erhalten haben, der ihn mit `git diff` oder mit einer Variante Unix-Befehls` diff` erzeugt hat (was nicht empfohlen wird; siehe nächster Abschnitt), können Sie ihn mit dem Befehl `git apply` anwenden. +Angenommen Sie haben den Patch unter `/tmp/patch-ruby-client.patch` gespeichert. Dann können Sie den Patch folgendermaßen anwenden: [source,console] ---- $ git apply /tmp/patch-ruby-client.patch ---- -This modifies the files in your working directory. -It's almost identical to running a `patch -p1` command to apply the patch, although it's more paranoid and accepts fewer fuzzy matches than patch. -It also handles file adds, deletes, and renames if they're described in the `git diff` format, which `patch` won't do. -Finally, `git apply` is an ``apply all or abort all'' model where either everything is applied or nothing is, whereas `patch` can partially apply patchfiles, leaving your working directory in a weird state. -`git apply` is overall much more conservative than `patch`. -It won't create a commit for you -- after running it, you must stage and commit the changes introduced manually. +Hierdurch werden die Dateien in Ihrem Arbeitsverzeichnis geändert. +Es ist fast identisch mit dem Ausführen eines `patch -p1` Befehls zum Anwenden des Patches, obwohl es paranoider ist und unscharfe Übereinstimmungen selektiver als `patch' akzeptiert. +Damit kann man auch Dateien Hinzufügen, Löschen und Umbenennen, wenn diese im `git diff`-Format beschrieben sind, was mit `patch` nicht möglich ist. +Zu guter letzt ist `git apply` ein ``wende alles oder nichts an''-Modell, bei dem entweder alles oder nichts angewendet wird, wohingegen `patch` Patchdateien teilweise anwenden kann und Ihr Arbeitsverzeichnis in einnm undefinierten Zustand versetzen kann. +`git apply` ist insgesamt sehr viel konservativer als` patch`. +Es wird kein Commit für Sie erstellen. Nach dem Ausführen müssen Sie die eingeführten Änderungen manuell bereitstellen und einchecken. -You can also use `git apply` to see if a patch applies cleanly before you try actually applying it -- you can run `git apply --check` with the patch: +Sie können auch `git apply` verwenden, um zu prüfen, ob ein Patch ordnungsgemäß angewendet wird, bevor Sie versuchen, ihn tatsächlich anzuwenden. Sie können `git apply --check` auf den Patch ausführen: [source,console] ---- @@ -62,20 +64,20 @@ error: patch failed: ticgit.gemspec:1 error: ticgit.gemspec: patch does not apply ---- -If there is no output, then the patch should apply cleanly. -This command also exits with a non-zero status if the check fails, so you can use it in scripts if you want. +Wenn keine Ausgabe erfolgt, sollte der Patch ordnungsgemäß angewendet werden können. +Dieser Befehl wird auch mit einem Rückgabewert ungleich Null beendet, wenn die Prüfung fehlschlägt, sodass Sie ihn bei Bedarf in Skripten verwenden können. [[_git_am]] -===== Applying a Patch with `am` +===== Änderungen mit `am` anwenden (((git commands, am))) -If the contributor is a Git user and was good enough to use the `format-patch` command to generate their patch, then your job is easier because the patch contains author information and a commit message for you. -If you can, encourage your contributors to use `format-patch` instead of `diff` to generate patches for you. -You should only have to use `git apply` for legacy patches and things like that. +Wenn der Beitragende ein Git-Benutzer ist und den Befehl `format-patch` zum Generieren seines Patches verwendet hat, ist Ihre Arbeit einfacher. Der Patch enthält bereits Informationen über dem Autor und eine entsprechende Commitnachricht. +Wenn möglich, ermutigen Sie die Beitragenden `format-patch` anstelle von `diff` zum erstellen von Patches zu verwenden. +Sie sollten `git apply` nur für ältere Patches und ähnliche Dinge verwenden. -To apply a patch generated by `format-patch`, you use `git am` (the command is named `am` as it is used to "apply a series of patches from a mailbox"). -Technically, `git am` is built to read an mbox file, which is a simple, plain-text format for storing one or more email messages in one text file. -It looks something like this: +Um einen von `format-patch` erzeugten Patch anzuwenden, verwenden Sie `git am` (der Befehl heißt `am`, da er verwendet wird, um „eine Reihe von Patches aus einer Mailbox anzuwenden“). +Technisch gesehen ist `git am` so aufgebaut, dass eine mbox-Datei gelesen werden kann. Hierbei handelt es sich um ein einfaches Nur-Text-Format zum Speichern einer oder mehrerer E-Mail-Nachrichten in einer Textdatei. +Das sieht in etwa so aus: [source,console] ---- @@ -87,11 +89,11 @@ Subject: [PATCH 1/2] add limit to log function Limit log functionality to the first 20 ---- -This is the beginning of the output of the `git format-patch` command that you saw in the previous section; it also represents a valid mbox email format. -If someone has emailed you the patch properly using `git send-email`, and you download that into an mbox format, then you can point `git am` to that mbox file, and it will start applying all the patches it sees. -If you run a mail client that can save several emails out in mbox format, you can save entire patch series into a file and then use `git am` to apply them one at a time. +Dies ist der Anfang der Ausgabe des Befehls `git format-patch`, den Sie im vorherigen Abschnitt gesehen haben. Es zeigt ein gültiges mbox Email Format. +Wenn Ihnen jemand den Patch ordnungsgemäß mit `git send-email` per E-Mail zugesendet hat und Sie ihn in ein mbox-Format herunterladen, können Sie `git am` auf diese mbox-Datei auführen und alle angezeigten Patches werden entsprechend angewendet. +Wenn Sie einen Mail-Client ausführen, der mehrere E-Mails im Mbox-Format speichern kann, können Sie ganze Patch-Serien in einer Datei speichern und diese dann mit `git am` einzeln anwenden. -However, if someone uploaded a patch file generated via `git format-patch` to a ticketing system or something similar, you can save the file locally and then pass that file saved on your disk to `git am` to apply it: +Wenn jedoch jemand eine mit `git format-patch` erzeugte Patch-Datei in ein Ticketing-System oder ähnliches hochgeladen hat, können Sie die Datei lokal speichern und diese auf Ihrer Festplatte gespeicherte Datei dann an `git am` übergeben, um sie anzuwenden: [source,console] ---- @@ -103,6 +105,10 @@ You can see that it applied cleanly and automatically created the new commit for The author information is taken from the email's `From` and `Date` headers, and the message of the commit is taken from the `Subject` and body (before the patch) of the email. For example, if this patch was applied from the mbox example above, the commit generated would look something like this: +Sie können sehen, dass es korrekt angewendet und das neue Commit automatisch für Sie erstellt wurde. +Die Autoreninformationen werden aus den Kopfzeilen `From` und `Date` der E-Mail entnommen und die Nachricht des Commits wird aus dem `Subject` und dem Textkörper (vor dem Patch) der E-Mail entnommen. +Wenn dieser Patch beispielsweise aus dem obigen mbox-Beispiel angewendet würde, würde der erzeugte Commit ungefähr so aussehen: + [source,console] ---- $ git log --pretty=fuller -1 @@ -117,12 +123,12 @@ CommitDate: Thu Apr 9 09:19:06 2009 -0700 Limit log functionality to the first 20 ---- -The `Commit` information indicates the person who applied the patch and the time it was applied. -The `Author` information is the individual who originally created the patch and when it was originally created. +Die `Commit`-Informationen gibt die Person an, die den Patch angewendet hat und den Zeitpunkt, wann er angewendet wurde. +Die `Author`-Information gibt die Person an, die den Patch ursprünglich erstellt hat und wann er ursprünglich erstellt wurde. -But it's possible that the patch won't apply cleanly. -Perhaps your main branch has diverged too far from the branch the patch was built from, or the patch depends on another patch you haven't applied yet. -In that case, the `git am` process will fail and ask you what you want to do: +Es besteht jedoch die Möglichkeit, dass der Patch nicht sauber angewendet werden kann. +Möglicherweise ist Ihr Hauptbranch zu weit vom Branch entfernt, von dem aus der Patch erstellt wurde. Oder aber der Patch hängt noch von einem anderen Patch ab, den Sie noch nicht angewendet haben. +In diesem Fall schlägt der Prozess `git am` fehl und Sie werden gefragt, was Sie tun möchten: [source,console] ---- @@ -136,8 +142,8 @@ If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". ---- -This command puts conflict markers in any files it has issues with, much like a conflicted merge or rebase operation. -You solve this issue much the same way -- edit the file to resolve the conflict, stage the new file, and then run `git am --resolved` to continue to the next patch: +Dieser Befehl fügt Konfliktmarkierungen in alle Dateien ein, in denen Probleme auftreten. Ähnlich wie bei einem Konflikt bei der Zusammenführung (engl. merge) bzw. der Reorganisation (engl rebase). +Sie lösen dieses Problem auf die gleiche Weise: Bearbeiten Sie die Datei, um den Konflikt zu lösen. Anschliessend fügen sie die neue Datei der Staging Area hinzu und führen Sie dann `git am --resolved` aus, um mit dem nächsten Patch fortzufahren: [source,console] ---- @@ -147,9 +153,9 @@ $ git am --resolved Applying: seeing if this helps the gem ---- -If you want Git to try a bit more intelligently to resolve the conflict, you can pass a `-3` option to it, which makes Git attempt a three-way merge. -This option isn't on by default because it doesn't work if the commit the patch says it was based on isn't in your repository. -If you do have that commit -- if the patch was based on a public commit -- then the `-3` option is generally much smarter about applying a conflicting patch: +Wenn Sie möchten, dass Git den Konflikt etwas intelligenter löst, können Sie ihm die Option "-3" übergeben, wodurch Git versucht, eine Dreifachzusammenführung durchzuführen. +Diese Option ist standardmäßig nicht aktiviert, da sie nicht funktioniert, wenn sich das Commit, auf dem der Patch basiert, nicht in Ihrem Repository befindet. +Wenn Sie diesen Commit haben - wenn der Patch auf einem öffentlichen Commit basiert -, ist die Option "-3" im Allgemeinen viel intelligenter beim Anwenden eines Patch mit Konflikten: [source,console] ---- @@ -162,10 +168,10 @@ Falling back to patching base and 3-way merge... No changes -- Patch already applied. ---- -In this case, without the `-3` option the patch would have been considered as a conflict. -Since the `-3` option was used the patch applied cleanly. +In diesem Fall wäre der Patch ohne die Option "-3" als Konflikt gewertet worden. +Da die Option "-3" verwendet wurde, wurde der Patch sauber angewendet. -If you're applying a number of patches from an mbox, you can also run the `am` command in interactive mode, which stops at each patch it finds and asks if you want to apply it: +Wenn Sie mehrere Patches von einer mbox aus anwenden, können Sie auch den Befehl `am` im interaktiven Modus ausführen. Bei jedem gefundenen Patch wird angehalten und Sie werden gefragt, ob Sie ihn anwenden möchten: [source,console] ---- @@ -177,9 +183,9 @@ seeing if this helps the gem Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all ---- -This is nice if you have a number of patches saved, because you can view the patch first if you don't remember what it is, or not apply the patch if you've already done so. +Dies ist hilfreich, wenn Sie eine Reihe von Patches gespeichert haben, da Sie den Patch zuerst anzeigen können, wenn Sie sich nicht daran erinnern, worum es genau geht. Oder aber weil sie den Patch nicht anwenden können, weil Sie dies bereits getan haben. -When all the patches for your topic are applied and committed into your branch, you can choose whether and how to integrate them into a longer-running branch. +Wenn alle Patches für Ihr Thema angewendet und in Ihrem Branch festgeschrieben wurden, können Sie auswählen, ob und wie Sie sie in einen Hauptzweig integrieren möchten. [[_checking_out_remotes]] ==== Checking Out Remote Branches From f8e9815dda1bbdbdc2dac7d88265c7b0266a2a10 Mon Sep 17 00:00:00 2001 From: pastatopf Date: Mon, 16 Sep 2019 17:37:31 +0200 Subject: [PATCH 05/14] translated book/05-distributed-git/sections/maintaining.asc to german --- .../sections/maintaining.asc | 281 +++++++++--------- 1 file changed, 143 insertions(+), 138 deletions(-) diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 60d2eac6..7109e37c 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -188,12 +188,12 @@ Dies ist hilfreich, wenn Sie eine Reihe von Patches gespeichert haben, da Sie de Wenn alle Patches für Ihr Thema angewendet und in Ihrem Branch festgeschrieben wurden, können Sie auswählen, ob und wie Sie sie in einen Hauptzweig integrieren möchten. [[_checking_out_remotes]] -==== Checking Out Remote Branches +==== Remote Branches auschecken (((branches, remote))) -If your contribution came from a Git user who set up their own repository, pushed a number of changes into it, and then sent you the URL to the repository and the name of the remote branch the changes are in, you can add them as a remote and do merges locally. +Wenn sie einen Beitrag erhalten, der von einem Git-Benutzer stammt, der sein eigenes Repository eingerichtet, eine Reihe von Änderungen vorgenommen und Ihnen dann die URL zum Repository und den Namen des Remote-Zweigs gesendet hat, in dem sich die Änderungen befinden, können Sie diesen als remote hinzufügen und die Änderungen lokal zusammenführen. -For instance, if Jessica sends you an email saying that she has a great new feature in the `ruby-client` branch of her repository, you can test it by adding the remote and checking out that branch locally: +Wenn Jessica Ihnen beispielsweise eine E-Mail sendet, die besagt, dass sie eine großartige neue Funktion im `ruby-client` Branch ihres Repositorys hat, können Sie diese testen, indem Sie den Branch als remote hinzufügen und ihn lokal auschecken: [source,console] ---- @@ -202,18 +202,18 @@ $ git fetch jessica $ git checkout -b rubyclient jessica/ruby-client ---- -If she emails you again later with another branch containing another great feature, you could directly `fetch` and `checkout` because you already have the remote setup. +Wenn sie Ihnen später erneut eine E-Mail mit einem anderen Branch sendet, der eine weitere großartige Funktion enthält, können Sie diese direkt abrufen und auschecken, da Sie bereits über das Remote Repository verfügen. -This is most useful if you're working with a person consistently. -If someone only has a single patch to contribute once in a while, then accepting it over email may be less time consuming than requiring everyone to run their own server and having to continually add and remove remotes to get a few patches. -You're also unlikely to want to have hundreds of remotes, each for someone who contributes only a patch or two. -However, scripts and hosted services may make this easier -- it depends largely on how you develop and how your contributors develop. +Dies ist am nützlichsten, wenn Sie durchweg mit einer Person arbeiten. +Wenn nur ein Patch von Zeit zu Zeit zur Verfügung steht, ist das Akzeptieren über E-Mail möglicherweise weniger zeitaufwendig, als dass jeder seinen eigenen Server unterhalten und Remotes hinzufügen und entfernen muss, um einige wenige Patches zu erhalten. +Es ist auch unwahrscheinlich, dass Sie Hunderte von Remotes einbinden möchten für Personen, die nur ein oder zwei Patches beisteuern. +Skripte und gehostete Dienste können dies jedoch vereinfachen - dies hängt weitgehend davon ab, wie Sie und die Mitwirkenden sich entwickeln. -The other advantage of this approach is that you get the history of the commits as well. -Although you may have legitimate merge issues, you know where in your history their work is based; a proper three-way merge is the default rather than having to supply a `-3` and hope the patch was generated off a public commit to which you have access. +Der andere Vorteil dieses Ansatzes ist, dass Sie auch die Historie der Commits erhalten. +Obwohl Sie möglicherweise berechtigte Probleme bei der Zusammenführungen haben, wissen Sie, wo in Ihrer Hisorie deren Arbeit basiert. Eine ordnungsgemäße Drei-Wege-Zusammenführung ist die Standardeinstellung, anstatt ein "-3" einzugeben, und sie hoffen, dass der Patch aus einem öffentlichen Commit generiert wurde, auf den Sie Zugriff haben. -If you aren't working with a person consistently but still want to pull from them in this way, you can provide the URL of the remote repository to the `git pull` command. -This does a one-time pull and doesn't save the URL as a remote reference: +Wenn Sie nicht durchgehen mit einer Person arbeiten, aber dennoch auf diese Weise von dieser Person abrufen möchten, können Sie die URL des Remote-Repositorys für den Befehl `git pull` angeben. +Dies führt einen einmaligen Abruf durch und speichert die URL nicht als Remote-Referenz: [source,console] ---- @@ -224,17 +224,17 @@ Merge made by the 'recursive' strategy. ---- [[_what_is_introduced]] -==== Determining What Is Introduced +==== Bestimmen, was eingeführt wird (((branches, diffing))) -Now you have a topic branch that contains contributed work. -At this point, you can determine what you'd like to do with it. -This section revisits a couple of commands so you can see how you can use them to review exactly what you'll be introducing if you merge this into your main branch. +Jetzt haben Sie einen Themen Branch mit neuen Beiträgen. +An dieser Stelle können Sie festlegen, was Sie damit machen möchten. +In diesem Abschnitt werden einige Befehle noch einmal behandelt, damit Sie sehen können, wie Sie sie verwenden können. So können sie genau überprüfen, was Sie einführen, wenn Sie die Beiträge in Ihrem Haupt Branch zusammenführen. -It's often helpful to get a review of all the commits that are in this branch but that aren't in your master branch. -You can exclude commits in the master branch by adding the `--not` option before the branch name. -This does the same thing as the `master..contrib` format that we used earlier. -For example, if your contributor sends you two patches and you create a branch called `contrib` and applied those patches there, you can run this: +Es ist oft hilfreich, eine Übersicht über alle Commits zu erhalten, die sich in diesem Branch jedoch nicht in Ihrem Master-Branch befinden. +Sie können Commits im Master-Branch ausschließen, indem Sie die Option "--not" vor dem Branchnamen hinzufügen. +Dies entspricht dem Format `master..contrib`, das wir zuvor verwendet haben. +Wenn Ihr Mitarbeiter Ihnen beispielsweise zwei Patches sendet und Sie einen Branch mit dem Namen `contrib` erstellen und diese Patches dort anwenden, können Sie Folgendes ausführen: [source,console] ---- @@ -252,27 +252,27 @@ Date: Mon Oct 22 19:38:36 2008 -0700 updated the gemspec to hopefully work better ---- -To see what changes each commit introduces, remember that you can pass the `-p` option to `git log` and it will append the diff introduced to each commit. +Denken Sie daran, dass Sie die Option `-p` an `git log` übergeben können, um zu sehen, welche Änderungen jeder Commit einführt, und den Diff an jeden Commit anfügt. -To see a full diff of what would happen if you were to merge this topic branch with another branch, you may have to use a weird trick to get the correct results. -You may think to run this: +Um einen vollständigen Überblick darüber zu erhalten, was passieren würde, wenn Sie diesen Branch mit einem anderen Branch zusammenführen würden, müssen Sie möglicherweise einen ungeröhnlichen Kniff anwenden, um die richtigen Ergebnisse zu erzielen. +Eventuell denken sie daran folgendes auszuführen: [source,console] ---- $ git diff master ---- -This command gives you a diff, but it may be misleading. -If your `master` branch has moved forward since you created the topic branch from it, then you'll get seemingly strange results. -This happens because Git directly compares the snapshots of the last commit of the topic branch you're on and the snapshot of the last commit on the `master` branch. -For example, if you've added a line in a file on the `master` branch, a direct comparison of the snapshots will look like the topic branch is going to remove that line. +Dieser Befehl gibt Ihnen den Unterschied zurück, jedoch kann dies irreführend sein. +Wenn Ihr Master-Branch vorgerückt ist, seit Sie den Themen-Branch daraus erstellt haben, erhalten Sie scheinbar unerwartete Ergebnisse. +Dies geschieht, weil Git den Snapshots des letzten Commits des Branches, in dem Sie sich befinden, und den Snapshot des letzten Commits des Branches `master` direkt miteinander vergleicht. +Wenn Sie beispielsweise eine Zeile in eine Datei im Branch `master` eingefügt haben, sieht ein direkter Vergleich der Snapshots so aus, als würde der Themen Branch diese Zeile entfernen. -If `master` is a direct ancestor of your topic branch, this isn't a problem; but if the two histories have diverged, the diff will look like you're adding all the new stuff in your topic branch and removing everything unique to the `master` branch. +Wenn `master` ein direkter Vorgänger Ihres Themen Branches ist, ist dies kein Problem. Wenn die beiden Historien jedoch voneinander abweichen, sieht es so aus, als würden Sie alle neuen Inhalte in Ihrem Themen Branch hinzufügen und alles entfernen, was für den `master` Branch eindeutig ist. -What you really want to see are the changes added to the topic branch -- the work you'll introduce if you merge this branch with master. -You do that by having Git compare the last commit on your topic branch with the first common ancestor it has with the master branch. +Was Sie wirklich sehen möchten, sind die Änderungen, die dem Themen Branch hinzugefügt wurden - die Arbeit, die Sie hinzufügen, wenn Sie den neuen Branch mit `master` zusammenführen. +Sie tun dies, indem Git das letzte Commit in Ihrem Themen Branch mit dem ersten gemeinsamen Vorgänger vom `master` Branch vergleicht. -Technically, you can do that by explicitly figuring out the common ancestor and then running your diff on it: +Technisch gesehen können Sie dies tun, indem Sie den gemeinsamen Vorgänger explizit herausfinden und dann Ihr `diff` darauf ausführen: [source,console] ---- @@ -281,116 +281,121 @@ $ git merge-base contrib master $ git diff 36c7db ---- -or, more concisely: +oder kurzgefasst: [source,console] ---- $ git diff $(git merge-base contrib master) ---- -However, neither of those is particularly convenient, so Git provides another shorthand for doing the same thing: the triple-dot syntax. -In the context of the `git diff` command, you can put three periods after another branch to do a `diff` between the last commit of the branch you're on and its common ancestor with another branch: +Beides ist jedoch nicht besonders praktisch, weshalb Git eine andere Weg für diesen Vorgang bietet: die Drei-Punkt-Syntax (engl. Triple-Dot-Syntax). +Im Kontext des Befehls `git diff` können Sie drei Punkte nach einem anderen Branch einfügen, um ein `diff` zwischen dem letzten Commit ihres aktullen Branchs, in dem Sie sich befinden, und dem gemeinsamen Vorgänger eines anderen Branches zu erstellen: [source,console] ---- $ git diff master...contrib ---- -This command shows you only the work your current topic branch has introduced since its common ancestor with master. -That is a very useful syntax to remember. +Dieser Befehl zeigt Ihnen nur die Arbeit an, die Ihr aktueller Branch seit seinem gemeinsamen Vorgänger mit master eingeführt hat. +Dies ist eine sehr nützliche Syntax, die sie sich merken sollten. -==== Integrating Contributed Work +==== Beiträge integrieren (((integrating work))) -When all the work in your topic branch is ready to be integrated into a more mainline branch, the question is how to do it. -Furthermore, what overall workflow do you want to use to maintain your project? -You have a number of choices, so we'll cover a few of them. +Wenn alle Arbeiten in Ihrem Themen Branch bereit sind, um in ein größeren Hauptbranch integriert zu werden, lautet die Frage, wie Sie dies tun können. +Welchen Workflow möchten Sie verwenden, um Ihr Projekt zu verwalten? +Sie haben eine Reihe von Möglichkeiten, daher werden wir einige davon behandeln. -===== Merging Workflows +===== Workflows zusammenführen (engl. mergen) (((workflows, merging))) -One basic workflow is to simply merge all that work directly into your `master` branch. -In this scenario, you have a `master` branch that contains basically stable code. -When you have work in a topic branch that you think you've completed, or work that someone else has contributed and you've verified, you merge it into your master branch, delete that just-merged topic branch, and repeat. +Ein grundlegender Workflow besteht darin, all diese Arbeiten einfach direkt in Ihrem `master`Branch zusammenzuführen. +In diesem Szenario haben Sie einen `master`-Branch, der stabilen Code enthält. +Wenn Sie in einem Branch arbeiten, von dem Sie glauben, dass Sie ihn abgeschlossen haben, oder von jemand anderem beigesteuert und überprüft haben, führen Sie ihn in Ihrem Hauptbranch zusammen. Löschen sie anschliessend diesen gerade zusammengeführten Branch und wiederholen diesen Vorgang bei Bedarf. -For instance, if we have a repository with work in two branches named `ruby_client` and `php_client` that looks like <>, and we merge `ruby_client` followed by `php_client`, your history will end up looking like <>. +Wenn wir zum Beispiel ein Repository mit zwei Branches namens `ruby_client` und `php_client` haben, die wie <> aussehen, und wir `ruby_client` gefolgt von `php_client` zusammenführen, sieht Ihr Verlauf wie <> aus. [[merwf_a]] -.History with several topic branches. -image::images/merging-workflows-1.png[History with several topic branches.] +.Historie mit meheren Topic Branches. +image::images/merging-workflows-1.png[Historie mit meheren Topic Branches.] [[merwf_b]] -.After a topic branch merge. -image::images/merging-workflows-2.png[After a topic branch merge.] +.Status nach einem Themen Branch Merge. +image::images/merging-workflows-2.png[Status nach einem Themen Branch Merge.] -That is probably the simplest workflow, but it can possibly be problematic if you're dealing with larger or more stable projects where you want to be really careful about what you introduce. +Das ist wahrscheinlich der einfachste Workflow. Es kann jedoch zu Problemen können, wenn Sie größere oder stabilere Projekte bearbeiten. Sie müssen bei der Einführung von Änderungen sehr vorsichtig sein. -If you have a more important project, you might want to use a two-phase merge cycle. -In this scenario, you have two long-running branches, `master` and `develop`, in which you determine that `master` is updated only when a very stable release is cut and all new code is integrated into the `develop` branch. -You regularly push both of these branches to the public repository. -Each time you have a new topic branch to merge in (<>), you merge it into `develop` (<>); then, when you tag a release, you fast-forward `master` to wherever the now-stable `develop` branch is (<>). +Wenn Sie ein wichtigeres Projekt haben, möchten Sie möglicherweise einen zweistufigen Merge Prozess verwenden. +In diesem Szenario haben Sie zwei lange laufende Branches namens `master` und `develop`. Sie legen fest, dass `master` nur dann aktualisiert wird, wenn eine sehr stabile Version vorhanden ist und der gesamte neue Code in den Branch `develop` integriert wird. +Sie pushen diese beiden Branches regelmäßig in das öffentliche Repository. +Jedes Mal, wenn Sie einen neuen Branch zum Zusammenführen haben (<>), führen Sie ihn in `develop` (<< merwf_d >>) zusammen. Wenn Sie ein Release mit einem Tag versehen, spulen Sie `master` an die Stelle weiter, an der sich der jetzt stabile `develop`-Branch befindet (<>). [[merwf_c]] -.Before a topic branch merge. -image::images/merging-workflows-3.png[Before a topic branch merge.] +.Vor einem Themen Branch Merge. +image::images/merging-workflows-3.png[Vor einem Themen Branch Merge.] [[merwf_d]] -.After a topic branch merge. -image::images/merging-workflows-4.png[After a topic branch merge.] +.Nach einem Themen Branch Merge. +image::images/merging-workflows-4.png[Nach einem Themen Branch Merge.] [[merwf_e]] -.After a project release. -image::images/merging-workflows-5.png[After a topic branch release.] +.Nach einem Projekt Release. +image::images/merging-workflows-5.png[Nach einem Projekt Release.] -This way, when people clone your project's repository, they can either check out `master` to build the latest stable version and keep up to date on that easily, or they can check out `develop`, which is the more cutting-edge content. -You can also extend this concept by having an `integrate` branch where all the work is merged together. -Then, when the codebase on that branch is stable and passes tests, you merge it into a `develop` branch; and when that has proven itself stable for a while, you fast-forward your `master` branch. +Auf diese Weise können Benutzer, die das Repository Ihres Projekts klonen, entweder `master` oder `develop` auschecken. Mit `master` können sie die neueste stabile Version erstellen und somit recht einfache auf dem neuesten Stand bleiben. Oder sie können `develop` auschecken, welchen den aktuellsten Inhalt darstellt. +Sie können dieses Konzept auch erweitern, indem Sie einen `integrate`-Branch einrichten, in dem alle Arbeiten zusammengeführt werden. +Wenn die Codebasis auf diesem Branch stabil ist und die Tests erfolgreich sind, können Sie sie zu einem Entwicklungsbranch zusammen führen. Wenn sich das als stabil erwiesen hat, können sie ihren `master`-Branch fast-forwarden. -===== Large-Merging Workflows +===== Workflows mit umfangreichen Merges (((workflows, "merging (large)"))) -The Git project has four long-running branches: `master`, `next`, and `pu` (proposed updates) for new work, and `maint` for maintenance backports. -When new work is introduced by contributors, it's collected into topic branches in the maintainer's repository in a manner similar to what we've described (see <>). -At this point, the topics are evaluated to determine whether they're safe and ready for consumption or whether they need more work. -If they're safe, they're merged into `next`, and that branch is pushed up so everyone can try the topics integrated together. +Das Git-Projekt hat vier lange laufende Branches: `master`, `next` und `pu` (vorgeschlagene Updates) für neue Arbeiten und `maint` für Wartungs-Backports. +Wenn neue Arbeiten von Mitwirkenden eingereicht werden, werden sie in ähnlicher Weise wie oben beschrieben in Themenbranches im Projektarchiv des Betreuers gesammelt (siehe <>). +Zu diesem Zeitpunkt werden die Themen evaluiert, um festzustellen, ob sie korrekt sind und zur Weiterverarbeitung bereit sind oder ob sie Nacharbeit benötigen. +Wenn sie korrekt sind, werden sie zu `next` zusammengeführt, und dieser Branch wird gepushed, damit jeder die miteinander integrierten Themen testen kann. [[merwf_f]] -.Managing a complex series of parallel contributed topic branches. -image::images/large-merges-1.png[Managing a complex series of parallel contributed topic branches.] +.Verwaltung einer komplexen Reihe paralleler Themenbranches. +image::images/large-merges-1.png[Verwaltung einer komplexen Reihe paralleler Themenbranches.] If the topics still need work, they're merged into `pu` instead. When it's determined that they're totally stable, the topics are re-merged into `master`. The `next` and `pu` branches are then rebuilt from the `master`. This means `master` almost always moves forward, `next` is rebased occasionally, and `pu` is rebased even more often: -.Merging contributed topic branches into long-term integration branches. -image::images/large-merges-2.png[Merging contributed topic branches into long-term integration branches.] +Wenn die Themen noch bearbeitet werden müssen, werden sie in `pu` gemerged. +Wenn festgestellt wird, dass sie absolut stabil sind, werden die Themen wieder zu `master` zusammengeführt. +Die Branches `next` und `pu` werden dann vom `master` neu aufgebaut. +Dies bedeutet, dass `master` fast immer vorwärts geht, `next` wird gelegentlich neu rebased und `pu` noch häufiger rebased wird: -When a topic branch has finally been merged into `master`, it's removed from the repository. -The Git project also has a `maint` branch that is forked off from the last release to provide backported patches in case a maintenance release is required. -Thus, when you clone the Git repository, you have four branches that you can check out to evaluate the project in different stages of development, depending on how cutting edge you want to be or how you want to contribute; and the maintainer has a structured workflow to help them vet new contributions. -The Git project's workflow is specialized. -To clearly understand this you could check out the https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt[Git Maintainer's guide]. +.Zusammenführen von Themen Branches in langfristige Integrationsbranches. +image::images/large-merges-2.png[Zusammenführen von Themen Branches in langfristige Integrationsbranches.] + +Wenn ein Branch schließlich zu `master` zusammengeführt wurde, wird er aus dem Repository entfernt. +Das Git-Projekt hat auch einen `maint`-Branch, der von der letzten Version geforkt wurde, um für den Fall, dass eine Wartungsversion erforderlich ist, Backport-Patches bereitzustellen. +Wenn Sie das Git-Repository klonen, stehen Ihnen vier Branches zur Verfügung, mit denen Sie das Projekt in verschiedenen Entwicklungsstadien bewerten können, je nachdem, wie aktuell Sie sein möchten oder wie Sie einen Beitrag leisten möchten. Der Betreuer verfügt über einen strukturierten Workflow, der ihm hilft, neue Beiträge zu überprüfen. +Der Workflow des Git-Projekts ist sehr speziell. +Um dies klar zu verstehen, können Sie das https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt[Git Maintainer's guide] lesen. [[_rebase_cherry_pick]] -===== Rebasing and Cherry-Picking Workflows +===== Rebasing und Cherry-Picking Workflows (((workflows, rebasing and cherry-picking))) -Other maintainers prefer to rebase or cherry-pick contributed work on top of their master branch, rather than merging it in, to keep a mostly linear history. -When you have work in a topic branch and have determined that you want to integrate it, you move to that branch and run the rebase command to rebuild the changes on top of your current master (or `develop`, and so on) branch. -If that works well, you can fast-forward your `master` branch, and you'll end up with a linear project history. +Andere Betreuer bevorzugen es, die Arbeit auf ihrem Masterbranch zu rebasen oder zu cherry-picken, anstatt sie zusammenzuführen, um einen linearen Verlauf beizubehalten. +Wenn Sie in einem Themen Branch arbeiten und sich dazu entschlossen haben, ihn zu integrieren, wechseln Sie in diesen Branch und führen den `rebase`Befehl aus. Damit stellen sie die , um die Änderungen auf Ihrem aktuellen `master` (oder `develop`-Branch usw.) wiederherzustellen. +Wenn das gut funktioniert, können Sie Ihren `master`-Branch fast-forwarden, und Sie erhalten eine lineare Projekthistorie. (((git commands, cherry-pick))) -The other way to move introduced work from one branch to another is to cherry-pick it. -A cherry-pick in Git is like a rebase for a single commit. -It takes the patch that was introduced in a commit and tries to reapply it on the branch you're currently on. -This is useful if you have a number of commits on a topic branch and you want to integrate only one of them, or if you only have one commit on a topic branch and you'd prefer to cherry-pick it rather than run rebase. -For example, suppose you have a project that looks like this: +Die andere Möglichkeit, die eingeführte Arbeit von einem Branch in einen anderen zu verschieben, besteht darin, sie zu cherry-picken. +Ein Cherry-Pick in Git ist wie ein Rebase für ein einzelnes Commit. +Es verwendet den Patch, der in einem Commit eingeführt wurde, und versucht, ihn erneut auf den Branch anzuwenden, auf dem Sie sich gerade befinden. +Dies ist nützlich, wenn Sie eine Reihe von Commits für einen Branch haben und nur eine davon integrieren möchten, oder wenn Sie nur einen Commit für einen Branch haben und Sie es vorziehen, diese zu cherry-picken, anstatt ein Rebase auszuführen. +Angenommen, Sie haben ein Projekt, das folgendermaßen aussieht: -.Example history before a cherry-pick. -image::images/rebasing-1.png[Example history before a cherry-pick.] +.Beispiel Historie vor einem Cherry-Pick. +image::images/rebasing-1.png[Beispiel Historie vor einem Cherry-Pick.] -If you want to pull commit `e43a6` into your master branch, you can run +Wenn Sie das Commit "e43a6" in Ihren Master-Branch ziehen möchten, können Sie folgendes ausführen: [source,console] ---- @@ -400,44 +405,44 @@ Finished one cherry-pick. 3 files changed, 17 insertions(+), 3 deletions(-) ---- -This pulls the same change introduced in `e43a6`, but you get a new commit SHA-1 value, because the date applied is different. -Now your history looks like this: +Dies zieht die gleiche Änderung nach sich, die in `e43a6` eingeführt wurde. Sie erhalten jedoch einen neuen Commit SHA-1-Wert, da das angewendete Datum unterschiedlich ist. +Nun sieht die Historie so aus: -.History after cherry-picking a commit on a topic branch. -image::images/rebasing-2.png[History after cherry-picking a commit on a topic branch.] +.Historie nach Cherry-Picken eines Commits auf einen Themen Branch. +image::images/rebasing-2.png[Historie nach Cherry-Picken eines Commits auf einen Themen Branch.] -Now you can remove your topic branch and drop the commits you didn't want to pull in. +Jetzt können Sie Ihren Themen Branch entfernen und die Commits löschen, die Sie nicht mehr benötigen. ===== Rerere (((git commands, rerere)))(((rerere))) -If you're doing lots of merging and rebasing, or you're maintaining a long-lived topic branch, Git has a feature called ``rerere'' that can help. +Wenn Sie viel mergen und rebasen oder einen langlebigen Themenbranch pflegen, hat Git eine Funktion namens ``rerere'', die helfen kann. -Rerere stands for ``reuse recorded resolution'' -- it's a way of shortcutting manual conflict resolution. -When rerere is enabled, Git will keep a set of pre- and post-images from successful merges, and if it notices that there's a conflict that looks exactly like one you've already fixed, it'll just use the fix from last time, without bothering you with it. +Rerere steht für ``reuse recorded resolution'' (deutsch ``Aufgezeichnete Lösung wiederverwenden'') - es ist eine Möglichkeit, die manuelle Konfliktlösung zu verkürzen. +Wenn rerere aktiviert ist, behält Git eine Reihe von Pre- und Post-Images von erfolgreichen Commits bei. Wenn es feststellt, dass ein Konflikt genau so aussieht, wie der, den Sie bereits behoben haben, wird nur die Korrektur vom letzten Mal verwendet , ohne nochmal zu belästigen. -This feature comes in two parts: a configuration setting and a command. -The configuration setting is `rerere.enabled`, and it's handy enough to put in your global config: +Diese Funktion besteht aus zwei Teilen: einer Konfigurationseinstellung und einem Befehl. +Die Konfigurationseinstellung lautet `rerere.enabled`. Man kann sie in die globale Konfiguration eingeben: [source,console] ---- $ git config --global rerere.enabled true ---- -Now, whenever you do a merge that resolves conflicts, the resolution will be recorded in the cache in case you need it in the future. +Wenn Sie nun einen merge durchführen, der die Konflikte auflöst, wird diese Auflösung im Cache gespeichert, falls Sie sie in Zukunft benötigen. -If you need to, you can interact with the rerere cache using the `git rerere` command. -When it's invoked alone, Git checks its database of resolutions and tries to find a match with any current merge conflicts and resolve them (although this is done automatically if `rerere.enabled` is set to `true`). -There are also subcommands to see what will be recorded, to erase specific resolution from the cache, and to clear the entire cache. -We will cover rerere in more detail in <>. +Bei Bedarf können Sie mit dem Cache interagieren mittels dem Befehl `git rerere`. +Wenn es aufgerufen wird, überprüft Git seine Lösungsdatenbank und versucht eine Übereinstimmung mit aktuellen Mergekonflikten zu finden und diese zu lösen (dies geschieht jedoch automatisch, wenn `rerere.enabled` auf` true` gesetzt ist). +Es gibt auch Unterbefehle, um zu sehen, was aufgezeichnet wird, um eine bestimmte Konfliktlösung aus dem Cache zu löschen oder um den gesamten Cache zu löschen. +Wir werden uns in <> eingehender mit rerere beschäftigen. [[_tagging_releases]] -==== Tagging Your Releases +==== Tagging ihres Releases (((tags)))(((tags, signing))) -When you've decided to cut a release, you'll probably want to assign a tag so you can re-create that release at any point going forward. -You can create a new tag as discussed in <>. -If you decide to sign the tag as the maintainer, the tagging may look something like this: +Wenn Sie sich entschieden haben, ein Release zu erstellen, dann möchten Sie wahrscheinlich einen Tag zuweisen, damit Sie dieses Release in Zukunft jederzeit neu erstellen können. +Sie können einen neuen Tag erstellen, wie in <> beschrieben. +Wenn Sie den Tag als Betreuer signieren möchten, sieht der Tag möglicherweise folgendermaßen aus: [source,console] ---- @@ -447,9 +452,9 @@ user: "Scott Chacon " 1024-bit DSA key, ID F721C45A, created 2009-02-09 ---- -If you do sign your tags, you may have the problem of distributing the public PGP key used to sign your tags. -The maintainer of the Git project has solved this issue by including their public key as a blob in the repository and then adding a tag that points directly to that content. -To do this, you can figure out which key you want by running `gpg --list-keys`: +Wenn Sie Ihre Tags signieren, haben Sie möglicherweise das Problem, den öffentlichen PGP-Schlüssel zu verteilen, der zum Signieren Ihrer Tags verwendet wird. +Der Betreuer des Git-Projekts hat dieses Problem behoben, indem er seinen öffentlichen Schlüssel als Blob in das Repository aufgenommen und anschließend ein enTag hinzugefügt hat, der direkt auf diesen Inhalt verweist. +Um dies zu tun, können Sie herausfinden, welchen Schlüssel Sie möchten, indem Sie `gpg --list-keys` ausführen: [source,console] ---- @@ -461,7 +466,7 @@ uid Scott Chacon sub 2048g/45D02282 2009-02-09 [expires: 2010-02-09] ---- -Then, you can directly import the key into the Git database by exporting it and piping that through `git hash-object`, which writes a new blob with those contents into Git and gives you back the SHA-1 of the blob: +Anschließend können Sie den Schlüssel direkt in die Git-Datenbank importieren, indem Sie ihn exportieren und diesen über `git hash-object` weiterleiten. Dadurch wird ein neuer Blob mit diesen Inhalten in Git geschrieben und Sie erhalten den SHA-1 des Blobs zurück: [source,console] ---- @@ -469,30 +474,30 @@ $ gpg -a --export F721C45A | git hash-object -w --stdin 659ef797d181633c87ec71ac3f9ba29fe5775b92 ---- -Now that you have the contents of your key in Git, you can create a tag that points directly to it by specifying the new SHA-1 value that the `hash-object` command gave you: +Nachdem Sie nun den Inhalt Ihres Schlüssels in Git haben, können Sie einen Tag erstellen, der direkt darauf verweist, indem Sie den neuen SHA-1-Wert angeben, den Sie mit dem Befehl `hash-object` erhalten haben: [source,console] ---- $ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92 ---- -If you run `git push --tags`, the `maintainer-pgp-pub` tag will be shared with everyone. -If anyone wants to verify a tag, they can directly import your PGP key by pulling the blob directly out of the database and importing it into GPG: +Wenn Sie `git push --tags` ausführen, wird der `maintainer-pgp-pub`-Tag für alle freigegeben. +Wenn jemand einen Tag verifizieren möchte, kann er Ihren PGP-Schlüssel direkt importieren, indem er den Blob direkt aus der Datenbank zieht und in GPG importiert: [source,console] ---- $ git show maintainer-pgp-pub | gpg --import ---- -They can use that key to verify all your signed tags. -Also, if you include instructions in the tag message, running `git show ` will let you give the end user more specific instructions about tag verification. +Mit diesem Schlüssel können sie alle Ihre signierten Tags überprüfen. +Wenn Sie der Tag-Nachricht Anweisungen hinzufügen, können Sie dem Endbenutzer mit `git show ` genauere Anweisungen zur Tag-Überprüfung geben. [[_build_number]] -==== Generating a Build Number +==== Eine Build Nummer generieren (((build numbers)))(((git commands, describe))) -Because Git doesn't have monotonically increasing numbers like 'v123' or the equivalent to go with each commit, if you want to have a human-readable name to go with a commit, you can run `git describe` on that commit. -In response, Git generates a string consisting of the name of the most recent tag earlier than that commit, followed by the number of commits since that tag, followed finally by a partial SHA-1 value of the commit being described (prefixed with the letter "g" meaning Git): +Da Git nicht über ansteigende Zahlen wie 'v123' oder das Äquivalent für jedes Commit verfügt, können Sie für dieses Commit den Befehl `git describe` ausführen, wenn Sie einen lesbaren Namen für einen Commit benötigen. +Als Antwort generiert Git eine Zeichenfolge, die aus dem Namen des jüngsten Tags vor diesem Commit besteht, gefolgt von der Anzahl der Commits seit diesem Tag, gefolgt von einem partiellen SHA-1-Wert des beschriebene Commits (vorangestelltem wird dem Buchstaben "g" für Git): [source,console] ---- @@ -500,21 +505,21 @@ $ git describe master v1.6.2-rc1-20-g8c5b85c ---- -This way, you can export a snapshot or build and name it something understandable to people. -In fact, if you build Git from source code cloned from the Git repository, `git --version` gives you something that looks like this. -If you're describing a commit that you have directly tagged, it gives you simply the tag name. +Auf diese Weise können Sie einen Snaphot exportieren oder einen Build erstellen und einen verständlichen Namen vergeben. +Wenn Sie Git aus den Quellcode erstellen, der aus dem Git-Repository geklont wurde, erhalten Sie mit `git --version` etwas, das genau so aussieht. +Wenn Sie einen Commit beschreiben, den Sie direkt getaggt haben, erhalten Sie einfach den Tag-Namen. -By default, the `git describe` command requires annotated tags (tags created with the `-a` or `-s` flag); if you want to take advantage of lightweight (non-annotated) tags as well, add the `--tags` option to the command. -You can also use this string as the target of a `git checkout` or `git show` command, although it relies on the abbreviated SHA-1 value at the end, so it may not be valid forever. -For instance, the Linux kernel recently jumped from 8 to 10 characters to ensure SHA-1 object uniqueness, so older `git describe` output names were invalidated. +Standardmäßig erfordert der Befehl `git describe` mit Anmerkungen versehene Tags (Tags, die mit dem Flag `-a` oder `-s` erstellt wurden). Wenn Sie auch leichte (nicht mit Anmerkungen versehene) Tags verwenden möchten, fügen Sie dem Befehl die Option `--tags` hinzu. +Sie können diese Zeichenfolge auch als Ziel der Befehle `git checkout` oder `git show` verwenden, obwohl sie auf dem abgekürzten SHA-1-Wert am Ende basiert, sodass sie möglicherweise nicht für immer gültig ist. +Zum Beispiel hat der Linux-Kernel kürzlich einen Sprung von 8 auf 10 Zeichen gemacht, um die Eindeutigkeit von SHA-1-Objekten zu gewährleisten, sodass ältere Ausgabenamen von `git describe` ungültig wurden. [[_preparing_release]] -==== Preparing a Release +==== Ein Release vorbereiten (((releasing)))(((git commands, archive))) -Now you want to release a build. -One of the things you'll want to do is create an archive of the latest snapshot of your code for those poor souls who don't use Git. -The command to do this is `git archive`: +Nun möchten Sie einen Build freigeben. +Eines der Dinge, die Sie tun möchten, ist, ein Archiv des neuesten Schnappschusses Ihres Codes für die armen Seelen zu erstellen, die Git nicht verwenden. +Der Befehl dazu lautet `git archive`: [source,console] ---- @@ -523,23 +528,23 @@ $ ls *.tar.gz v1.6.2-rc1-20-g8c5b85c.tar.gz ---- -If someone opens that tarball, they get the latest snapshot of your project under a project directory. -You can also create a zip archive in much the same way, but by passing the `--format=zip` option to `git archive`: +Wenn jemand dieses Archiv öffnet, erhält er den neuesten Schnappschuss Ihres Projekts in einem Projektverzeichnis. +Sie können ein zip-Archiv auch auf die gleiche Weise erstellen, indem Sie jedoch die Option `--format=zip` an `git archive` übergeben: [source,console] ---- $ git archive master --prefix='project/' --format=zip > `git describe master`.zip ---- -You now have a nice tarball and a zip archive of your project release that you can upload to your website or email to people. +Sie haben jetzt einen schönen Tarball und ein Zip-Archiv Ihrer Projektversion, die Sie auf Ihre Website hochladen oder per E-Mail an andere Personen senden können. [[_the_shortlog]] -==== The Shortlog +==== Das Shortlog (((git commands, shortlog))) -It's time to email your mailing list of people who want to know what's happening in your project. -A nice way of quickly getting a sort of changelog of what has been added to your project since your last release or email is to use the `git shortlog` command. -It summarizes all the commits in the range you give it; for example, the following gives you a summary of all the commits since your last release, if your last release was named v1.0.1: +Es ist Zeit, eine E-Mail an die Personen Ihre Mailingliste zu senden, die wissen möchten, was in Ihrem Projekt vor sich geht. +Mit dem Befehl `git shortlog` können Sie schnell eine Art Änderungsprotokoll dessen abrufen, was Ihrem Projekt seit Ihrer letzten Veröffentlichung oder E-Mail hinzugefügt wurde. +Es fasst alle Commits in dem von Ihnen angegebenen Bereich zusammen. Im Folgenden finden Sie als Beispiel 0eine Zusammenfassung aller Commits seit Ihrer letzten Veröffentlichung, sofern Ihre letzte Veröffentlichung den Namen v1.0.1 hat: [source,console] ---- @@ -559,4 +564,4 @@ Tom Preston-Werner (4): Regenerated gemspec for version 1.0.2 ---- -You get a clean summary of all the commits since v1.0.1, grouped by author, that you can email to your list. +Sie erhalten eine übersichtliche Zusammenfassung aller Commits seit Version 1.0.1, gruppiert nach Autoren, die Sie per E-Mail an Ihre Mailingliste senden können. From c77ba7ad22f7d8b31f602e5e9d61a0c8d7c08a5b Mon Sep 17 00:00:00 2001 From: pastatopf Date: Mon, 16 Sep 2019 17:52:56 +0200 Subject: [PATCH 06/14] Deleted some english text which was still in the tranlsation --- book/05-distributed-git/sections/maintaining.asc | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 7109e37c..865127a4 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -38,7 +38,6 @@ Es gibt zwei Möglichkeiten, einen per E-Mail versendeten Patch anzuwenden: mit ===== Änderungen mit `apply` anwenden (((git commands, apply))) -If you received the patch from someone who generated it with `git diff` or some variation of the Unix `diff` command (which is not recommended; see the next section), you can apply it with the `git apply` command. Assuming you saved the patch at `/tmp/patch-ruby-client.patch`, you can apply the patch like this: Wenn Sie den Patch von jemandem erhalten haben, der ihn mit `git diff` oder mit einer Variante Unix-Befehls` diff` erzeugt hat (was nicht empfohlen wird; siehe nächster Abschnitt), können Sie ihn mit dem Befehl `git apply` anwenden. Angenommen Sie haben den Patch unter `/tmp/patch-ruby-client.patch` gespeichert. Dann können Sie den Patch folgendermaßen anwenden: @@ -101,10 +100,6 @@ $ git am 0001-limit-log-function.patch Applying: add limit to log function ---- -You can see that it applied cleanly and automatically created the new commit for you. -The author information is taken from the email's `From` and `Date` headers, and the message of the commit is taken from the `Subject` and body (before the patch) of the email. -For example, if this patch was applied from the mbox example above, the commit generated would look something like this: - Sie können sehen, dass es korrekt angewendet und das neue Commit automatisch für Sie erstellt wurde. Die Autoreninformationen werden aus den Kopfzeilen `From` und `Date` der E-Mail entnommen und die Nachricht des Commits wird aus dem `Subject` und dem Textkörper (vor dem Patch) der E-Mail entnommen. Wenn dieser Patch beispielsweise aus dem obigen mbox-Beispiel angewendet würde, würde der erzeugte Commit ungefähr so aussehen: @@ -358,11 +353,6 @@ Wenn sie korrekt sind, werden sie zu `next` zusammengeführt, und dieser Branch .Verwaltung einer komplexen Reihe paralleler Themenbranches. image::images/large-merges-1.png[Verwaltung einer komplexen Reihe paralleler Themenbranches.] -If the topics still need work, they're merged into `pu` instead. -When it's determined that they're totally stable, the topics are re-merged into `master`. -The `next` and `pu` branches are then rebuilt from the `master`. -This means `master` almost always moves forward, `next` is rebased occasionally, and `pu` is rebased even more often: - Wenn die Themen noch bearbeitet werden müssen, werden sie in `pu` gemerged. Wenn festgestellt wird, dass sie absolut stabil sind, werden die Themen wieder zu `master` zusammengeführt. Die Branches `next` und `pu` werden dann vom `master` neu aufgebaut. From 61e0217fa2671688fa6c1d2fe0293a8ee4b94457 Mon Sep 17 00:00:00 2001 From: pastatopf Date: Mon, 16 Sep 2019 17:54:48 +0200 Subject: [PATCH 07/14] Deleted one line in english --- book/05-distributed-git/sections/maintaining.asc | 1 - 1 file changed, 1 deletion(-) diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 865127a4..80ac6c03 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -38,7 +38,6 @@ Es gibt zwei Möglichkeiten, einen per E-Mail versendeten Patch anzuwenden: mit ===== Änderungen mit `apply` anwenden (((git commands, apply))) -Assuming you saved the patch at `/tmp/patch-ruby-client.patch`, you can apply the patch like this: Wenn Sie den Patch von jemandem erhalten haben, der ihn mit `git diff` oder mit einer Variante Unix-Befehls` diff` erzeugt hat (was nicht empfohlen wird; siehe nächster Abschnitt), können Sie ihn mit dem Befehl `git apply` anwenden. Angenommen Sie haben den Patch unter `/tmp/patch-ruby-client.patch` gespeichert. Dann können Sie den Patch folgendermaßen anwenden: From d955cda0c079909c5806527367ffd300c750d0ac Mon Sep 17 00:00:00 2001 From: pastatopf Date: Tue, 10 Sep 2019 21:05:18 +0200 Subject: [PATCH 08/14] Translated book/05-distributed-git/sections/contributing.asc to german --- TRANSLATION_NOTES_DE.asc | 4 ++++ book/05-distributed-git/sections/contributing.asc | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/TRANSLATION_NOTES_DE.asc b/TRANSLATION_NOTES_DE.asc index 68d022b7..558ebf34 100644 --- a/TRANSLATION_NOTES_DE.asc +++ b/TRANSLATION_NOTES_DE.asc @@ -112,7 +112,11 @@ Integrator |============================================================================== |Englisch|Deutsch |Lieutenant| +<<<<<<< HEAD der Leutnant; Plural: die Leutnants +======= +der Leutnant; Plural: die Leutnante +>>>>>>> Translated book/05-distributed-git/sections/contributing.asc to german |Maintainer| Projektbetreuer |to maintain| diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 918fc87c..c63e9028 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -789,4 +789,4 @@ Result: OK In diesem Abschnitt wurden eine Reihe gängiger Arbeitsabläufe für den Umgang mit verschiedenen Arten von Git-Projekten behandelt. Außerdem wurden einige neue Tools vorgestellt, die Sie bei der Verwaltung dieser Prozesse unterstützen. Als Nächstes erfahren Sie, wie Sie auf der anderen Seite arbeiten: als Verwalter (Maintainer) eines Git-Projektes. -Sie lernen, wie man sich als wohlwollender Diktator oder Integrationsmanager korrekt arbeitet. \ No newline at end of file +Sie lernen, wie man sich als wohlwollender Diktator oder Integrationsmanager korrekt arbeitet. From 6637453a492a16a42e5e132c4054695dfcaefb3b Mon Sep 17 00:00:00 2001 From: pastatopf Date: Mon, 23 Sep 2019 20:03:30 +0200 Subject: [PATCH 09/14] code geaendert --- ch05-distributed-git.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch05-distributed-git.asc b/ch05-distributed-git.asc index f7c77ec0..007497d8 100644 --- a/ch05-distributed-git.asc +++ b/ch05-distributed-git.asc @@ -2,7 +2,7 @@ == Verteiltes Git (((distributed git))) -Nachdem Sie ein entferntes Git Repository eingerichtet haben, in dem alle Entwickler ihren Quellcode teilen können, und Sie mit den grundlegenden Git-Befehlen in einem lokalen Arbeitsablauf vertraut sind, werden Sie einige der verteilten Arbeitsabläufe verwenden, die Git Ihnen ermöglicht. +Nachdem Sie ein entferntes Git Repository eingerichtet haben, in dem alle Entwickler ihren Code teilen können, und Sie mit den grundlegenden Git-Befehlen in einem lokalen Arbeitsablauf vertraut sind, werden Sie einige der verteilten Arbeitsabläufe verwenden, die Git Ihnen ermöglicht. In diesem Kapitel erfahren Sie, wie Sie mit Git in einer verteilten Umgebung als Mitwirkender und Integrator arbeiten. Das heißt, Sie lernen, wie Sie Quelltext erfolgreich zu einem Projekt beisteuern und es Ihnen und dem Projektbetreuer so einfach wie möglich machen. Außerdem lernen Sie, wie Sie ein Projekt erfolgreich verwalten, in dem mehrere Entwicklern Inhalte beisteuern. From 53e2f454695ea594e2553ae9139cded1f860e3be Mon Sep 17 00:00:00 2001 From: pastatopf Date: Thu, 12 Sep 2019 12:24:57 +0200 Subject: [PATCH 10/14] Translated book/05-distributed-git/sections/maintaining.asc to german --- TRANSLATION_NOTES_DE.asc | 6 +- .../sections/maintaining.asc | 108 +++++++++--------- 2 files changed, 62 insertions(+), 52 deletions(-) diff --git a/TRANSLATION_NOTES_DE.asc b/TRANSLATION_NOTES_DE.asc index 558ebf34..8926087f 100644 --- a/TRANSLATION_NOTES_DE.asc +++ b/TRANSLATION_NOTES_DE.asc @@ -59,6 +59,8 @@ Bitte erfinden Sie keine neue deutsche Übersetzung, sondern orientieren Sie sic [width="100%", frame="topbot", options="header,footer"] |============================================================================== |Englisch|Deutsch +|to apply| +anwenden |Branch| Branch; Singular: der Branch; Plural: die Branches; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung „Zweig“ verwendet werden. |Branchname| @@ -78,7 +80,7 @@ Commit-ID; Singular: die Commit-ID; Plural: die Commit-IDs |Commit message| Commit-Beschreibung; Singular: die Commit-Beschreibung; Plural: die Commit-Beschreibungen; Alternativ: die Commit-Nachricht |Contributor| -Mitwirkender +Mitwirkender; Beitragender |Diff| Diff; Singular: der Diff; Plural: die Diffs; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung 'Vergleich oder Ausgabe eines Vergleichs' verwendet werden. |============================================================================== @@ -123,6 +125,8 @@ Projektbetreuer betreuen |to merge| mergen; er/sie mergt; wir mergen; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung "zusammenführen oder verschmelzen" verwendet werden. +|Patch| +Änderung oder auch Patch |to pull| pullen; er/sie pullt; wir pullen; Deutsch: übernehmen |Pull Request| diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 44cab806..60d2eac6 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -1,59 +1,61 @@ -=== Maintaining a Project +=== Ein Projekt verwalten (((maintaining a project))) -In addition to knowing how to contribute effectively to a project, you'll likely need to know how to maintain one. -This can consist of accepting and applying patches generated via `format-patch` and emailed to you, or integrating changes in remote branches for repositories you've added as remotes to your project. -Whether you maintain a canonical repository or want to help by verifying or approving patches, you need to know how to accept work in a way that is clearest for other contributors and sustainable by you over the long run. +Sie müssen nicht nur wissen, wie Sie effektiv zu einem Projekt etewas beitragen, sondern auch wissen, wie Sie ein Projekt verwalten. +Sie müssen bspw. wissen wie sie Patches akzeptieren und anwenden, die über `format-patch` generiert und per E-Mail an Sie gesendet wurden. Weiterhin sollten sie wissen wie sie Änderungen in Remote-Branches für Repositorys integrieren, die Sie als Remotes zu Ihrem Projekt hinzugefügt haben. +Unabhängig davon, ob Sie ein zentrales Repository verwalten oder durch Überprüfen oder Genehmigen von Patches helfen möchten, müssen Sie wissen, wie Sie die Arbeit auf eine Weise akzeptieren, die für andere Mitwirkende transparent und auf lange Sicht auch nachhaltig ist. -==== Working in Topic Branches +==== Arbeiten in Themen Branches (((branches, topic))) -When you're thinking of integrating new work, it's generally a good idea to try it out in a _topic branch_ -- a temporary branch specifically made to try out that new work. -This way, it's easy to tweak a patch individually and leave it if it's not working until you have time to come back to it. -If you create a simple branch name based on the theme of the work you're going to try, such as `ruby_client` or something similarly descriptive, you can easily remember it if you have to abandon it for a while and come back later. -The maintainer of the Git project tends to namespace these branches as well -- such as `sc/ruby_client`, where `sc` is short for the person who contributed the work. -As you'll remember, you can create the branch based off your `master` branch like this: +Wenn man vor hat, neuen Quelltext zu integrieren, ist es im Allgemeinen eine gute Idee, sie in einem _Topic Branch_ auszuprobieren - einem temporären Branch, der speziell zum Ausprobieren dieser neuen Änderungen erstellt wurde. +Auf diese Weise ist es einfach, einen Patch einzeln zu optimieren und ihn nicht weiter zu bearbeiten, wenn er nicht funktioniert, bis Sie Zeit haben, sich wieder damit zu befassen. +Sie sollten einen einfachen Branchnamen erstellen, der auf dem Thema der Arbeit basiert, die Sie durchführen, wie z.B. `ruby_client` oder etwas ähnlich sprechendes. Dann können Sie sich später leichter daran erinnern, falls Sie den Branch für eine Weile haben ruhen lassen und später daran weiter arbeiten. +Der Betreuer des Git-Projekts neigt auch dazu, diese Branches mit einem Namespace zu versehen - wie z. B. `sc/ruby_client`, wobei `sc` für die Person steht, die die Arbeit beigesteuert hat. +Wie Sie sich erinnern werden, können Sie den Branch basierend auf Ihrem `master`-Branch wie folgt erstellen: [source,console] ---- $ git branch sc/ruby_client master ---- -Or, if you want to also switch to it immediately, you can use the `checkout -b` option: +Wenn sie anschliessend sofort zum neuen Branch wechseln möchten, können Sie auch die Option `checkout -b` verwenden: [source,console] ---- $ git checkout -b sc/ruby_client master ---- -Now you're ready to add the contributed work that you received into this topic branch and determine if you want to merge it into your longer-term branches. +Jetzt können Sie die eingereichte Arbeit zu diesem Branch hinzufügen und festlegen, ob Sie ihn mit Ihren bestehenden Branches zusammenführen möchten. [[_patches_from_email]] -==== Applying Patches from Email +==== Anwenden von Änderungen aus E-Mails (((email, applying patches from))) -If you receive a patch over email that you need to integrate into your project, you need to apply the patch in your topic branch to evaluate it. -There are two ways to apply an emailed patch: with `git apply` or with `git am`. +Wenn Sie einen Patch per E-Mail erhalten, den Sie in Ihr Projekt integrieren müssen, müssen Sie den Patch in Ihrer Themen Branch anwenden, damit sie ihn prüfen können. +Es gibt zwei Möglichkeiten, einen per E-Mail versendeten Patch anzuwenden: mit `git apply` oder mit` git am`. -===== Applying a Patch with apply +===== Änderungen mit `apply` anwenden (((git commands, apply))) If you received the patch from someone who generated it with `git diff` or some variation of the Unix `diff` command (which is not recommended; see the next section), you can apply it with the `git apply` command. Assuming you saved the patch at `/tmp/patch-ruby-client.patch`, you can apply the patch like this: +Wenn Sie den Patch von jemandem erhalten haben, der ihn mit `git diff` oder mit einer Variante Unix-Befehls` diff` erzeugt hat (was nicht empfohlen wird; siehe nächster Abschnitt), können Sie ihn mit dem Befehl `git apply` anwenden. +Angenommen Sie haben den Patch unter `/tmp/patch-ruby-client.patch` gespeichert. Dann können Sie den Patch folgendermaßen anwenden: [source,console] ---- $ git apply /tmp/patch-ruby-client.patch ---- -This modifies the files in your working directory. -It's almost identical to running a `patch -p1` command to apply the patch, although it's more paranoid and accepts fewer fuzzy matches than patch. -It also handles file adds, deletes, and renames if they're described in the `git diff` format, which `patch` won't do. -Finally, `git apply` is an ``apply all or abort all'' model where either everything is applied or nothing is, whereas `patch` can partially apply patchfiles, leaving your working directory in a weird state. -`git apply` is overall much more conservative than `patch`. -It won't create a commit for you -- after running it, you must stage and commit the changes introduced manually. +Hierdurch werden die Dateien in Ihrem Arbeitsverzeichnis geändert. +Es ist fast identisch mit dem Ausführen eines `patch -p1` Befehls zum Anwenden des Patches, obwohl es paranoider ist und unscharfe Übereinstimmungen selektiver als `patch' akzeptiert. +Damit kann man auch Dateien Hinzufügen, Löschen und Umbenennen, wenn diese im `git diff`-Format beschrieben sind, was mit `patch` nicht möglich ist. +Zu guter letzt ist `git apply` ein ``wende alles oder nichts an''-Modell, bei dem entweder alles oder nichts angewendet wird, wohingegen `patch` Patchdateien teilweise anwenden kann und Ihr Arbeitsverzeichnis in einnm undefinierten Zustand versetzen kann. +`git apply` ist insgesamt sehr viel konservativer als` patch`. +Es wird kein Commit für Sie erstellen. Nach dem Ausführen müssen Sie die eingeführten Änderungen manuell bereitstellen und einchecken. -You can also use `git apply` to see if a patch applies cleanly before you try actually applying it -- you can run `git apply --check` with the patch: +Sie können auch `git apply` verwenden, um zu prüfen, ob ein Patch ordnungsgemäß angewendet wird, bevor Sie versuchen, ihn tatsächlich anzuwenden. Sie können `git apply --check` auf den Patch ausführen: [source,console] ---- @@ -62,20 +64,20 @@ error: patch failed: ticgit.gemspec:1 error: ticgit.gemspec: patch does not apply ---- -If there is no output, then the patch should apply cleanly. -This command also exits with a non-zero status if the check fails, so you can use it in scripts if you want. +Wenn keine Ausgabe erfolgt, sollte der Patch ordnungsgemäß angewendet werden können. +Dieser Befehl wird auch mit einem Rückgabewert ungleich Null beendet, wenn die Prüfung fehlschlägt, sodass Sie ihn bei Bedarf in Skripten verwenden können. [[_git_am]] -===== Applying a Patch with `am` +===== Änderungen mit `am` anwenden (((git commands, am))) -If the contributor is a Git user and was good enough to use the `format-patch` command to generate their patch, then your job is easier because the patch contains author information and a commit message for you. -If you can, encourage your contributors to use `format-patch` instead of `diff` to generate patches for you. -You should only have to use `git apply` for legacy patches and things like that. +Wenn der Beitragende ein Git-Benutzer ist und den Befehl `format-patch` zum Generieren seines Patches verwendet hat, ist Ihre Arbeit einfacher. Der Patch enthält bereits Informationen über dem Autor und eine entsprechende Commitnachricht. +Wenn möglich, ermutigen Sie die Beitragenden `format-patch` anstelle von `diff` zum erstellen von Patches zu verwenden. +Sie sollten `git apply` nur für ältere Patches und ähnliche Dinge verwenden. -To apply a patch generated by `format-patch`, you use `git am` (the command is named `am` as it is used to "apply a series of patches from a mailbox"). -Technically, `git am` is built to read an mbox file, which is a simple, plain-text format for storing one or more email messages in one text file. -It looks something like this: +Um einen von `format-patch` erzeugten Patch anzuwenden, verwenden Sie `git am` (der Befehl heißt `am`, da er verwendet wird, um „eine Reihe von Patches aus einer Mailbox anzuwenden“). +Technisch gesehen ist `git am` so aufgebaut, dass eine mbox-Datei gelesen werden kann. Hierbei handelt es sich um ein einfaches Nur-Text-Format zum Speichern einer oder mehrerer E-Mail-Nachrichten in einer Textdatei. +Das sieht in etwa so aus: [source,console] ---- @@ -87,11 +89,11 @@ Subject: [PATCH 1/2] add limit to log function Limit log functionality to the first 20 ---- -This is the beginning of the output of the `git format-patch` command that you saw in the previous section; it also represents a valid mbox email format. -If someone has emailed you the patch properly using `git send-email`, and you download that into an mbox format, then you can point `git am` to that mbox file, and it will start applying all the patches it sees. -If you run a mail client that can save several emails out in mbox format, you can save entire patch series into a file and then use `git am` to apply them one at a time. +Dies ist der Anfang der Ausgabe des Befehls `git format-patch`, den Sie im vorherigen Abschnitt gesehen haben. Es zeigt ein gültiges mbox Email Format. +Wenn Ihnen jemand den Patch ordnungsgemäß mit `git send-email` per E-Mail zugesendet hat und Sie ihn in ein mbox-Format herunterladen, können Sie `git am` auf diese mbox-Datei auführen und alle angezeigten Patches werden entsprechend angewendet. +Wenn Sie einen Mail-Client ausführen, der mehrere E-Mails im Mbox-Format speichern kann, können Sie ganze Patch-Serien in einer Datei speichern und diese dann mit `git am` einzeln anwenden. -However, if someone uploaded a patch file generated via `git format-patch` to a ticketing system or something similar, you can save the file locally and then pass that file saved on your disk to `git am` to apply it: +Wenn jedoch jemand eine mit `git format-patch` erzeugte Patch-Datei in ein Ticketing-System oder ähnliches hochgeladen hat, können Sie die Datei lokal speichern und diese auf Ihrer Festplatte gespeicherte Datei dann an `git am` übergeben, um sie anzuwenden: [source,console] ---- @@ -103,6 +105,10 @@ You can see that it applied cleanly and automatically created the new commit for The author information is taken from the email's `From` and `Date` headers, and the message of the commit is taken from the `Subject` and body (before the patch) of the email. For example, if this patch was applied from the mbox example above, the commit generated would look something like this: +Sie können sehen, dass es korrekt angewendet und das neue Commit automatisch für Sie erstellt wurde. +Die Autoreninformationen werden aus den Kopfzeilen `From` und `Date` der E-Mail entnommen und die Nachricht des Commits wird aus dem `Subject` und dem Textkörper (vor dem Patch) der E-Mail entnommen. +Wenn dieser Patch beispielsweise aus dem obigen mbox-Beispiel angewendet würde, würde der erzeugte Commit ungefähr so aussehen: + [source,console] ---- $ git log --pretty=fuller -1 @@ -117,12 +123,12 @@ CommitDate: Thu Apr 9 09:19:06 2009 -0700 Limit log functionality to the first 20 ---- -The `Commit` information indicates the person who applied the patch and the time it was applied. -The `Author` information is the individual who originally created the patch and when it was originally created. +Die `Commit`-Informationen gibt die Person an, die den Patch angewendet hat und den Zeitpunkt, wann er angewendet wurde. +Die `Author`-Information gibt die Person an, die den Patch ursprünglich erstellt hat und wann er ursprünglich erstellt wurde. -But it's possible that the patch won't apply cleanly. -Perhaps your main branch has diverged too far from the branch the patch was built from, or the patch depends on another patch you haven't applied yet. -In that case, the `git am` process will fail and ask you what you want to do: +Es besteht jedoch die Möglichkeit, dass der Patch nicht sauber angewendet werden kann. +Möglicherweise ist Ihr Hauptbranch zu weit vom Branch entfernt, von dem aus der Patch erstellt wurde. Oder aber der Patch hängt noch von einem anderen Patch ab, den Sie noch nicht angewendet haben. +In diesem Fall schlägt der Prozess `git am` fehl und Sie werden gefragt, was Sie tun möchten: [source,console] ---- @@ -136,8 +142,8 @@ If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". ---- -This command puts conflict markers in any files it has issues with, much like a conflicted merge or rebase operation. -You solve this issue much the same way -- edit the file to resolve the conflict, stage the new file, and then run `git am --resolved` to continue to the next patch: +Dieser Befehl fügt Konfliktmarkierungen in alle Dateien ein, in denen Probleme auftreten. Ähnlich wie bei einem Konflikt bei der Zusammenführung (engl. merge) bzw. der Reorganisation (engl rebase). +Sie lösen dieses Problem auf die gleiche Weise: Bearbeiten Sie die Datei, um den Konflikt zu lösen. Anschliessend fügen sie die neue Datei der Staging Area hinzu und führen Sie dann `git am --resolved` aus, um mit dem nächsten Patch fortzufahren: [source,console] ---- @@ -147,9 +153,9 @@ $ git am --resolved Applying: seeing if this helps the gem ---- -If you want Git to try a bit more intelligently to resolve the conflict, you can pass a `-3` option to it, which makes Git attempt a three-way merge. -This option isn't on by default because it doesn't work if the commit the patch says it was based on isn't in your repository. -If you do have that commit -- if the patch was based on a public commit -- then the `-3` option is generally much smarter about applying a conflicting patch: +Wenn Sie möchten, dass Git den Konflikt etwas intelligenter löst, können Sie ihm die Option "-3" übergeben, wodurch Git versucht, eine Dreifachzusammenführung durchzuführen. +Diese Option ist standardmäßig nicht aktiviert, da sie nicht funktioniert, wenn sich das Commit, auf dem der Patch basiert, nicht in Ihrem Repository befindet. +Wenn Sie diesen Commit haben - wenn der Patch auf einem öffentlichen Commit basiert -, ist die Option "-3" im Allgemeinen viel intelligenter beim Anwenden eines Patch mit Konflikten: [source,console] ---- @@ -162,10 +168,10 @@ Falling back to patching base and 3-way merge... No changes -- Patch already applied. ---- -In this case, without the `-3` option the patch would have been considered as a conflict. -Since the `-3` option was used the patch applied cleanly. +In diesem Fall wäre der Patch ohne die Option "-3" als Konflikt gewertet worden. +Da die Option "-3" verwendet wurde, wurde der Patch sauber angewendet. -If you're applying a number of patches from an mbox, you can also run the `am` command in interactive mode, which stops at each patch it finds and asks if you want to apply it: +Wenn Sie mehrere Patches von einer mbox aus anwenden, können Sie auch den Befehl `am` im interaktiven Modus ausführen. Bei jedem gefundenen Patch wird angehalten und Sie werden gefragt, ob Sie ihn anwenden möchten: [source,console] ---- @@ -177,9 +183,9 @@ seeing if this helps the gem Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all ---- -This is nice if you have a number of patches saved, because you can view the patch first if you don't remember what it is, or not apply the patch if you've already done so. +Dies ist hilfreich, wenn Sie eine Reihe von Patches gespeichert haben, da Sie den Patch zuerst anzeigen können, wenn Sie sich nicht daran erinnern, worum es genau geht. Oder aber weil sie den Patch nicht anwenden können, weil Sie dies bereits getan haben. -When all the patches for your topic are applied and committed into your branch, you can choose whether and how to integrate them into a longer-running branch. +Wenn alle Patches für Ihr Thema angewendet und in Ihrem Branch festgeschrieben wurden, können Sie auswählen, ob und wie Sie sie in einen Hauptzweig integrieren möchten. [[_checking_out_remotes]] ==== Checking Out Remote Branches From 57fc77bb55e6812298c03b9180f6c16951909821 Mon Sep 17 00:00:00 2001 From: pastatopf Date: Mon, 16 Sep 2019 17:37:31 +0200 Subject: [PATCH 11/14] translated book/05-distributed-git/sections/maintaining.asc to german --- .../sections/maintaining.asc | 281 +++++++++--------- 1 file changed, 143 insertions(+), 138 deletions(-) diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 60d2eac6..7109e37c 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -188,12 +188,12 @@ Dies ist hilfreich, wenn Sie eine Reihe von Patches gespeichert haben, da Sie de Wenn alle Patches für Ihr Thema angewendet und in Ihrem Branch festgeschrieben wurden, können Sie auswählen, ob und wie Sie sie in einen Hauptzweig integrieren möchten. [[_checking_out_remotes]] -==== Checking Out Remote Branches +==== Remote Branches auschecken (((branches, remote))) -If your contribution came from a Git user who set up their own repository, pushed a number of changes into it, and then sent you the URL to the repository and the name of the remote branch the changes are in, you can add them as a remote and do merges locally. +Wenn sie einen Beitrag erhalten, der von einem Git-Benutzer stammt, der sein eigenes Repository eingerichtet, eine Reihe von Änderungen vorgenommen und Ihnen dann die URL zum Repository und den Namen des Remote-Zweigs gesendet hat, in dem sich die Änderungen befinden, können Sie diesen als remote hinzufügen und die Änderungen lokal zusammenführen. -For instance, if Jessica sends you an email saying that she has a great new feature in the `ruby-client` branch of her repository, you can test it by adding the remote and checking out that branch locally: +Wenn Jessica Ihnen beispielsweise eine E-Mail sendet, die besagt, dass sie eine großartige neue Funktion im `ruby-client` Branch ihres Repositorys hat, können Sie diese testen, indem Sie den Branch als remote hinzufügen und ihn lokal auschecken: [source,console] ---- @@ -202,18 +202,18 @@ $ git fetch jessica $ git checkout -b rubyclient jessica/ruby-client ---- -If she emails you again later with another branch containing another great feature, you could directly `fetch` and `checkout` because you already have the remote setup. +Wenn sie Ihnen später erneut eine E-Mail mit einem anderen Branch sendet, der eine weitere großartige Funktion enthält, können Sie diese direkt abrufen und auschecken, da Sie bereits über das Remote Repository verfügen. -This is most useful if you're working with a person consistently. -If someone only has a single patch to contribute once in a while, then accepting it over email may be less time consuming than requiring everyone to run their own server and having to continually add and remove remotes to get a few patches. -You're also unlikely to want to have hundreds of remotes, each for someone who contributes only a patch or two. -However, scripts and hosted services may make this easier -- it depends largely on how you develop and how your contributors develop. +Dies ist am nützlichsten, wenn Sie durchweg mit einer Person arbeiten. +Wenn nur ein Patch von Zeit zu Zeit zur Verfügung steht, ist das Akzeptieren über E-Mail möglicherweise weniger zeitaufwendig, als dass jeder seinen eigenen Server unterhalten und Remotes hinzufügen und entfernen muss, um einige wenige Patches zu erhalten. +Es ist auch unwahrscheinlich, dass Sie Hunderte von Remotes einbinden möchten für Personen, die nur ein oder zwei Patches beisteuern. +Skripte und gehostete Dienste können dies jedoch vereinfachen - dies hängt weitgehend davon ab, wie Sie und die Mitwirkenden sich entwickeln. -The other advantage of this approach is that you get the history of the commits as well. -Although you may have legitimate merge issues, you know where in your history their work is based; a proper three-way merge is the default rather than having to supply a `-3` and hope the patch was generated off a public commit to which you have access. +Der andere Vorteil dieses Ansatzes ist, dass Sie auch die Historie der Commits erhalten. +Obwohl Sie möglicherweise berechtigte Probleme bei der Zusammenführungen haben, wissen Sie, wo in Ihrer Hisorie deren Arbeit basiert. Eine ordnungsgemäße Drei-Wege-Zusammenführung ist die Standardeinstellung, anstatt ein "-3" einzugeben, und sie hoffen, dass der Patch aus einem öffentlichen Commit generiert wurde, auf den Sie Zugriff haben. -If you aren't working with a person consistently but still want to pull from them in this way, you can provide the URL of the remote repository to the `git pull` command. -This does a one-time pull and doesn't save the URL as a remote reference: +Wenn Sie nicht durchgehen mit einer Person arbeiten, aber dennoch auf diese Weise von dieser Person abrufen möchten, können Sie die URL des Remote-Repositorys für den Befehl `git pull` angeben. +Dies führt einen einmaligen Abruf durch und speichert die URL nicht als Remote-Referenz: [source,console] ---- @@ -224,17 +224,17 @@ Merge made by the 'recursive' strategy. ---- [[_what_is_introduced]] -==== Determining What Is Introduced +==== Bestimmen, was eingeführt wird (((branches, diffing))) -Now you have a topic branch that contains contributed work. -At this point, you can determine what you'd like to do with it. -This section revisits a couple of commands so you can see how you can use them to review exactly what you'll be introducing if you merge this into your main branch. +Jetzt haben Sie einen Themen Branch mit neuen Beiträgen. +An dieser Stelle können Sie festlegen, was Sie damit machen möchten. +In diesem Abschnitt werden einige Befehle noch einmal behandelt, damit Sie sehen können, wie Sie sie verwenden können. So können sie genau überprüfen, was Sie einführen, wenn Sie die Beiträge in Ihrem Haupt Branch zusammenführen. -It's often helpful to get a review of all the commits that are in this branch but that aren't in your master branch. -You can exclude commits in the master branch by adding the `--not` option before the branch name. -This does the same thing as the `master..contrib` format that we used earlier. -For example, if your contributor sends you two patches and you create a branch called `contrib` and applied those patches there, you can run this: +Es ist oft hilfreich, eine Übersicht über alle Commits zu erhalten, die sich in diesem Branch jedoch nicht in Ihrem Master-Branch befinden. +Sie können Commits im Master-Branch ausschließen, indem Sie die Option "--not" vor dem Branchnamen hinzufügen. +Dies entspricht dem Format `master..contrib`, das wir zuvor verwendet haben. +Wenn Ihr Mitarbeiter Ihnen beispielsweise zwei Patches sendet und Sie einen Branch mit dem Namen `contrib` erstellen und diese Patches dort anwenden, können Sie Folgendes ausführen: [source,console] ---- @@ -252,27 +252,27 @@ Date: Mon Oct 22 19:38:36 2008 -0700 updated the gemspec to hopefully work better ---- -To see what changes each commit introduces, remember that you can pass the `-p` option to `git log` and it will append the diff introduced to each commit. +Denken Sie daran, dass Sie die Option `-p` an `git log` übergeben können, um zu sehen, welche Änderungen jeder Commit einführt, und den Diff an jeden Commit anfügt. -To see a full diff of what would happen if you were to merge this topic branch with another branch, you may have to use a weird trick to get the correct results. -You may think to run this: +Um einen vollständigen Überblick darüber zu erhalten, was passieren würde, wenn Sie diesen Branch mit einem anderen Branch zusammenführen würden, müssen Sie möglicherweise einen ungeröhnlichen Kniff anwenden, um die richtigen Ergebnisse zu erzielen. +Eventuell denken sie daran folgendes auszuführen: [source,console] ---- $ git diff master ---- -This command gives you a diff, but it may be misleading. -If your `master` branch has moved forward since you created the topic branch from it, then you'll get seemingly strange results. -This happens because Git directly compares the snapshots of the last commit of the topic branch you're on and the snapshot of the last commit on the `master` branch. -For example, if you've added a line in a file on the `master` branch, a direct comparison of the snapshots will look like the topic branch is going to remove that line. +Dieser Befehl gibt Ihnen den Unterschied zurück, jedoch kann dies irreführend sein. +Wenn Ihr Master-Branch vorgerückt ist, seit Sie den Themen-Branch daraus erstellt haben, erhalten Sie scheinbar unerwartete Ergebnisse. +Dies geschieht, weil Git den Snapshots des letzten Commits des Branches, in dem Sie sich befinden, und den Snapshot des letzten Commits des Branches `master` direkt miteinander vergleicht. +Wenn Sie beispielsweise eine Zeile in eine Datei im Branch `master` eingefügt haben, sieht ein direkter Vergleich der Snapshots so aus, als würde der Themen Branch diese Zeile entfernen. -If `master` is a direct ancestor of your topic branch, this isn't a problem; but if the two histories have diverged, the diff will look like you're adding all the new stuff in your topic branch and removing everything unique to the `master` branch. +Wenn `master` ein direkter Vorgänger Ihres Themen Branches ist, ist dies kein Problem. Wenn die beiden Historien jedoch voneinander abweichen, sieht es so aus, als würden Sie alle neuen Inhalte in Ihrem Themen Branch hinzufügen und alles entfernen, was für den `master` Branch eindeutig ist. -What you really want to see are the changes added to the topic branch -- the work you'll introduce if you merge this branch with master. -You do that by having Git compare the last commit on your topic branch with the first common ancestor it has with the master branch. +Was Sie wirklich sehen möchten, sind die Änderungen, die dem Themen Branch hinzugefügt wurden - die Arbeit, die Sie hinzufügen, wenn Sie den neuen Branch mit `master` zusammenführen. +Sie tun dies, indem Git das letzte Commit in Ihrem Themen Branch mit dem ersten gemeinsamen Vorgänger vom `master` Branch vergleicht. -Technically, you can do that by explicitly figuring out the common ancestor and then running your diff on it: +Technisch gesehen können Sie dies tun, indem Sie den gemeinsamen Vorgänger explizit herausfinden und dann Ihr `diff` darauf ausführen: [source,console] ---- @@ -281,116 +281,121 @@ $ git merge-base contrib master $ git diff 36c7db ---- -or, more concisely: +oder kurzgefasst: [source,console] ---- $ git diff $(git merge-base contrib master) ---- -However, neither of those is particularly convenient, so Git provides another shorthand for doing the same thing: the triple-dot syntax. -In the context of the `git diff` command, you can put three periods after another branch to do a `diff` between the last commit of the branch you're on and its common ancestor with another branch: +Beides ist jedoch nicht besonders praktisch, weshalb Git eine andere Weg für diesen Vorgang bietet: die Drei-Punkt-Syntax (engl. Triple-Dot-Syntax). +Im Kontext des Befehls `git diff` können Sie drei Punkte nach einem anderen Branch einfügen, um ein `diff` zwischen dem letzten Commit ihres aktullen Branchs, in dem Sie sich befinden, und dem gemeinsamen Vorgänger eines anderen Branches zu erstellen: [source,console] ---- $ git diff master...contrib ---- -This command shows you only the work your current topic branch has introduced since its common ancestor with master. -That is a very useful syntax to remember. +Dieser Befehl zeigt Ihnen nur die Arbeit an, die Ihr aktueller Branch seit seinem gemeinsamen Vorgänger mit master eingeführt hat. +Dies ist eine sehr nützliche Syntax, die sie sich merken sollten. -==== Integrating Contributed Work +==== Beiträge integrieren (((integrating work))) -When all the work in your topic branch is ready to be integrated into a more mainline branch, the question is how to do it. -Furthermore, what overall workflow do you want to use to maintain your project? -You have a number of choices, so we'll cover a few of them. +Wenn alle Arbeiten in Ihrem Themen Branch bereit sind, um in ein größeren Hauptbranch integriert zu werden, lautet die Frage, wie Sie dies tun können. +Welchen Workflow möchten Sie verwenden, um Ihr Projekt zu verwalten? +Sie haben eine Reihe von Möglichkeiten, daher werden wir einige davon behandeln. -===== Merging Workflows +===== Workflows zusammenführen (engl. mergen) (((workflows, merging))) -One basic workflow is to simply merge all that work directly into your `master` branch. -In this scenario, you have a `master` branch that contains basically stable code. -When you have work in a topic branch that you think you've completed, or work that someone else has contributed and you've verified, you merge it into your master branch, delete that just-merged topic branch, and repeat. +Ein grundlegender Workflow besteht darin, all diese Arbeiten einfach direkt in Ihrem `master`Branch zusammenzuführen. +In diesem Szenario haben Sie einen `master`-Branch, der stabilen Code enthält. +Wenn Sie in einem Branch arbeiten, von dem Sie glauben, dass Sie ihn abgeschlossen haben, oder von jemand anderem beigesteuert und überprüft haben, führen Sie ihn in Ihrem Hauptbranch zusammen. Löschen sie anschliessend diesen gerade zusammengeführten Branch und wiederholen diesen Vorgang bei Bedarf. -For instance, if we have a repository with work in two branches named `ruby_client` and `php_client` that looks like <>, and we merge `ruby_client` followed by `php_client`, your history will end up looking like <>. +Wenn wir zum Beispiel ein Repository mit zwei Branches namens `ruby_client` und `php_client` haben, die wie <> aussehen, und wir `ruby_client` gefolgt von `php_client` zusammenführen, sieht Ihr Verlauf wie <> aus. [[merwf_a]] -.History with several topic branches. -image::images/merging-workflows-1.png[History with several topic branches.] +.Historie mit meheren Topic Branches. +image::images/merging-workflows-1.png[Historie mit meheren Topic Branches.] [[merwf_b]] -.After a topic branch merge. -image::images/merging-workflows-2.png[After a topic branch merge.] +.Status nach einem Themen Branch Merge. +image::images/merging-workflows-2.png[Status nach einem Themen Branch Merge.] -That is probably the simplest workflow, but it can possibly be problematic if you're dealing with larger or more stable projects where you want to be really careful about what you introduce. +Das ist wahrscheinlich der einfachste Workflow. Es kann jedoch zu Problemen können, wenn Sie größere oder stabilere Projekte bearbeiten. Sie müssen bei der Einführung von Änderungen sehr vorsichtig sein. -If you have a more important project, you might want to use a two-phase merge cycle. -In this scenario, you have two long-running branches, `master` and `develop`, in which you determine that `master` is updated only when a very stable release is cut and all new code is integrated into the `develop` branch. -You regularly push both of these branches to the public repository. -Each time you have a new topic branch to merge in (<>), you merge it into `develop` (<>); then, when you tag a release, you fast-forward `master` to wherever the now-stable `develop` branch is (<>). +Wenn Sie ein wichtigeres Projekt haben, möchten Sie möglicherweise einen zweistufigen Merge Prozess verwenden. +In diesem Szenario haben Sie zwei lange laufende Branches namens `master` und `develop`. Sie legen fest, dass `master` nur dann aktualisiert wird, wenn eine sehr stabile Version vorhanden ist und der gesamte neue Code in den Branch `develop` integriert wird. +Sie pushen diese beiden Branches regelmäßig in das öffentliche Repository. +Jedes Mal, wenn Sie einen neuen Branch zum Zusammenführen haben (<>), führen Sie ihn in `develop` (<< merwf_d >>) zusammen. Wenn Sie ein Release mit einem Tag versehen, spulen Sie `master` an die Stelle weiter, an der sich der jetzt stabile `develop`-Branch befindet (<>). [[merwf_c]] -.Before a topic branch merge. -image::images/merging-workflows-3.png[Before a topic branch merge.] +.Vor einem Themen Branch Merge. +image::images/merging-workflows-3.png[Vor einem Themen Branch Merge.] [[merwf_d]] -.After a topic branch merge. -image::images/merging-workflows-4.png[After a topic branch merge.] +.Nach einem Themen Branch Merge. +image::images/merging-workflows-4.png[Nach einem Themen Branch Merge.] [[merwf_e]] -.After a project release. -image::images/merging-workflows-5.png[After a topic branch release.] +.Nach einem Projekt Release. +image::images/merging-workflows-5.png[Nach einem Projekt Release.] -This way, when people clone your project's repository, they can either check out `master` to build the latest stable version and keep up to date on that easily, or they can check out `develop`, which is the more cutting-edge content. -You can also extend this concept by having an `integrate` branch where all the work is merged together. -Then, when the codebase on that branch is stable and passes tests, you merge it into a `develop` branch; and when that has proven itself stable for a while, you fast-forward your `master` branch. +Auf diese Weise können Benutzer, die das Repository Ihres Projekts klonen, entweder `master` oder `develop` auschecken. Mit `master` können sie die neueste stabile Version erstellen und somit recht einfache auf dem neuesten Stand bleiben. Oder sie können `develop` auschecken, welchen den aktuellsten Inhalt darstellt. +Sie können dieses Konzept auch erweitern, indem Sie einen `integrate`-Branch einrichten, in dem alle Arbeiten zusammengeführt werden. +Wenn die Codebasis auf diesem Branch stabil ist und die Tests erfolgreich sind, können Sie sie zu einem Entwicklungsbranch zusammen führen. Wenn sich das als stabil erwiesen hat, können sie ihren `master`-Branch fast-forwarden. -===== Large-Merging Workflows +===== Workflows mit umfangreichen Merges (((workflows, "merging (large)"))) -The Git project has four long-running branches: `master`, `next`, and `pu` (proposed updates) for new work, and `maint` for maintenance backports. -When new work is introduced by contributors, it's collected into topic branches in the maintainer's repository in a manner similar to what we've described (see <>). -At this point, the topics are evaluated to determine whether they're safe and ready for consumption or whether they need more work. -If they're safe, they're merged into `next`, and that branch is pushed up so everyone can try the topics integrated together. +Das Git-Projekt hat vier lange laufende Branches: `master`, `next` und `pu` (vorgeschlagene Updates) für neue Arbeiten und `maint` für Wartungs-Backports. +Wenn neue Arbeiten von Mitwirkenden eingereicht werden, werden sie in ähnlicher Weise wie oben beschrieben in Themenbranches im Projektarchiv des Betreuers gesammelt (siehe <>). +Zu diesem Zeitpunkt werden die Themen evaluiert, um festzustellen, ob sie korrekt sind und zur Weiterverarbeitung bereit sind oder ob sie Nacharbeit benötigen. +Wenn sie korrekt sind, werden sie zu `next` zusammengeführt, und dieser Branch wird gepushed, damit jeder die miteinander integrierten Themen testen kann. [[merwf_f]] -.Managing a complex series of parallel contributed topic branches. -image::images/large-merges-1.png[Managing a complex series of parallel contributed topic branches.] +.Verwaltung einer komplexen Reihe paralleler Themenbranches. +image::images/large-merges-1.png[Verwaltung einer komplexen Reihe paralleler Themenbranches.] If the topics still need work, they're merged into `pu` instead. When it's determined that they're totally stable, the topics are re-merged into `master`. The `next` and `pu` branches are then rebuilt from the `master`. This means `master` almost always moves forward, `next` is rebased occasionally, and `pu` is rebased even more often: -.Merging contributed topic branches into long-term integration branches. -image::images/large-merges-2.png[Merging contributed topic branches into long-term integration branches.] +Wenn die Themen noch bearbeitet werden müssen, werden sie in `pu` gemerged. +Wenn festgestellt wird, dass sie absolut stabil sind, werden die Themen wieder zu `master` zusammengeführt. +Die Branches `next` und `pu` werden dann vom `master` neu aufgebaut. +Dies bedeutet, dass `master` fast immer vorwärts geht, `next` wird gelegentlich neu rebased und `pu` noch häufiger rebased wird: -When a topic branch has finally been merged into `master`, it's removed from the repository. -The Git project also has a `maint` branch that is forked off from the last release to provide backported patches in case a maintenance release is required. -Thus, when you clone the Git repository, you have four branches that you can check out to evaluate the project in different stages of development, depending on how cutting edge you want to be or how you want to contribute; and the maintainer has a structured workflow to help them vet new contributions. -The Git project's workflow is specialized. -To clearly understand this you could check out the https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt[Git Maintainer's guide]. +.Zusammenführen von Themen Branches in langfristige Integrationsbranches. +image::images/large-merges-2.png[Zusammenführen von Themen Branches in langfristige Integrationsbranches.] + +Wenn ein Branch schließlich zu `master` zusammengeführt wurde, wird er aus dem Repository entfernt. +Das Git-Projekt hat auch einen `maint`-Branch, der von der letzten Version geforkt wurde, um für den Fall, dass eine Wartungsversion erforderlich ist, Backport-Patches bereitzustellen. +Wenn Sie das Git-Repository klonen, stehen Ihnen vier Branches zur Verfügung, mit denen Sie das Projekt in verschiedenen Entwicklungsstadien bewerten können, je nachdem, wie aktuell Sie sein möchten oder wie Sie einen Beitrag leisten möchten. Der Betreuer verfügt über einen strukturierten Workflow, der ihm hilft, neue Beiträge zu überprüfen. +Der Workflow des Git-Projekts ist sehr speziell. +Um dies klar zu verstehen, können Sie das https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt[Git Maintainer's guide] lesen. [[_rebase_cherry_pick]] -===== Rebasing and Cherry-Picking Workflows +===== Rebasing und Cherry-Picking Workflows (((workflows, rebasing and cherry-picking))) -Other maintainers prefer to rebase or cherry-pick contributed work on top of their master branch, rather than merging it in, to keep a mostly linear history. -When you have work in a topic branch and have determined that you want to integrate it, you move to that branch and run the rebase command to rebuild the changes on top of your current master (or `develop`, and so on) branch. -If that works well, you can fast-forward your `master` branch, and you'll end up with a linear project history. +Andere Betreuer bevorzugen es, die Arbeit auf ihrem Masterbranch zu rebasen oder zu cherry-picken, anstatt sie zusammenzuführen, um einen linearen Verlauf beizubehalten. +Wenn Sie in einem Themen Branch arbeiten und sich dazu entschlossen haben, ihn zu integrieren, wechseln Sie in diesen Branch und führen den `rebase`Befehl aus. Damit stellen sie die , um die Änderungen auf Ihrem aktuellen `master` (oder `develop`-Branch usw.) wiederherzustellen. +Wenn das gut funktioniert, können Sie Ihren `master`-Branch fast-forwarden, und Sie erhalten eine lineare Projekthistorie. (((git commands, cherry-pick))) -The other way to move introduced work from one branch to another is to cherry-pick it. -A cherry-pick in Git is like a rebase for a single commit. -It takes the patch that was introduced in a commit and tries to reapply it on the branch you're currently on. -This is useful if you have a number of commits on a topic branch and you want to integrate only one of them, or if you only have one commit on a topic branch and you'd prefer to cherry-pick it rather than run rebase. -For example, suppose you have a project that looks like this: +Die andere Möglichkeit, die eingeführte Arbeit von einem Branch in einen anderen zu verschieben, besteht darin, sie zu cherry-picken. +Ein Cherry-Pick in Git ist wie ein Rebase für ein einzelnes Commit. +Es verwendet den Patch, der in einem Commit eingeführt wurde, und versucht, ihn erneut auf den Branch anzuwenden, auf dem Sie sich gerade befinden. +Dies ist nützlich, wenn Sie eine Reihe von Commits für einen Branch haben und nur eine davon integrieren möchten, oder wenn Sie nur einen Commit für einen Branch haben und Sie es vorziehen, diese zu cherry-picken, anstatt ein Rebase auszuführen. +Angenommen, Sie haben ein Projekt, das folgendermaßen aussieht: -.Example history before a cherry-pick. -image::images/rebasing-1.png[Example history before a cherry-pick.] +.Beispiel Historie vor einem Cherry-Pick. +image::images/rebasing-1.png[Beispiel Historie vor einem Cherry-Pick.] -If you want to pull commit `e43a6` into your master branch, you can run +Wenn Sie das Commit "e43a6" in Ihren Master-Branch ziehen möchten, können Sie folgendes ausführen: [source,console] ---- @@ -400,44 +405,44 @@ Finished one cherry-pick. 3 files changed, 17 insertions(+), 3 deletions(-) ---- -This pulls the same change introduced in `e43a6`, but you get a new commit SHA-1 value, because the date applied is different. -Now your history looks like this: +Dies zieht die gleiche Änderung nach sich, die in `e43a6` eingeführt wurde. Sie erhalten jedoch einen neuen Commit SHA-1-Wert, da das angewendete Datum unterschiedlich ist. +Nun sieht die Historie so aus: -.History after cherry-picking a commit on a topic branch. -image::images/rebasing-2.png[History after cherry-picking a commit on a topic branch.] +.Historie nach Cherry-Picken eines Commits auf einen Themen Branch. +image::images/rebasing-2.png[Historie nach Cherry-Picken eines Commits auf einen Themen Branch.] -Now you can remove your topic branch and drop the commits you didn't want to pull in. +Jetzt können Sie Ihren Themen Branch entfernen und die Commits löschen, die Sie nicht mehr benötigen. ===== Rerere (((git commands, rerere)))(((rerere))) -If you're doing lots of merging and rebasing, or you're maintaining a long-lived topic branch, Git has a feature called ``rerere'' that can help. +Wenn Sie viel mergen und rebasen oder einen langlebigen Themenbranch pflegen, hat Git eine Funktion namens ``rerere'', die helfen kann. -Rerere stands for ``reuse recorded resolution'' -- it's a way of shortcutting manual conflict resolution. -When rerere is enabled, Git will keep a set of pre- and post-images from successful merges, and if it notices that there's a conflict that looks exactly like one you've already fixed, it'll just use the fix from last time, without bothering you with it. +Rerere steht für ``reuse recorded resolution'' (deutsch ``Aufgezeichnete Lösung wiederverwenden'') - es ist eine Möglichkeit, die manuelle Konfliktlösung zu verkürzen. +Wenn rerere aktiviert ist, behält Git eine Reihe von Pre- und Post-Images von erfolgreichen Commits bei. Wenn es feststellt, dass ein Konflikt genau so aussieht, wie der, den Sie bereits behoben haben, wird nur die Korrektur vom letzten Mal verwendet , ohne nochmal zu belästigen. -This feature comes in two parts: a configuration setting and a command. -The configuration setting is `rerere.enabled`, and it's handy enough to put in your global config: +Diese Funktion besteht aus zwei Teilen: einer Konfigurationseinstellung und einem Befehl. +Die Konfigurationseinstellung lautet `rerere.enabled`. Man kann sie in die globale Konfiguration eingeben: [source,console] ---- $ git config --global rerere.enabled true ---- -Now, whenever you do a merge that resolves conflicts, the resolution will be recorded in the cache in case you need it in the future. +Wenn Sie nun einen merge durchführen, der die Konflikte auflöst, wird diese Auflösung im Cache gespeichert, falls Sie sie in Zukunft benötigen. -If you need to, you can interact with the rerere cache using the `git rerere` command. -When it's invoked alone, Git checks its database of resolutions and tries to find a match with any current merge conflicts and resolve them (although this is done automatically if `rerere.enabled` is set to `true`). -There are also subcommands to see what will be recorded, to erase specific resolution from the cache, and to clear the entire cache. -We will cover rerere in more detail in <>. +Bei Bedarf können Sie mit dem Cache interagieren mittels dem Befehl `git rerere`. +Wenn es aufgerufen wird, überprüft Git seine Lösungsdatenbank und versucht eine Übereinstimmung mit aktuellen Mergekonflikten zu finden und diese zu lösen (dies geschieht jedoch automatisch, wenn `rerere.enabled` auf` true` gesetzt ist). +Es gibt auch Unterbefehle, um zu sehen, was aufgezeichnet wird, um eine bestimmte Konfliktlösung aus dem Cache zu löschen oder um den gesamten Cache zu löschen. +Wir werden uns in <> eingehender mit rerere beschäftigen. [[_tagging_releases]] -==== Tagging Your Releases +==== Tagging ihres Releases (((tags)))(((tags, signing))) -When you've decided to cut a release, you'll probably want to assign a tag so you can re-create that release at any point going forward. -You can create a new tag as discussed in <>. -If you decide to sign the tag as the maintainer, the tagging may look something like this: +Wenn Sie sich entschieden haben, ein Release zu erstellen, dann möchten Sie wahrscheinlich einen Tag zuweisen, damit Sie dieses Release in Zukunft jederzeit neu erstellen können. +Sie können einen neuen Tag erstellen, wie in <> beschrieben. +Wenn Sie den Tag als Betreuer signieren möchten, sieht der Tag möglicherweise folgendermaßen aus: [source,console] ---- @@ -447,9 +452,9 @@ user: "Scott Chacon " 1024-bit DSA key, ID F721C45A, created 2009-02-09 ---- -If you do sign your tags, you may have the problem of distributing the public PGP key used to sign your tags. -The maintainer of the Git project has solved this issue by including their public key as a blob in the repository and then adding a tag that points directly to that content. -To do this, you can figure out which key you want by running `gpg --list-keys`: +Wenn Sie Ihre Tags signieren, haben Sie möglicherweise das Problem, den öffentlichen PGP-Schlüssel zu verteilen, der zum Signieren Ihrer Tags verwendet wird. +Der Betreuer des Git-Projekts hat dieses Problem behoben, indem er seinen öffentlichen Schlüssel als Blob in das Repository aufgenommen und anschließend ein enTag hinzugefügt hat, der direkt auf diesen Inhalt verweist. +Um dies zu tun, können Sie herausfinden, welchen Schlüssel Sie möchten, indem Sie `gpg --list-keys` ausführen: [source,console] ---- @@ -461,7 +466,7 @@ uid Scott Chacon sub 2048g/45D02282 2009-02-09 [expires: 2010-02-09] ---- -Then, you can directly import the key into the Git database by exporting it and piping that through `git hash-object`, which writes a new blob with those contents into Git and gives you back the SHA-1 of the blob: +Anschließend können Sie den Schlüssel direkt in die Git-Datenbank importieren, indem Sie ihn exportieren und diesen über `git hash-object` weiterleiten. Dadurch wird ein neuer Blob mit diesen Inhalten in Git geschrieben und Sie erhalten den SHA-1 des Blobs zurück: [source,console] ---- @@ -469,30 +474,30 @@ $ gpg -a --export F721C45A | git hash-object -w --stdin 659ef797d181633c87ec71ac3f9ba29fe5775b92 ---- -Now that you have the contents of your key in Git, you can create a tag that points directly to it by specifying the new SHA-1 value that the `hash-object` command gave you: +Nachdem Sie nun den Inhalt Ihres Schlüssels in Git haben, können Sie einen Tag erstellen, der direkt darauf verweist, indem Sie den neuen SHA-1-Wert angeben, den Sie mit dem Befehl `hash-object` erhalten haben: [source,console] ---- $ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92 ---- -If you run `git push --tags`, the `maintainer-pgp-pub` tag will be shared with everyone. -If anyone wants to verify a tag, they can directly import your PGP key by pulling the blob directly out of the database and importing it into GPG: +Wenn Sie `git push --tags` ausführen, wird der `maintainer-pgp-pub`-Tag für alle freigegeben. +Wenn jemand einen Tag verifizieren möchte, kann er Ihren PGP-Schlüssel direkt importieren, indem er den Blob direkt aus der Datenbank zieht und in GPG importiert: [source,console] ---- $ git show maintainer-pgp-pub | gpg --import ---- -They can use that key to verify all your signed tags. -Also, if you include instructions in the tag message, running `git show ` will let you give the end user more specific instructions about tag verification. +Mit diesem Schlüssel können sie alle Ihre signierten Tags überprüfen. +Wenn Sie der Tag-Nachricht Anweisungen hinzufügen, können Sie dem Endbenutzer mit `git show ` genauere Anweisungen zur Tag-Überprüfung geben. [[_build_number]] -==== Generating a Build Number +==== Eine Build Nummer generieren (((build numbers)))(((git commands, describe))) -Because Git doesn't have monotonically increasing numbers like 'v123' or the equivalent to go with each commit, if you want to have a human-readable name to go with a commit, you can run `git describe` on that commit. -In response, Git generates a string consisting of the name of the most recent tag earlier than that commit, followed by the number of commits since that tag, followed finally by a partial SHA-1 value of the commit being described (prefixed with the letter "g" meaning Git): +Da Git nicht über ansteigende Zahlen wie 'v123' oder das Äquivalent für jedes Commit verfügt, können Sie für dieses Commit den Befehl `git describe` ausführen, wenn Sie einen lesbaren Namen für einen Commit benötigen. +Als Antwort generiert Git eine Zeichenfolge, die aus dem Namen des jüngsten Tags vor diesem Commit besteht, gefolgt von der Anzahl der Commits seit diesem Tag, gefolgt von einem partiellen SHA-1-Wert des beschriebene Commits (vorangestelltem wird dem Buchstaben "g" für Git): [source,console] ---- @@ -500,21 +505,21 @@ $ git describe master v1.6.2-rc1-20-g8c5b85c ---- -This way, you can export a snapshot or build and name it something understandable to people. -In fact, if you build Git from source code cloned from the Git repository, `git --version` gives you something that looks like this. -If you're describing a commit that you have directly tagged, it gives you simply the tag name. +Auf diese Weise können Sie einen Snaphot exportieren oder einen Build erstellen und einen verständlichen Namen vergeben. +Wenn Sie Git aus den Quellcode erstellen, der aus dem Git-Repository geklont wurde, erhalten Sie mit `git --version` etwas, das genau so aussieht. +Wenn Sie einen Commit beschreiben, den Sie direkt getaggt haben, erhalten Sie einfach den Tag-Namen. -By default, the `git describe` command requires annotated tags (tags created with the `-a` or `-s` flag); if you want to take advantage of lightweight (non-annotated) tags as well, add the `--tags` option to the command. -You can also use this string as the target of a `git checkout` or `git show` command, although it relies on the abbreviated SHA-1 value at the end, so it may not be valid forever. -For instance, the Linux kernel recently jumped from 8 to 10 characters to ensure SHA-1 object uniqueness, so older `git describe` output names were invalidated. +Standardmäßig erfordert der Befehl `git describe` mit Anmerkungen versehene Tags (Tags, die mit dem Flag `-a` oder `-s` erstellt wurden). Wenn Sie auch leichte (nicht mit Anmerkungen versehene) Tags verwenden möchten, fügen Sie dem Befehl die Option `--tags` hinzu. +Sie können diese Zeichenfolge auch als Ziel der Befehle `git checkout` oder `git show` verwenden, obwohl sie auf dem abgekürzten SHA-1-Wert am Ende basiert, sodass sie möglicherweise nicht für immer gültig ist. +Zum Beispiel hat der Linux-Kernel kürzlich einen Sprung von 8 auf 10 Zeichen gemacht, um die Eindeutigkeit von SHA-1-Objekten zu gewährleisten, sodass ältere Ausgabenamen von `git describe` ungültig wurden. [[_preparing_release]] -==== Preparing a Release +==== Ein Release vorbereiten (((releasing)))(((git commands, archive))) -Now you want to release a build. -One of the things you'll want to do is create an archive of the latest snapshot of your code for those poor souls who don't use Git. -The command to do this is `git archive`: +Nun möchten Sie einen Build freigeben. +Eines der Dinge, die Sie tun möchten, ist, ein Archiv des neuesten Schnappschusses Ihres Codes für die armen Seelen zu erstellen, die Git nicht verwenden. +Der Befehl dazu lautet `git archive`: [source,console] ---- @@ -523,23 +528,23 @@ $ ls *.tar.gz v1.6.2-rc1-20-g8c5b85c.tar.gz ---- -If someone opens that tarball, they get the latest snapshot of your project under a project directory. -You can also create a zip archive in much the same way, but by passing the `--format=zip` option to `git archive`: +Wenn jemand dieses Archiv öffnet, erhält er den neuesten Schnappschuss Ihres Projekts in einem Projektverzeichnis. +Sie können ein zip-Archiv auch auf die gleiche Weise erstellen, indem Sie jedoch die Option `--format=zip` an `git archive` übergeben: [source,console] ---- $ git archive master --prefix='project/' --format=zip > `git describe master`.zip ---- -You now have a nice tarball and a zip archive of your project release that you can upload to your website or email to people. +Sie haben jetzt einen schönen Tarball und ein Zip-Archiv Ihrer Projektversion, die Sie auf Ihre Website hochladen oder per E-Mail an andere Personen senden können. [[_the_shortlog]] -==== The Shortlog +==== Das Shortlog (((git commands, shortlog))) -It's time to email your mailing list of people who want to know what's happening in your project. -A nice way of quickly getting a sort of changelog of what has been added to your project since your last release or email is to use the `git shortlog` command. -It summarizes all the commits in the range you give it; for example, the following gives you a summary of all the commits since your last release, if your last release was named v1.0.1: +Es ist Zeit, eine E-Mail an die Personen Ihre Mailingliste zu senden, die wissen möchten, was in Ihrem Projekt vor sich geht. +Mit dem Befehl `git shortlog` können Sie schnell eine Art Änderungsprotokoll dessen abrufen, was Ihrem Projekt seit Ihrer letzten Veröffentlichung oder E-Mail hinzugefügt wurde. +Es fasst alle Commits in dem von Ihnen angegebenen Bereich zusammen. Im Folgenden finden Sie als Beispiel 0eine Zusammenfassung aller Commits seit Ihrer letzten Veröffentlichung, sofern Ihre letzte Veröffentlichung den Namen v1.0.1 hat: [source,console] ---- @@ -559,4 +564,4 @@ Tom Preston-Werner (4): Regenerated gemspec for version 1.0.2 ---- -You get a clean summary of all the commits since v1.0.1, grouped by author, that you can email to your list. +Sie erhalten eine übersichtliche Zusammenfassung aller Commits seit Version 1.0.1, gruppiert nach Autoren, die Sie per E-Mail an Ihre Mailingliste senden können. From 45a61cf43449c078a20310c5385834ea6f81b2b1 Mon Sep 17 00:00:00 2001 From: pastatopf Date: Mon, 16 Sep 2019 17:52:56 +0200 Subject: [PATCH 12/14] Deleted some english text which was still in the tranlsation --- book/05-distributed-git/sections/maintaining.asc | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 7109e37c..865127a4 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -38,7 +38,6 @@ Es gibt zwei Möglichkeiten, einen per E-Mail versendeten Patch anzuwenden: mit ===== Änderungen mit `apply` anwenden (((git commands, apply))) -If you received the patch from someone who generated it with `git diff` or some variation of the Unix `diff` command (which is not recommended; see the next section), you can apply it with the `git apply` command. Assuming you saved the patch at `/tmp/patch-ruby-client.patch`, you can apply the patch like this: Wenn Sie den Patch von jemandem erhalten haben, der ihn mit `git diff` oder mit einer Variante Unix-Befehls` diff` erzeugt hat (was nicht empfohlen wird; siehe nächster Abschnitt), können Sie ihn mit dem Befehl `git apply` anwenden. Angenommen Sie haben den Patch unter `/tmp/patch-ruby-client.patch` gespeichert. Dann können Sie den Patch folgendermaßen anwenden: @@ -101,10 +100,6 @@ $ git am 0001-limit-log-function.patch Applying: add limit to log function ---- -You can see that it applied cleanly and automatically created the new commit for you. -The author information is taken from the email's `From` and `Date` headers, and the message of the commit is taken from the `Subject` and body (before the patch) of the email. -For example, if this patch was applied from the mbox example above, the commit generated would look something like this: - Sie können sehen, dass es korrekt angewendet und das neue Commit automatisch für Sie erstellt wurde. Die Autoreninformationen werden aus den Kopfzeilen `From` und `Date` der E-Mail entnommen und die Nachricht des Commits wird aus dem `Subject` und dem Textkörper (vor dem Patch) der E-Mail entnommen. Wenn dieser Patch beispielsweise aus dem obigen mbox-Beispiel angewendet würde, würde der erzeugte Commit ungefähr so aussehen: @@ -358,11 +353,6 @@ Wenn sie korrekt sind, werden sie zu `next` zusammengeführt, und dieser Branch .Verwaltung einer komplexen Reihe paralleler Themenbranches. image::images/large-merges-1.png[Verwaltung einer komplexen Reihe paralleler Themenbranches.] -If the topics still need work, they're merged into `pu` instead. -When it's determined that they're totally stable, the topics are re-merged into `master`. -The `next` and `pu` branches are then rebuilt from the `master`. -This means `master` almost always moves forward, `next` is rebased occasionally, and `pu` is rebased even more often: - Wenn die Themen noch bearbeitet werden müssen, werden sie in `pu` gemerged. Wenn festgestellt wird, dass sie absolut stabil sind, werden die Themen wieder zu `master` zusammengeführt. Die Branches `next` und `pu` werden dann vom `master` neu aufgebaut. From ca4f09dd92f92965a766789c38985298f63d5f5d Mon Sep 17 00:00:00 2001 From: pastatopf Date: Mon, 16 Sep 2019 17:54:48 +0200 Subject: [PATCH 13/14] Deleted one line in english --- book/05-distributed-git/sections/maintaining.asc | 1 - 1 file changed, 1 deletion(-) diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 865127a4..80ac6c03 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -38,7 +38,6 @@ Es gibt zwei Möglichkeiten, einen per E-Mail versendeten Patch anzuwenden: mit ===== Änderungen mit `apply` anwenden (((git commands, apply))) -Assuming you saved the patch at `/tmp/patch-ruby-client.patch`, you can apply the patch like this: Wenn Sie den Patch von jemandem erhalten haben, der ihn mit `git diff` oder mit einer Variante Unix-Befehls` diff` erzeugt hat (was nicht empfohlen wird; siehe nächster Abschnitt), können Sie ihn mit dem Befehl `git apply` anwenden. Angenommen Sie haben den Patch unter `/tmp/patch-ruby-client.patch` gespeichert. Dann können Sie den Patch folgendermaßen anwenden: From 1df092dbf937ca91d5c045d6716b6d21a370ef0c Mon Sep 17 00:00:00 2001 From: pastatopf Date: Mon, 23 Sep 2019 19:54:10 +0200 Subject: [PATCH 14/14] Datei book/05-distributed-git/sections/maintaining.asc auf deutsch uebersetzt. --- .../sections/maintaining.asc | 201 +++++++++--------- book/contributors.asc | 8 +- book/dedication.asc | 12 +- book/license.asc | 2 +- status.json | 2 +- 5 files changed, 107 insertions(+), 118 deletions(-) diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index 80ac6c03..46ef25c5 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -1,16 +1,16 @@ === Ein Projekt verwalten (((maintaining a project))) -Sie müssen nicht nur wissen, wie Sie effektiv zu einem Projekt etewas beitragen, sondern auch wissen, wie Sie ein Projekt verwalten. +Sie müssen nicht nur wissen, wie Sie effektiv zu einem Projekt etwas beitragen. Sie sollten auch wissen, wie Sie ein Projekt verwalten. Sie müssen bspw. wissen wie sie Patches akzeptieren und anwenden, die über `format-patch` generiert und per E-Mail an Sie gesendet wurden. Weiterhin sollten sie wissen wie sie Änderungen in Remote-Branches für Repositorys integrieren, die Sie als Remotes zu Ihrem Projekt hinzugefügt haben. -Unabhängig davon, ob Sie ein zentrales Repository verwalten oder durch Überprüfen oder Genehmigen von Patches helfen möchten, müssen Sie wissen, wie Sie die Arbeit auf eine Weise akzeptieren, die für andere Mitwirkende transparent und auf lange Sicht auch nachhaltig ist. +Unabhängig davon, ob Sie ein zentrales Repository verwalten oder durch Überprüfen oder Genehmigen von Patches helfen möchten, müssen Sie wissen, wie Sie die Arbeit anderer so akzeptieren, dass es für andere Mitwirkende transparent und auf lange Sicht auch nachhaltig ist. ==== Arbeiten in Themen Branches (((branches, topic))) -Wenn man vor hat, neuen Quelltext zu integrieren, ist es im Allgemeinen eine gute Idee, sie in einem _Topic Branch_ auszuprobieren - einem temporären Branch, der speziell zum Ausprobieren dieser neuen Änderungen erstellt wurde. +Wenn man vorhat, neuen Quelltext zu integrieren, ist es im Allgemeinen eine gute Idee, sie in einem _Topic Branch_ zu testen. Das ist ein temporärer Branch, der speziell zum Ausprobieren dieser neuen Änderungen erstellt wurde. Auf diese Weise ist es einfach, einen Patch einzeln zu optimieren und ihn nicht weiter zu bearbeiten, wenn er nicht funktioniert, bis Sie Zeit haben, sich wieder damit zu befassen. -Sie sollten einen einfachen Branchnamen erstellen, der auf dem Thema der Arbeit basiert, die Sie durchführen, wie z.B. `ruby_client` oder etwas ähnlich sprechendes. Dann können Sie sich später leichter daran erinnern, falls Sie den Branch für eine Weile haben ruhen lassen und später daran weiter arbeiten. +Sie sollten einen einfachen Branchnamen erstellen, der auf dem Thema der Arbeit basiert, die Sie durchführen, wie z.B. `ruby_client` oder etwas ähnlich Sprechendes. Dann können Sie sich später leichter daran erinnern, falls Sie den Branch für eine Weile haben ruhen lassen und später daran weiter arbeiten. Der Betreuer des Git-Projekts neigt auch dazu, diese Branches mit einem Namespace zu versehen - wie z. B. `sc/ruby_client`, wobei `sc` für die Person steht, die die Arbeit beigesteuert hat. Wie Sie sich erinnern werden, können Sie den Branch basierend auf Ihrem `master`-Branch wie folgt erstellen: @@ -19,27 +19,27 @@ Wie Sie sich erinnern werden, können Sie den Branch basierend auf Ihrem `master $ git branch sc/ruby_client master ---- -Wenn sie anschliessend sofort zum neuen Branch wechseln möchten, können Sie auch die Option `checkout -b` verwenden: +Wenn sie anschließend sofort zum neuen Branch wechseln möchten, können Sie auch die Option `checkout -b` verwenden: [source,console] ---- $ git checkout -b sc/ruby_client master ---- -Jetzt können Sie die eingereichte Arbeit zu diesem Branch hinzufügen und festlegen, ob Sie ihn mit Ihren bestehenden Branches zusammenführen möchten. +Jetzt können Sie die getätigte Arbeit zu diesem Branch hinzufügen und festlegen, ob Sie ihn mit Ihren bestehenden Branches zusammenführen möchten. [[_patches_from_email]] -==== Anwenden von Änderungen aus E-Mails +==== Integrieren von Änderungen aus E-Mails (((email, applying patches from))) -Wenn Sie einen Patch per E-Mail erhalten, den Sie in Ihr Projekt integrieren müssen, müssen Sie den Patch in Ihrer Themen Branch anwenden, damit sie ihn prüfen können. -Es gibt zwei Möglichkeiten, einen per E-Mail versendeten Patch anzuwenden: mit `git apply` oder mit` git am`. +Wenn Sie einen Patch per E-Mail erhalten, den Sie in Ihr Projekt integrieren müssen, müssen Sie den Patch in Ihrer Themen Branch einfließen lassen, damit sie ihn prüfen können. +Es gibt zwei Möglichkeiten, einen per E-Mail versendeten Patch anzuwenden: mit `git apply` oder mit `git am`. -===== Änderungen mit `apply` anwenden +===== Änderungen mit `apply` integrieren (((git commands, apply))) -Wenn Sie den Patch von jemandem erhalten haben, der ihn mit `git diff` oder mit einer Variante Unix-Befehls` diff` erzeugt hat (was nicht empfohlen wird; siehe nächster Abschnitt), können Sie ihn mit dem Befehl `git apply` anwenden. -Angenommen Sie haben den Patch unter `/tmp/patch-ruby-client.patch` gespeichert. Dann können Sie den Patch folgendermaßen anwenden: +Wenn Sie den Patch von jemandem erhalten haben, der ihn mit `git diff` oder mit einer Variante des Unix-Befehls` diff` erzeugt hat (was nicht empfohlen wird; siehe nächster Abschnitt), können Sie ihn mit dem Befehl `git apply` integrieren. +Angenommen Sie haben den Patch unter `/tmp/patch-ruby-client.patch` gespeichert. Dann können Sie den Patch folgendermaßen integrieren: [source,console] ---- @@ -47,13 +47,13 @@ $ git apply /tmp/patch-ruby-client.patch ---- Hierdurch werden die Dateien in Ihrem Arbeitsverzeichnis geändert. -Es ist fast identisch mit dem Ausführen eines `patch -p1` Befehls zum Anwenden des Patches, obwohl es paranoider ist und unscharfe Übereinstimmungen selektiver als `patch' akzeptiert. +Es ist fast identisch mit dem Ausführen eines `patch -p1` Befehls zum Anwenden des Patches, obwohl es vorsichtiger ist und unscharfe Übereinstimmungen selektiver als `patch` akzeptiert. Damit kann man auch Dateien Hinzufügen, Löschen und Umbenennen, wenn diese im `git diff`-Format beschrieben sind, was mit `patch` nicht möglich ist. -Zu guter letzt ist `git apply` ein ``wende alles oder nichts an''-Modell, bei dem entweder alles oder nichts angewendet wird, wohingegen `patch` Patchdateien teilweise anwenden kann und Ihr Arbeitsverzeichnis in einnm undefinierten Zustand versetzen kann. -`git apply` ist insgesamt sehr viel konservativer als` patch`. -Es wird kein Commit für Sie erstellen. Nach dem Ausführen müssen Sie die eingeführten Änderungen manuell bereitstellen und einchecken. +Zu guter Letzt ist `git apply` ein ``wende alles oder nichts an''-Modell, bei dem entweder alles oder nichts angewendet wird. `patch` hingegen integriert Patchdateien eventuell nur teilweise und kann Ihr Arbeitsverzeichnis in einem undefinierten Zustand versetzen. +`git apply` ist insgesamt sehr viel konservativer als `patch`. +Es wird kein Commit erstellen. Nach dem Ausführen müssen Sie die eingeführten Änderungen manuell bereitstellen und comitten. -Sie können auch `git apply` verwenden, um zu prüfen, ob ein Patch ordnungsgemäß angewendet wird, bevor Sie versuchen, ihn tatsächlich anzuwenden. Sie können `git apply --check` auf den Patch ausführen: +Sie können `git apply` verwenden, um zu prüfen, ob ein Patch ordnungsgemäß integriert werden kann, bevor Sie versuchen, ihn tatsächlich anzuwenden. Sie können `git apply --check` auf den Patch ausführen: [source,console] ---- @@ -63,17 +63,17 @@ error: ticgit.gemspec: patch does not apply ---- Wenn keine Ausgabe erfolgt, sollte der Patch ordnungsgemäß angewendet werden können. -Dieser Befehl wird auch mit einem Rückgabewert ungleich Null beendet, wenn die Prüfung fehlschlägt, sodass Sie ihn bei Bedarf in Skripten verwenden können. +Dieser Befehl wird auch mit einem Rückgabewert ungleich Null beendet, wenn die Prüfung fehlschlägt. So können sie ihn bei Bedarf in Skripten verwenden. [[_git_am]] -===== Änderungen mit `am` anwenden +===== Änderungen mit `am` integrieren (((git commands, am))) -Wenn der Beitragende ein Git-Benutzer ist und den Befehl `format-patch` zum Generieren seines Patches verwendet hat, ist Ihre Arbeit einfacher. Der Patch enthält bereits Informationen über dem Autor und eine entsprechende Commitnachricht. -Wenn möglich, ermutigen Sie die Beitragenden `format-patch` anstelle von `diff` zum erstellen von Patches zu verwenden. -Sie sollten `git apply` nur für ältere Patches und ähnliche Dinge verwenden. +Wenn der Beitragende ein Git-Benutzer ist und den Befehl `format-patch` zum Generieren seines Patches verwendet hat, ist Ihre Arbeit einfacher. Der Patch enthält bereits Informationen über den Autor und eine entsprechende Commitnachricht. +Wenn möglich, ermutigen Sie die Beitragenden `format-patch` anstelle von `diff` zum Erstellen von Patches zu verwenden. +Sie sollten `git apply` nur für ältere Patche und ähnliche Dinge verwenden. -Um einen von `format-patch` erzeugten Patch anzuwenden, verwenden Sie `git am` (der Befehl heißt `am`, da er verwendet wird, um „eine Reihe von Patches aus einer Mailbox anzuwenden“). +Um einen von `format-patch` erzeugten Patch zu integrieren, verwenden Sie `git am` (der Befehl heißt `am`, da er verwendet wird, um „eine Reihe von Patches aus einer Mailbox anzuwenden“). Technisch gesehen ist `git am` so aufgebaut, dass eine mbox-Datei gelesen werden kann. Hierbei handelt es sich um ein einfaches Nur-Text-Format zum Speichern einer oder mehrerer E-Mail-Nachrichten in einer Textdatei. Das sieht in etwa so aus: @@ -88,10 +88,10 @@ Limit log functionality to the first 20 ---- Dies ist der Anfang der Ausgabe des Befehls `git format-patch`, den Sie im vorherigen Abschnitt gesehen haben. Es zeigt ein gültiges mbox Email Format. -Wenn Ihnen jemand den Patch ordnungsgemäß mit `git send-email` per E-Mail zugesendet hat und Sie ihn in ein mbox-Format herunterladen, können Sie `git am` auf diese mbox-Datei auführen und alle angezeigten Patches werden entsprechend angewendet. -Wenn Sie einen Mail-Client ausführen, der mehrere E-Mails im Mbox-Format speichern kann, können Sie ganze Patch-Serien in einer Datei speichern und diese dann mit `git am` einzeln anwenden. +Wenn Ihnen jemand den Patch ordnungsgemäß mit `git send-email` per E-Mail zugesendet hat und Sie ihn in ein mbox-Format herunterladen, können Sie `git am` auf diese mbox-Datei ausführen. Damit werden alle angezeigten Patches entsprechend angewendet. +Wenn Sie einen Mail-Client ausführen, der mehrere E-Mails im Mbox-Format speichern kann, können Sie ganze Patch-Serien in einer Datei speichern. Diese können anschließend mit `git am` einzeln angewendet werden. -Wenn jedoch jemand eine mit `git format-patch` erzeugte Patch-Datei in ein Ticketing-System oder ähnliches hochgeladen hat, können Sie die Datei lokal speichern und diese auf Ihrer Festplatte gespeicherte Datei dann an `git am` übergeben, um sie anzuwenden: +Wenn jemand eine mit `git format-patch` erzeugte Patch-Datei in ein Ticketing-System oder ähnliches hochgeladen hat, können Sie die Datei lokal speichern. Die Datei können sie dann an `git am` übergeben, um sie integrieren: [source,console] ---- @@ -99,9 +99,9 @@ $ git am 0001-limit-log-function.patch Applying: add limit to log function ---- -Sie können sehen, dass es korrekt angewendet und das neue Commit automatisch für Sie erstellt wurde. -Die Autoreninformationen werden aus den Kopfzeilen `From` und `Date` der E-Mail entnommen und die Nachricht des Commits wird aus dem `Subject` und dem Textkörper (vor dem Patch) der E-Mail entnommen. -Wenn dieser Patch beispielsweise aus dem obigen mbox-Beispiel angewendet würde, würde der erzeugte Commit ungefähr so aussehen: +Wie sie können sehen, wurde der Patch korrekt integriert und es wurde automatisch ein neue Commit für Sie erstellt. +Die Autoreninformationen werden aus den Kopfzeilen `From` und `Date` der E-Mail entnommen und die Commitnachricht wird aus dem `Subject` und dem Textkörper (vor dem Patch) der E-Mail entnommen. +Wenn dieser Patch bspw. aus dem obigen mbox-Beispiel angewendet würde, würde der erzeugte Commit in etwa so aussehen: [source,console] ---- @@ -136,8 +136,8 @@ If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". ---- -Dieser Befehl fügt Konfliktmarkierungen in alle Dateien ein, in denen Probleme auftreten. Ähnlich wie bei einem Konflikt bei der Zusammenführung (engl. merge) bzw. der Reorganisation (engl rebase). -Sie lösen dieses Problem auf die gleiche Weise: Bearbeiten Sie die Datei, um den Konflikt zu lösen. Anschliessend fügen sie die neue Datei der Staging Area hinzu und führen Sie dann `git am --resolved` aus, um mit dem nächsten Patch fortzufahren: +Dieser Befehl fügt Konfliktmarkierungen in alle Dateien ein, in denen Probleme auftreten. Ähnlich wie bei einem Konflikt bei der Zusammenführung (engl. merge) bzw. bei der Reorganisation (engl. rebase). +Sie lösen dieses Problem auf die gleiche Art: Bearbeiten Sie die Datei, um den Konflikt zu lösen. Anschließend fügen sie die neue Datei der Staging Area hinzu und führen dann `git am --resolved` aus, um mit dem nächsten Patch fortzufahren: [source,console] ---- @@ -148,7 +148,7 @@ Applying: seeing if this helps the gem ---- Wenn Sie möchten, dass Git den Konflikt etwas intelligenter löst, können Sie ihm die Option "-3" übergeben, wodurch Git versucht, eine Dreifachzusammenführung durchzuführen. -Diese Option ist standardmäßig nicht aktiviert, da sie nicht funktioniert, wenn sich das Commit, auf dem der Patch basiert, nicht in Ihrem Repository befindet. +Diese Option ist standardmäßig nicht aktiviert, da sie nicht funktioniert, wenn sich der Commit, auf dem der Patch basiert, nicht in Ihrem Repository befindet. Wenn Sie diesen Commit haben - wenn der Patch auf einem öffentlichen Commit basiert -, ist die Option "-3" im Allgemeinen viel intelligenter beim Anwenden eines Patch mit Konflikten: [source,console] @@ -162,10 +162,10 @@ Falling back to patching base and 3-way merge... No changes -- Patch already applied. ---- -In diesem Fall wäre der Patch ohne die Option "-3" als Konflikt gewertet worden. -Da die Option "-3" verwendet wurde, wurde der Patch sauber angewendet. +In diesem Fall wäre der Patch ohne die Option `-3` als Konflikt gewertet worden. +Da die Option `-3` verwendet wurde, konnte der Patch sauber angewendet werden. -Wenn Sie mehrere Patches von einer mbox aus anwenden, können Sie auch den Befehl `am` im interaktiven Modus ausführen. Bei jedem gefundenen Patch wird angehalten und Sie werden gefragt, ob Sie ihn anwenden möchten: +Wenn Sie mehrere Patches aus mbox anwenden, können Sie auch den Befehl `am` im interaktiven Modus ausführen. Bei jedem gefundenen Patch wird angehalten und Sie werden gefragt, ob Sie ihn anwenden möchten: [source,console] ---- @@ -177,17 +177,17 @@ seeing if this helps the gem Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all ---- -Dies ist hilfreich, wenn Sie eine Reihe von Patches gespeichert haben, da Sie den Patch zuerst anzeigen können, wenn Sie sich nicht daran erinnern, worum es genau geht. Oder aber weil sie den Patch nicht anwenden können, weil Sie dies bereits getan haben. +Dies ist hilfreich, wenn Sie eine Reihe von Patches gespeichert haben. Sie können sich den Patch zuerst anzeigen lassen, wenn Sie sich nicht daran erinnern, worum es genau geht. Oder sie wenden den Patch nicht an, weil Sie es bereits getan haben. -Wenn alle Patches für Ihr Thema angewendet und in Ihrem Branch festgeschrieben wurden, können Sie auswählen, ob und wie Sie sie in einen Hauptzweig integrieren möchten. +Wenn alle Patches für Ihr Thema angewendet und in Ihrem Branch committet wurden, können Sie auswählen, ob und wie Sie sie in einen Hauptbranch integrieren möchten. [[_checking_out_remotes]] ==== Remote Branches auschecken (((branches, remote))) -Wenn sie einen Beitrag erhalten, der von einem Git-Benutzer stammt, der sein eigenes Repository eingerichtet, eine Reihe von Änderungen vorgenommen und Ihnen dann die URL zum Repository und den Namen des Remote-Zweigs gesendet hat, in dem sich die Änderungen befinden, können Sie diesen als remote hinzufügen und die Änderungen lokal zusammenführen. +Wenn sie einen Beitrag von einem Git-Nutzer erhalten, der sein eigenes Repository eingerichtet, eine Reihe von Änderungen vorgenommen und Ihnen dann die URL zum Repository und den Namen des Remote-Zweigs gesendet hat, in dem sich die Änderungen befinden, dann können Sie diesen als remote hinzufügen und die Änderungen lokal zusammenführen. -Wenn Jessica Ihnen beispielsweise eine E-Mail sendet, die besagt, dass sie eine großartige neue Funktion im `ruby-client` Branch ihres Repositorys hat, können Sie diese testen, indem Sie den Branch als remote hinzufügen und ihn lokal auschecken: +Wenn Jessica Ihnen bspw. eine E-Mail sendet, die besagt, dass sie eine großartige neue Funktion im `ruby-client` Branch ihres Repositorys hat, können Sie diese testen, indem Sie den Branch als remote hinzufügen und ihn lokal auschecken: [source,console] ---- @@ -196,17 +196,17 @@ $ git fetch jessica $ git checkout -b rubyclient jessica/ruby-client ---- -Wenn sie Ihnen später erneut eine E-Mail mit einem anderen Branch sendet, der eine weitere großartige Funktion enthält, können Sie diese direkt abrufen und auschecken, da Sie bereits über das Remote Repository verfügen. +Wenn Jessica Ihnen später erneut eine E-Mail mit einem anderen Branch sendet, der eine weitere großartige Funktion enthält, können Sie diese direkt abrufen und auschecken, da Sie bereits über das Remote Repository verfügen. -Dies ist am nützlichsten, wenn Sie durchweg mit einer Person arbeiten. -Wenn nur ein Patch von Zeit zu Zeit zur Verfügung steht, ist das Akzeptieren über E-Mail möglicherweise weniger zeitaufwendig, als dass jeder seinen eigenen Server unterhalten und Remotes hinzufügen und entfernen muss, um einige wenige Patches zu erhalten. +Dies ist am nützlichsten, wenn Sie durchgängig mit einer Person arbeiten. +Wenn jemand nur selten einen Patch zur Verfügung steht, ist das Akzeptieren über E-Mail möglicherweise weniger zeitaufwendig. Andernfalls müsste jeder seinen eigenen Server unterhalten und Remotes hinzufügen und entfernen, um diese wenige Patches zu erhalten. Es ist auch unwahrscheinlich, dass Sie Hunderte von Remotes einbinden möchten für Personen, die nur ein oder zwei Patches beisteuern. -Skripte und gehostete Dienste können dies jedoch vereinfachen - dies hängt weitgehend davon ab, wie Sie und die Mitwirkenden sich entwickeln. +Skripte und gehostete Dienste können dies jedoch vereinfachen - dies hängt weitgehend davon ab, wie Sie und die Mitwirkenden entwickeln. Der andere Vorteil dieses Ansatzes ist, dass Sie auch die Historie der Commits erhalten. -Obwohl Sie möglicherweise berechtigte Probleme bei der Zusammenführungen haben, wissen Sie, wo in Ihrer Hisorie deren Arbeit basiert. Eine ordnungsgemäße Drei-Wege-Zusammenführung ist die Standardeinstellung, anstatt ein "-3" einzugeben, und sie hoffen, dass der Patch aus einem öffentlichen Commit generiert wurde, auf den Sie Zugriff haben. +Obwohl Sie möglicherweise berechtigte Probleme bei der Zusammenführungen haben, wissen Sie, wo in Ihrer Historie deren Arbeit basiert. Eine ordnungsgemäße Drei-Wege-Zusammenführung ist die Standardeinstellung, anstatt ein "-3" einzugeben, und zu hoffen, dass der Patch aus einem öffentlichen Commit generiert wurde, auf den Sie Zugriff haben. -Wenn Sie nicht durchgehen mit einer Person arbeiten, aber dennoch auf diese Weise von dieser Person abrufen möchten, können Sie die URL des Remote-Repositorys für den Befehl `git pull` angeben. +Wenn Sie nicht durchgängig mit einer Person arbeiten, aber dennoch auf diese Weise von dieser Person abrufen möchten, können Sie die URL des Remote-Repositorys für den Befehl `git pull` angeben. Dies führt einen einmaligen Abruf durch und speichert die URL nicht als Remote-Referenz: [source,console] @@ -221,14 +221,14 @@ Merge made by the 'recursive' strategy. ==== Bestimmen, was eingeführt wird (((branches, diffing))) -Jetzt haben Sie einen Themen Branch mit neuen Beiträgen. +Sie haben nun einen Themen Branch mit neuen Beiträgen. An dieser Stelle können Sie festlegen, was Sie damit machen möchten. -In diesem Abschnitt werden einige Befehle noch einmal behandelt, damit Sie sehen können, wie Sie sie verwenden können. So können sie genau überprüfen, was Sie einführen, wenn Sie die Beiträge in Ihrem Haupt Branch zusammenführen. +In diesem Abschnitt werden einige Befehle noch einmal behandelt. Mit diesen können sie genau überprüfen, was Sie einführen, wenn Sie die Beiträge in Ihrem Hauptbranch zusammenführen. -Es ist oft hilfreich, eine Übersicht über alle Commits zu erhalten, die sich in diesem Branch jedoch nicht in Ihrem Master-Branch befinden. -Sie können Commits im Master-Branch ausschließen, indem Sie die Option "--not" vor dem Branchnamen hinzufügen. -Dies entspricht dem Format `master..contrib`, das wir zuvor verwendet haben. -Wenn Ihr Mitarbeiter Ihnen beispielsweise zwei Patches sendet und Sie einen Branch mit dem Namen `contrib` erstellen und diese Patches dort anwenden, können Sie Folgendes ausführen: +Es ist oft hilfreich, eine Überprüfung über alle Commits zu erhalten, die sich in diesem Branch jedoch nicht in Ihrem Masterbranch befinden. +Sie können Commits im Masterbranch ausschließen, indem Sie die Option `--not` vor dem Branchnamen hinzufügen. +Dies entspricht dem Format `master..contrib`, welches wir zuvor verwendet haben. +Wenn Ihr Mitarbeiter Ihnen bspw. zwei Patches sendet und Sie einen Branch mit dem Namen `contrib` erstellen und diese Patches dort anwenden, können Sie Folgendes ausführen: [source,console] ---- @@ -246,9 +246,9 @@ Date: Mon Oct 22 19:38:36 2008 -0700 updated the gemspec to hopefully work better ---- -Denken Sie daran, dass Sie die Option `-p` an `git log` übergeben können, um zu sehen, welche Änderungen jeder Commit einführt, und den Diff an jeden Commit anfügt. +Denken Sie daran, dass Sie die Option `-p` an `git log` übergeben können, um zu sehen, welche Änderungen jeder Commit einführt. -Um einen vollständigen Überblick darüber zu erhalten, was passieren würde, wenn Sie diesen Branch mit einem anderen Branch zusammenführen würden, müssen Sie möglicherweise einen ungeröhnlichen Kniff anwenden, um die richtigen Ergebnisse zu erzielen. +Um einen vollständigen Überblick darüber zu erhalten, was passieren würde, wenn Sie diesen Branch mit einem anderen Branch zusammenführen würden, müssen Sie möglicherweise einen ungewöhnlichen Kniff anwenden, um die richtigen Ergebnisse zu erzielen. Eventuell denken sie daran folgendes auszuführen: [source,console] @@ -257,14 +257,14 @@ $ git diff master ---- Dieser Befehl gibt Ihnen den Unterschied zurück, jedoch kann dies irreführend sein. -Wenn Ihr Master-Branch vorgerückt ist, seit Sie den Themen-Branch daraus erstellt haben, erhalten Sie scheinbar unerwartete Ergebnisse. +Wenn Ihr Masterbranch vorgerückt ist, seit Sie den Themenbranch daraus erstellt haben, erhalten Sie scheinbar unerwartete Ergebnisse. Dies geschieht, weil Git den Snapshots des letzten Commits des Branches, in dem Sie sich befinden, und den Snapshot des letzten Commits des Branches `master` direkt miteinander vergleicht. -Wenn Sie beispielsweise eine Zeile in eine Datei im Branch `master` eingefügt haben, sieht ein direkter Vergleich der Snapshots so aus, als würde der Themen Branch diese Zeile entfernen. +Wenn Sie bspw. eine Zeile in eine Datei im Branch `master` eingefügt haben, sieht ein direkter Vergleich der Snapshots so aus, als würde der Themen Branch diese Zeile entfernen. -Wenn `master` ein direkter Vorgänger Ihres Themen Branches ist, ist dies kein Problem. Wenn die beiden Historien jedoch voneinander abweichen, sieht es so aus, als würden Sie alle neuen Inhalte in Ihrem Themen Branch hinzufügen und alles entfernen, was für den `master` Branch eindeutig ist. +Wenn `master` ein direkter Vorgänger Ihres Themenbranches ist, ist dies kein Problem. Wenn aber beiden Historien voneinander abweichen, sieht es so aus, als würden Sie alle neuen Inhalte in Ihrem Themenbranch hinzufügen und alles entfernen, was im `master` Branch eindeutig ist. -Was Sie wirklich sehen möchten, sind die Änderungen, die dem Themen Branch hinzugefügt wurden - die Arbeit, die Sie hinzufügen, wenn Sie den neuen Branch mit `master` zusammenführen. -Sie tun dies, indem Git das letzte Commit in Ihrem Themen Branch mit dem ersten gemeinsamen Vorgänger vom `master` Branch vergleicht. +Was Sie wirklich sehen möchten, sind die Änderungen, die dem Themenbranch hinzugefügt wurde. Die Arbeit, die Sie hinzufügen, wenn Sie den neuen Branch mit `master` zusammenführen. +Sie tun dies, indem Git das letzte Commit in Ihrem Themen Branch mit dem ersten gemeinsamen Vorgänger aus dem `master` Branch vergleicht. Technisch gesehen können Sie dies tun, indem Sie den gemeinsamen Vorgänger explizit herausfinden und dann Ihr `diff` darauf ausführen: @@ -283,46 +283,46 @@ $ git diff $(git merge-base contrib master) ---- Beides ist jedoch nicht besonders praktisch, weshalb Git eine andere Weg für diesen Vorgang bietet: die Drei-Punkt-Syntax (engl. Triple-Dot-Syntax). -Im Kontext des Befehls `git diff` können Sie drei Punkte nach einem anderen Branch einfügen, um ein `diff` zwischen dem letzten Commit ihres aktullen Branchs, in dem Sie sich befinden, und dem gemeinsamen Vorgänger eines anderen Branches zu erstellen: +Im Kontext des Befehls `git diff` können Sie drei Punkte nach einem anderen Branch einfügen, um ein `diff` zwischen dem letzten Commit ihres aktuellen Branch und dem gemeinsamen Vorgänger eines anderen Branches zu erstellen: [source,console] ---- $ git diff master...contrib ---- -Dieser Befehl zeigt Ihnen nur die Arbeit an, die Ihr aktueller Branch seit seinem gemeinsamen Vorgänger mit master eingeführt hat. +Dieser Befehl zeigt Ihnen nur die Arbeit an, die Ihr aktueller Branch seit dem gemeinsamen Vorgänger mit master eingeführt hat. Dies ist eine sehr nützliche Syntax, die sie sich merken sollten. ==== Beiträge integrieren (((integrating work))) -Wenn alle Arbeiten in Ihrem Themen Branch bereit sind, um in ein größeren Hauptbranch integriert zu werden, lautet die Frage, wie Sie dies tun können. +Wenn ihr Themenbranch bereit ist, um in einen Hauptbranch integriert zu werden, lautet die Frage, wie Sie dies tun können. Welchen Workflow möchten Sie verwenden, um Ihr Projekt zu verwalten? Sie haben eine Reihe von Möglichkeiten, daher werden wir einige davon behandeln. -===== Workflows zusammenführen (engl. mergen) +===== Zusammenführungs Workflow (engl. mergen) (((workflows, merging))) -Ein grundlegender Workflow besteht darin, all diese Arbeiten einfach direkt in Ihrem `master`Branch zusammenzuführen. +Ein grundlegender Workflow besteht darin, all diese Arbeiten einfach direkt in Ihrem `master`-Branch zusammenzuführen. In diesem Szenario haben Sie einen `master`-Branch, der stabilen Code enthält. -Wenn Sie in einem Branch arbeiten, von dem Sie glauben, dass Sie ihn abgeschlossen haben, oder von jemand anderem beigesteuert und überprüft haben, führen Sie ihn in Ihrem Hauptbranch zusammen. Löschen sie anschliessend diesen gerade zusammengeführten Branch und wiederholen diesen Vorgang bei Bedarf. +Wenn Sie in einem Branch arbeiten, von dem Sie glauben, dass Sie ihn abgeschlossen haben, oder von jemand anderem beigesteuert und überprüft haben, führen Sie ihn in Ihrem Hauptbranch zusammen. Löschen sie anschließend diesen gerade zusammengeführten Branch und wiederholen den Vorgang bei Bedarf. -Wenn wir zum Beispiel ein Repository mit zwei Branches namens `ruby_client` und `php_client` haben, die wie <> aussehen, und wir `ruby_client` gefolgt von `php_client` zusammenführen, sieht Ihr Verlauf wie <> aus. +Wenn wir zum Beispiel ein Repository mit zwei Branches namens `ruby_client` und `php_client` haben, die wie <> aussehen, und wir `ruby_client` gefolgt von `php_client` zusammenführen, sieht Ihr Verlauf so aus <>. [[merwf_a]] -.Historie mit meheren Topic Branches. -image::images/merging-workflows-1.png[Historie mit meheren Topic Branches.] +.Historie mit mehreren Topic Branches. +image::images/merging-workflows-1.png[Historie mit mehreren Topic Branches.] [[merwf_b]] .Status nach einem Themen Branch Merge. image::images/merging-workflows-2.png[Status nach einem Themen Branch Merge.] -Das ist wahrscheinlich der einfachste Workflow. Es kann jedoch zu Problemen können, wenn Sie größere oder stabilere Projekte bearbeiten. Sie müssen bei der Einführung von Änderungen sehr vorsichtig sein. +Das ist wahrscheinlich der einfachste Workflow. Es kann jedoch zu Problemen können, wenn Sie größere oder stabilere Projekte bearbeiten. Bei diesen müssen mit der Einführung von Änderungen sehr vorsichtig sein. Wenn Sie ein wichtigeres Projekt haben, möchten Sie möglicherweise einen zweistufigen Merge Prozess verwenden. In diesem Szenario haben Sie zwei lange laufende Branches namens `master` und `develop`. Sie legen fest, dass `master` nur dann aktualisiert wird, wenn eine sehr stabile Version vorhanden ist und der gesamte neue Code in den Branch `develop` integriert wird. Sie pushen diese beiden Branches regelmäßig in das öffentliche Repository. -Jedes Mal, wenn Sie einen neuen Branch zum Zusammenführen haben (<>), führen Sie ihn in `develop` (<< merwf_d >>) zusammen. Wenn Sie ein Release mit einem Tag versehen, spulen Sie `master` an die Stelle weiter, an der sich der jetzt stabile `develop`-Branch befindet (<>). +Jedes Mal, wenn Sie einen neuen Branch zum Zusammenführen haben (<>), führen Sie ihn in `develop` (<< merwf_d >>) zusammen. Wenn Sie nun ein Release mit einem Tag versehen, spulen Sie `master` an die Stelle weiter, an der sich der jetzt stabile `develop`-Branch befindet (<>). [[merwf_c]] .Vor einem Themen Branch Merge. @@ -336,17 +336,17 @@ image::images/merging-workflows-4.png[Nach einem Themen Branch Merge.] .Nach einem Projekt Release. image::images/merging-workflows-5.png[Nach einem Projekt Release.] -Auf diese Weise können Benutzer, die das Repository Ihres Projekts klonen, entweder `master` oder `develop` auschecken. Mit `master` können sie die neueste stabile Version erstellen und somit recht einfache auf dem neuesten Stand bleiben. Oder sie können `develop` auschecken, welchen den aktuellsten Inhalt darstellt. +Auf diese Weise können Benutzer, die das Repository Ihres Projekts klonen, entweder `master` oder `develop` auschecken. Mit `master` können sie die neueste stabile Version erstellen und somit recht einfache auf dem neuesten Stand bleiben. Oder sie können `develop` auschecken, welchen den aktuellsten Inhalt enthält. Sie können dieses Konzept auch erweitern, indem Sie einen `integrate`-Branch einrichten, in dem alle Arbeiten zusammengeführt werden. -Wenn die Codebasis auf diesem Branch stabil ist und die Tests erfolgreich sind, können Sie sie zu einem Entwicklungsbranch zusammen führen. Wenn sich das als stabil erwiesen hat, können sie ihren `master`-Branch fast-forwarden. +Wenn die Codebasis auf diesem Branch stabil ist und die Tests erfolgreich sind, können Sie sie zu einem Entwicklungsbranch zusammen führen. Wenn sich dieser dann als stabil erwiesen hat, können sie ihren `master`-Branch fast-forwarden. ===== Workflows mit umfangreichen Merges (((workflows, "merging (large)"))) -Das Git-Projekt hat vier lange laufende Branches: `master`, `next` und `pu` (vorgeschlagene Updates) für neue Arbeiten und `maint` für Wartungs-Backports. -Wenn neue Arbeiten von Mitwirkenden eingereicht werden, werden sie in ähnlicher Weise wie oben beschrieben in Themenbranches im Projektarchiv des Betreuers gesammelt (siehe <>). +Das Git-Projekt selber hat vier kontinuierlich laufende Branches: `master`, `next` und `pu` (vorgeschlagene Updates) für neue Arbeiten und `maint` für Wartungs-Backports. +Wenn neue Arbeiten von Mitwirkenden eingereicht werden, werden sie in ähnlicher Weise wie oben beschrieben in Themenbranches im Projektrepository des Betreuers gesammelt (siehe <>). Zu diesem Zeitpunkt werden die Themen evaluiert, um festzustellen, ob sie korrekt sind und zur Weiterverarbeitung bereit sind oder ob sie Nacharbeit benötigen. -Wenn sie korrekt sind, werden sie zu `next` zusammengeführt, und dieser Branch wird gepushed, damit jeder die miteinander integrierten Themen testen kann. +Wenn sie korrekt sind, werden sie zu `next` zusammengeführt, und dieser Branch wird dann gepushed, damit jeder die miteinander integrierten Themen testen kann. [[merwf_f]] .Verwaltung einer komplexen Reihe paralleler Themenbranches. @@ -354,31 +354,31 @@ image::images/large-merges-1.png[Verwaltung einer komplexen Reihe paralleler The Wenn die Themen noch bearbeitet werden müssen, werden sie in `pu` gemerged. Wenn festgestellt wird, dass sie absolut stabil sind, werden die Themen wieder zu `master` zusammengeführt. -Die Branches `next` und `pu` werden dann vom `master` neu aufgebaut. -Dies bedeutet, dass `master` fast immer vorwärts geht, `next` wird gelegentlich neu rebased und `pu` noch häufiger rebased wird: +Die Branches `next` und `pu` werden dann von `master` neu aufgebaut. +Dies bedeutet, dass `master` fast immer vorwärts geht, `next` wird gelegentlich und `pu` häufiger rebased: .Zusammenführen von Themen Branches in langfristige Integrationsbranches. image::images/large-merges-2.png[Zusammenführen von Themen Branches in langfristige Integrationsbranches.] Wenn ein Branch schließlich zu `master` zusammengeführt wurde, wird er aus dem Repository entfernt. -Das Git-Projekt hat auch einen `maint`-Branch, der von der letzten Version geforkt wurde, um für den Fall, dass eine Wartungsversion erforderlich ist, Backport-Patches bereitzustellen. -Wenn Sie das Git-Repository klonen, stehen Ihnen vier Branches zur Verfügung, mit denen Sie das Projekt in verschiedenen Entwicklungsstadien bewerten können, je nachdem, wie aktuell Sie sein möchten oder wie Sie einen Beitrag leisten möchten. Der Betreuer verfügt über einen strukturierten Workflow, der ihm hilft, neue Beiträge zu überprüfen. +Das Git-Projekt hat auch einen `maint`-Branch, der von letzten release geforkt wurde, um für den Fall, dass eine Wartungsversion erforderlich ist, Backport-Patches bereitzustellen. +Wenn Sie das Git-Repository also klonen, stehen Ihnen vier Branches zur Verfügung, mit denen Sie das Projekt in verschiedenen Entwicklungsstadien bewerten können, je nachdem, wie aktuell Sie sein möchten oder wie Sie einen Beitrag leisten möchten. Der Betreuer verfügt über einen strukturierten Workflow, der ihm hilft, neue Beiträge zu überprüfen. Der Workflow des Git-Projekts ist sehr speziell. -Um dies klar zu verstehen, können Sie das https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt[Git Maintainer's guide] lesen. +Um dies zu verstehen, können Sie das https://github.com/git/git/blob/master/Documentation/howto/maintain-git.txt[Git Maintainer's guide] lesen. [[_rebase_cherry_pick]] ===== Rebasing und Cherry-Picking Workflows (((workflows, rebasing and cherry-picking))) Andere Betreuer bevorzugen es, die Arbeit auf ihrem Masterbranch zu rebasen oder zu cherry-picken, anstatt sie zusammenzuführen, um einen linearen Verlauf beizubehalten. -Wenn Sie in einem Themen Branch arbeiten und sich dazu entschlossen haben, ihn zu integrieren, wechseln Sie in diesen Branch und führen den `rebase`Befehl aus. Damit stellen sie die , um die Änderungen auf Ihrem aktuellen `master` (oder `develop`-Branch usw.) wiederherzustellen. +Wenn Sie in einem Themen Branch arbeiten und sich dazu entschlossen haben, ihn zu integrieren, wechseln Sie in diesen Branch und führen den `rebase` Befehl aus, um die Änderungen auf ihrem `master` (oder `develop`-Branch usw.) aufzubauen. Wenn das gut funktioniert, können Sie Ihren `master`-Branch fast-forwarden, und Sie erhalten eine lineare Projekthistorie. (((git commands, cherry-pick))) -Die andere Möglichkeit, die eingeführte Arbeit von einem Branch in einen anderen zu verschieben, besteht darin, sie zu cherry-picken. +Eine andere Möglichkeit, die eingeführte Arbeit von einem Branch in einen anderen zu verschieben, besteht darin, sie zu cherry-picken. Ein Cherry-Pick in Git ist wie ein Rebase für ein einzelnes Commit. -Es verwendet den Patch, der in einem Commit eingeführt wurde, und versucht, ihn erneut auf den Branch anzuwenden, auf dem Sie sich gerade befinden. -Dies ist nützlich, wenn Sie eine Reihe von Commits für einen Branch haben und nur eine davon integrieren möchten, oder wenn Sie nur einen Commit für einen Branch haben und Sie es vorziehen, diese zu cherry-picken, anstatt ein Rebase auszuführen. +Es nimmt den Patch, der in einem Commit eingeführt wurde, und versucht ihn erneut auf den Branch anzuwenden, auf dem Sie sich gerade befinden. +Dies ist nützlich, wenn Sie eine Reihe von Commits für einen Branch haben und nur eine davon integrieren möchten. Oder aber wenn Sie nur einen Commit für einen Branch haben und es vorziehen, diesen zu cherry-picken, anstatt ein Rebase auszuführen. Angenommen, Sie haben ein Projekt, das folgendermaßen aussieht: .Beispiel Historie vor einem Cherry-Pick. @@ -400,16 +400,15 @@ Nun sieht die Historie so aus: .Historie nach Cherry-Picken eines Commits auf einen Themen Branch. image::images/rebasing-2.png[Historie nach Cherry-Picken eines Commits auf einen Themen Branch.] -Jetzt können Sie Ihren Themen Branch entfernen und die Commits löschen, die Sie nicht mehr benötigen. +Jetzt können Sie Ihren Themen Branch entfernen und die Commits löschen, die Sie nicht einbeziehen wollten. ===== Rerere (((git commands, rerere)))(((rerere))) -Wenn Sie viel mergen und rebasen oder einen langlebigen Themenbranch pflegen, hat Git eine Funktion namens ``rerere'', die helfen kann. - -Rerere steht für ``reuse recorded resolution'' (deutsch ``Aufgezeichnete Lösung wiederverwenden'') - es ist eine Möglichkeit, die manuelle Konfliktlösung zu verkürzen. -Wenn rerere aktiviert ist, behält Git eine Reihe von Pre- und Post-Images von erfolgreichen Commits bei. Wenn es feststellt, dass ein Konflikt genau so aussieht, wie der, den Sie bereits behoben haben, wird nur die Korrektur vom letzten Mal verwendet , ohne nochmal zu belästigen. +Wenn Sie viel mergen und rebasen oder einen langlebigen Themenbranch pflegen, hat Git eine Funktion namens ``rerere'', die nützlich sein kann. +Rerere steht für ``reuse recorded resolution'' (deutsch ``Aufgezeichnete Lösung wiederverwenden''). Es ist eine Möglichkeit, die manuelle Konfliktlösung zu verkürzen. +Wenn rerere aktiviert ist, behält Git eine Reihe von Pre- und Postimages von erfolgreichen Commits bei. Wenn es feststellt, dass ein Konflikt genauso aussieht, wie der, den Sie bereits behoben haben, wird die Korrektur vom letzten Mal verwendet, ohne nochmal nachzufragen. Diese Funktion besteht aus zwei Teilen: einer Konfigurationseinstellung und einem Befehl. Die Konfigurationseinstellung lautet `rerere.enabled`. Man kann sie in die globale Konfiguration eingeben: @@ -418,10 +417,10 @@ Die Konfigurationseinstellung lautet `rerere.enabled`. Man kann sie in die globa $ git config --global rerere.enabled true ---- -Wenn Sie nun einen merge durchführen, der die Konflikte auflöst, wird diese Auflösung im Cache gespeichert, falls Sie sie in Zukunft benötigen. +Wenn Sie nun einen merge durchführen, der Konflikte auflöst, wird diese Auflösung im Cache gespeichert, falls Sie sie in Zukunft benötigen. -Bei Bedarf können Sie mit dem Cache interagieren mittels dem Befehl `git rerere`. -Wenn es aufgerufen wird, überprüft Git seine Lösungsdatenbank und versucht eine Übereinstimmung mit aktuellen Mergekonflikten zu finden und diese zu lösen (dies geschieht jedoch automatisch, wenn `rerere.enabled` auf` true` gesetzt ist). +Bei Bedarf können Sie mit dem rerere Cache interagieren mittels des Befehls `git rerere`. +Wenn der Befehlt ausgeführt wird, überprüft Git seine Lösungsdatenbank und versucht eine Übereinstimmung mit aktuellen Mergekonflikten zu finden und diesen zu lösen (dies geschieht jedoch automatisch, wenn `rerere.enabled` auf` true` gesetzt ist). Es gibt auch Unterbefehle, um zu sehen, was aufgezeichnet wird, um eine bestimmte Konfliktlösung aus dem Cache zu löschen oder um den gesamten Cache zu löschen. Wir werden uns in <> eingehender mit rerere beschäftigen. @@ -442,7 +441,7 @@ user: "Scott Chacon " ---- Wenn Sie Ihre Tags signieren, haben Sie möglicherweise das Problem, den öffentlichen PGP-Schlüssel zu verteilen, der zum Signieren Ihrer Tags verwendet wird. -Der Betreuer des Git-Projekts hat dieses Problem behoben, indem er seinen öffentlichen Schlüssel als Blob in das Repository aufgenommen und anschließend ein enTag hinzugefügt hat, der direkt auf diesen Inhalt verweist. +Der Betreuer des Git-Projekts hat dieses Problem behoben, indem er seinen öffentlichen Schlüssel als Blob in das Repository aufgenommen und anschließend einen Tag hinzugefügt hat, der direkt auf diesen Inhalt verweist. Um dies zu tun, können Sie herausfinden, welchen Schlüssel Sie möchten, indem Sie `gpg --list-keys` ausführen: [source,console] @@ -463,7 +462,7 @@ $ gpg -a --export F721C45A | git hash-object -w --stdin 659ef797d181633c87ec71ac3f9ba29fe5775b92 ---- -Nachdem Sie nun den Inhalt Ihres Schlüssels in Git haben, können Sie einen Tag erstellen, der direkt darauf verweist, indem Sie den neuen SHA-1-Wert angeben, den Sie mit dem Befehl `hash-object` erhalten haben: +Nachdem Sie nun den Inhalt Ihres Schlüssels in Git haben, können Sie einen Tag erstellen, der direkt darauf verweist. Dies tun sie indem Sie den neuen SHA-1-Wert angeben, den Sie mit dem Befehl `hash-object` erhalten haben: [source,console] ---- @@ -485,7 +484,7 @@ Wenn Sie der Tag-Nachricht Anweisungen hinzufügen, können Sie dem Endbenutzer ==== Eine Build Nummer generieren (((build numbers)))(((git commands, describe))) -Da Git nicht über ansteigende Zahlen wie 'v123' oder das Äquivalent für jedes Commit verfügt, können Sie für dieses Commit den Befehl `git describe` ausführen, wenn Sie einen lesbaren Namen für einen Commit benötigen. +Git verfügt nicht über ansteigende Zahlen wie 'v123' oder ähnliches für jedes Commit. Wenn sie einen lesbaren Namen für ihren Commit benötigen, dann können Sie für dieses Commit den Befehl `git describe` ausführen. Als Antwort generiert Git eine Zeichenfolge, die aus dem Namen des jüngsten Tags vor diesem Commit besteht, gefolgt von der Anzahl der Commits seit diesem Tag, gefolgt von einem partiellen SHA-1-Wert des beschriebene Commits (vorangestelltem wird dem Buchstaben "g" für Git): [source,console] @@ -495,10 +494,10 @@ v1.6.2-rc1-20-g8c5b85c ---- Auf diese Weise können Sie einen Snaphot exportieren oder einen Build erstellen und einen verständlichen Namen vergeben. -Wenn Sie Git aus den Quellcode erstellen, der aus dem Git-Repository geklont wurde, erhalten Sie mit `git --version` etwas, das genau so aussieht. +Wenn Sie Git aus den Quellcode erstellen, der aus dem Git-Repository geklont wurde, erhalten Sie mit `git --version` etwas, das genauso aussieht. Wenn Sie einen Commit beschreiben, den Sie direkt getaggt haben, erhalten Sie einfach den Tag-Namen. -Standardmäßig erfordert der Befehl `git describe` mit Anmerkungen versehene Tags (Tags, die mit dem Flag `-a` oder `-s` erstellt wurden). Wenn Sie auch leichte (nicht mit Anmerkungen versehene) Tags verwenden möchten, fügen Sie dem Befehl die Option `--tags` hinzu. +Standardmäßig erfordert der Befehl `git describe` mit Anmerkungen versehene Tags (Tags, die mit dem Flag `-a` oder `-s` erstellt wurden). Wenn Sie auch leichtgewichtige (nicht mit Anmerkungen versehene) Tags verwenden möchten, fügen Sie dem Befehl die Option `--tags` hinzu. Sie können diese Zeichenfolge auch als Ziel der Befehle `git checkout` oder `git show` verwenden, obwohl sie auf dem abgekürzten SHA-1-Wert am Ende basiert, sodass sie möglicherweise nicht für immer gültig ist. Zum Beispiel hat der Linux-Kernel kürzlich einen Sprung von 8 auf 10 Zeichen gemacht, um die Eindeutigkeit von SHA-1-Objekten zu gewährleisten, sodass ältere Ausgabenamen von `git describe` ungültig wurden. @@ -507,7 +506,7 @@ Zum Beispiel hat der Linux-Kernel kürzlich einen Sprung von 8 auf 10 Zeichen ge (((releasing)))(((git commands, archive))) Nun möchten Sie einen Build freigeben. -Eines der Dinge, die Sie tun möchten, ist, ein Archiv des neuesten Schnappschusses Ihres Codes für die armen Seelen zu erstellen, die Git nicht verwenden. +Eines der Dinge, die Sie tun möchten, ist ein Archiv des neuesten Schnappschusses Ihres Codes für die armen Seelen zu erstellen, die Git nicht verwenden. Der Befehl dazu lautet `git archive`: [source,console] @@ -518,7 +517,7 @@ v1.6.2-rc1-20-g8c5b85c.tar.gz ---- Wenn jemand dieses Archiv öffnet, erhält er den neuesten Schnappschuss Ihres Projekts in einem Projektverzeichnis. -Sie können ein zip-Archiv auch auf die gleiche Weise erstellen, indem Sie jedoch die Option `--format=zip` an `git archive` übergeben: +Sie können auch ein zip-Archiv auf die gleiche Weise erstellen, indem Sie jedoch die Option `--format=zip` an `git archive` übergeben: [source,console] ---- @@ -532,8 +531,8 @@ Sie haben jetzt einen schönen Tarball und ein Zip-Archiv Ihrer Projektversion, (((git commands, shortlog))) Es ist Zeit, eine E-Mail an die Personen Ihre Mailingliste zu senden, die wissen möchten, was in Ihrem Projekt vor sich geht. -Mit dem Befehl `git shortlog` können Sie schnell eine Art Änderungsprotokoll dessen abrufen, was Ihrem Projekt seit Ihrer letzten Veröffentlichung oder E-Mail hinzugefügt wurde. -Es fasst alle Commits in dem von Ihnen angegebenen Bereich zusammen. Im Folgenden finden Sie als Beispiel 0eine Zusammenfassung aller Commits seit Ihrer letzten Veröffentlichung, sofern Ihre letzte Veröffentlichung den Namen v1.0.1 hat: +Mit dem Befehl `git shortlog` können Sie schnell eine Art Änderungsprotokoll dessen abrufen, was Ihrem Projekt seit Ihrer letzten Veröffentlichung oder ihrer letzte E-Mail hinzugefügt wurde. +Es fasst alle Commits in dem von Ihnen angegebenen Bereich zusammen. Im Folgenden finden Sie als Beispiel eine Zusammenfassung aller Commits seit Ihrer letzten Veröffentlichung, sofern Ihre letzte Veröffentlichung den Namen v1.0.1 hat: [source,console] ---- @@ -553,4 +552,4 @@ Tom Preston-Werner (4): Regenerated gemspec for version 1.0.2 ---- -Sie erhalten eine übersichtliche Zusammenfassung aller Commits seit Version 1.0.1, gruppiert nach Autoren, die Sie per E-Mail an Ihre Mailingliste senden können. +Sie erhalten eine übersichtliche Zusammenfassung aller Commits seit Version 1.0.1, gruppiert nach Autoren, die Sie per E-Mail an Ihre Mailingliste senden können. \ No newline at end of file diff --git a/book/contributors.asc b/book/contributors.asc index 8bfa48a7..f6dc3318 100644 --- a/book/contributors.asc +++ b/book/contributors.asc @@ -1,9 +1,9 @@ [preface] -== Contributors +== Mitwirkende -Since this is an Open Source book, we have gotten several errata and content changes donated over the years. -Here are all the people who have contributed to the English version of Pro Git as an open source project. -Thank you everyone for helping make this a better book for everyone. +Da es sich um ein Open Source-Buch handelt, haben wir im Laufe der Jahre verschiedene Errata und inhaltliche Änderungen erhalten. +Nachfolgend sind alle Personen aufgelistet, die zum Open Source-Projekt der deutschen Version von Pro Git beigetragen haben. +Vielen Dank an alle, die mitgeholfen haben, dieses Buch zu verbessern. [source,tabsize=8] ---- diff --git a/book/dedication.asc b/book/dedication.asc index 24b706fe..328a1bd1 100644 --- a/book/dedication.asc +++ b/book/dedication.asc @@ -1,15 +1,5 @@ [dedication] -== Dedications - -_To my wife, Becky, without whom this adventure never would have begun. — Ben_ - -_This edition is dedicated to my girls. -To my wife Jessica who has supported me for all of these years and to my daughter Josephine, -who will support me when I'm too old to know what's going on. — Scott_ - -=== - -==== Widmungen +== Widmungen _An meine Frau Becky, ohne die dieses Abenteuer nie begonnen hätte. – Ben_ diff --git a/book/license.asc b/book/license.asc index 490603e1..8fdebd05 100644 --- a/book/license.asc +++ b/book/license.asc @@ -1,4 +1,4 @@ [preface] -== Licence +== Lizenz include::../LICENSE.asc[] diff --git a/status.json b/status.json index 49152309..4cd5248a 100644 --- a/status.json +++ b/status.json @@ -48,7 +48,7 @@ "1-distributed-git.asc": 100, "sections/contributing.asc": 100, "sections/distributed-workflows.asc": 100, - "sections/maintaining.asc": 0 + "sections/maintaining.asc": 100 }, "06-github": { "1-github.asc": 100,