diff --git a/.gitignore b/.gitignore index 424a30e5..724ad441 100644 --- a/.gitignore +++ b/.gitignore @@ -9,4 +9,4 @@ progit.pdfmarks progit.epub progit-kf8.epub progit.mobi -contributors.txt \ No newline at end of file +contributors.txt diff --git a/CONTRIBUTING.asc b/CONTRIBUTING.asc new file mode 100644 index 00000000..acc0ab0a --- /dev/null +++ b/CONTRIBUTING.asc @@ -0,0 +1,44 @@ += Zur Übersetzung der zweiten Auflage von Git Pro beitragen + +== Lizenz + +Mit Erzeugen eines Pull-Requests für dieses Repository stimmen Sie zu, dass Ihre Arbeit unter die angegebene link:LICENSE.asc[Projektlizenz] gestellt wird. +Außerdem erklären Sie sich damit einverstanden, eine solche Lizenz an Ihrer Arbeit den Hauptautoren @ben und @schacon zu gewähren, die sie für zukünftige, gedruckte Ausgaben benötigen. +Sollten Ihre Änderungen in einer gedruckten Fassung erscheinen, so werden Sie in die Liste der link:book/contributors.asc[Mitwirkenden] aufgenommen. + +== Ein Problem melden + +Bevor Sie ein Problem melden, bitten wir Sie zu überprüfen, ob sich nicht ein ähnliches oder gar dasselbe Problem bereits im Bugtracking-System befindet. + +Wenn das Problem auch auf der link:https://git-scm.com[Git-Website] zu finden ist, überprüfen Sie bitte auch, ob das Problem dort noch aktuell ist. Es könnte schon erledigt, aber noch nicht veröffentlicht sein. + +== Kleinere Korrekturen + +Fehlerkorrekturen und grundlegende Klarstellungen werden akzeptiert, wenn wir uns einig sind, dass sie den Inhalt verbessern. +Sie können auch ein Issue eröffnen, damit wir herausfinden können, wie oder ob es gelöst werden muss. + +Wenn Sie dies noch nie zuvor getan haben, kann der link:https://guides.github.com/introduction/flow/[Flow Guide] hilfreich sein. + +== Größere Änderungen + +Öffnen Sie ein Issue zur Diskussion, bevor Sie beginnen. +Diese Veränderungen sind in der Regel sehr subjektiv, oft nur klärende Dinge für einen kleinen Prozentsatz der Menschen und es lohnt sich selten, sie zu akzeptieren. +Professionelle Textredakteure haben diesen Inhalt bereits mehrmals überprüft, so dass es unwahrscheinlich ist, dass Ihre Texte so viel besser werden, dass es sich lohnt, große Textmengen zu ändern, obwohl Sie vielleicht einen etwas besseren Geschmack und bessere Grammatik haben als wir. + +== Abbildungen + +Die Bilder in diesem Buch wurden mit link:https://www.sketchapp.com/[Sketch 3] und der link:https://github.com/progit/progit2/blob/master/diagram-source/progit.sketch[mitgelieferten Sketchbook-Datei] erstellt. + +Um eine Abbildung einzufügen: + +1. Fügen Sie eine Seite zum Sketchbook hinzu. Versuchen Sie möglichst die enthaltenen Symbole zu verwenden. +2. Fügen Sie Ihrer Seite ein „Slice“ hinzu. Geben Sie ihm einen Namen, der mit dem PNG-Dateinamen des Ziels übereinstimmt, relativ zur Root des Quellverzeichnisses. +3. Vergewissern Sie sich, dass Ihr Slice so eingestellt ist, dass er mit „800w“ exportiert wird. + +== Übersetzungen + +Wenn Sie einen Beitrag zur Übersetzung von Pro Git in Ihre Sprache leisten möchten, werfen Sie einen Blick auf link:https://github.com/progit/progit2/blob/master/TRANSLATING.md[TRANSLATING.md]. + +== Weiterführende Hinweise zur deutschen Übersetzung + +Alle weiterführenden Hinweise zur deutschen Übersetzung finden sie im Dokument link:TRANSLATION_NOTES_DE.asc[Hinweise zur deutschen Übersetzung]. diff --git a/LICENSE.asc b/LICENSE.asc index 5aceb9e9..be3737ab 100644 --- a/LICENSE.asc +++ b/LICENSE.asc @@ -1,2 +1,2 @@ -This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. -To view a copy of this license, visit https://creativecommons.org/licenses/by-nc-sa/3.0 or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. +Dieses Werk ist lizensiert unter der „Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported“ Lizenz. +Um eine Kopie dieser Lizenz zu lesen, besuchen Sie https://creativecommons.org/licenses/by-nc-sa/3.0 oder senden Sie einen Brief an Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. diff --git a/README.asc b/README.asc index d3728c4e..878d78cb 100644 --- a/README.asc +++ b/README.asc @@ -1,21 +1,21 @@ -= Pro Git, Second Edition += Pro Git: Zweite Auflage -Welcome to the second edition of the Pro Git book. +Herzlich willkommen bei der zweiten Auflage des Buchs „Pro Git“. -You can find this book online at: https://git-scm.com/book +Sie finden dieses Buch online unter: https://git-scm.com/book/de/v2 -Like the first edition, the second edition of Pro Git is open source under a Creative Commons license. +Wie die erste, ist auch die zweite Auflage von *Pro Git* Open Source und steht unter der Creative Commons-Lizenz. -A couple of things have changed since open sourcing the first edition. -For one, we've moved from Markdown to the amazing Asciidoc format for the text of the book. +Im Vergleich zur ersten Auflage haben sich in der zweiten Auflage allerdings ein paar Dinge geändert: +Unter anderem haben wir von Markdown auf das fantastische Asciidoc-Format für den Text des Buches umgestellt. -We've also moved to keeping the translations in separate repositories rather than subdirectories of the English repository. -See link:TRANSLATING.md[the translating document] for more information. +Statt eines großen Repositorys für alle Sprachen wird jede Sprache mittlerweile in einem eigenen Repository verwaltet. +In den Dokumenten link:TRANSLATING.md[Pro Git Übersetzung] und link:TRANSLATION_NOTES_DE.asc[Hinweise zur deutschen Übersetzung] finden Sie weitere Informationen. -== How To Generate the Book +== Wie kann das Buch erstellt werden? -You can generate the e-book files manually with Asciidoctor. -If you run the following you _may_ actually get HTML, Epub, Mobi and PDF output files: +Sie können die E-Book-Dateien manuell mit Asciidoctor erzeugen. +Wenn Sie die folgenden Befehle ausführen, können Sie auch HTML-, Epub-, Mobi- und PDF-Ausgabedateien erhalten: ---- $ bundle install @@ -30,13 +30,13 @@ Converting to PDF... -- PDF output at progit.pdf ---- -== Signaling an Issue +== Ein Problem melden -Before signaling an issue, please check that there isn't already a similar one in the bug tracking system. +Bevor Sie ein Problem melden, bitten wir Sie zu überprüfen, ob sich nicht ein ähnliches oder gar dasselbe Problem bereits im Bugtracking-System befindet. -Also, if this issue has been spotted on the git-scm.com site, please cross-check that it is still present in this repo. -The issue may have already been corrected, but the changes have not been deployed yet. +Wenn Sie dieses Problem auf der Website git-scm.com entdeckt haben, überprüfen Sie bitte nochmals, ob es in diesem Repo noch vorhanden ist. +Das Problem wurde eventuell schon behoben, aber die Änderungen noch nicht eingespielt. -== Contributing +== Mithelfen -If you'd like to help out by making a change, take a look at the link:CONTRIBUTING.md[contributor's guide]. +Wenn Sie uns bei der Übersetzung helfen wollen, sei es um einen Text neu zu übersetzen oder einen Rechtschreibfehler zu verbessern, finden Sie in dem Dokument link:CONTRIBUTING.asc[Contributor Guide] weitere Informationen. diff --git a/Special_Characters.asc b/Special_Characters.asc new file mode 100644 index 00000000..79dd0f23 --- /dev/null +++ b/Special_Characters.asc @@ -0,0 +1,84 @@ +== Sonderzeichen + +Die Tabelle ist noch in Arbeit (vorläufiger Inhalt). + +Der Inhalt dieser Datei soll auch im Wiki zu sehen sein. + +Die Eingabe von Sonderzeichen mit der normalen Standard-Tastatur ist je nach Betriebssystem und, bei Linux auch je nach Distribution/WM-Manager verschieden und kann unterschiedlich kompliziert sein. + +Das Ziel dieser Datei ist es, für die häufigsten Sonderzeichen ein `copy + paste` zu ermöglichen. + +Falls für ein notwendiges Sonderzeichen in der folgenden Tabelle kein Eintrag vorhanden ist, sollten Sie entweder selbst einen Vorschlag machen oder über „New Issue“ eine Nachricht hinterlassen. + +[TIP] +==== +Bei den Windows und macOS Shortcuts werden die Zusatztasten (strg, alt, shift) gehalten und dann der Code bzw. Zweittaste eingegeben. + +Die Ziffern in den Windows Shortcuts *müssen* über den Nummernblock eingegeben werden. +==== + +.Sonderzeichen +[cols="1,2,2,2,2,2,5", options="header"] +|=== +|Sonderzeichen |Name (de/en) |UTF-Code (hex) |HTML-Entity |Windows Shortcut |macOS Shortcut |Bemerkung +|– +|Bindestrich, Halbgeviert-Strich + +/ hyphen +|U+2013 +|\– +|`alt (+) 0150` +|`alt (+) -` +|ersetzt doppeltes + +- Zeichen (--) der Sourcetexte – +ist sehr häufig mit falsch gesetzten Minus-Zeichen zu tauschen + +(siehe link:https://de.wikipedia.org/wiki/Typografische_Zeichen_in_HTML#Striche[Wikipedia]) + +|— +|Gedankenstrich, Geviert-Strich + +/ em dash +|U+2014 +|\— +|`alt (+) 0151` +| +|wird in deutschen Texten selten verwendet + +|… +|Auslassungspunkte + +/ three dot leader +|U+2026 +|\… +|`alt (+) 0133` +|`alt (+) .` +| + +|„ +|Anführung, links unten +|U+201C +|\„ +|`alt (+) 0132` +|`alt (+) shift (+) W` +|nicht in Code-Beispielen verwenden + +|“ +|Anführung, rechts oben +|U+201C +|\“ +|`alt (+) 0147` +|`alt (+) 2` +|nicht in Code-Beispielen verwenden + +|‚ +|einfach Anführung, links unten +|U+201A +|\‚ +|`alt (+) 0130` +|`alt (+) s` +|nicht in Code-Beispielen verwenden + +|‘ +|einfach Anführung, rechts oben +|U+2018 +|\‘ +|`alt (+) 0145` +|`alt (+) #` +|nicht in Code-Beispielen verwenden diff --git a/TRANSLATING.md b/TRANSLATING.md index e7d630e5..efe309bd 100644 --- a/TRANSLATING.md +++ b/TRANSLATING.md @@ -1,26 +1,26 @@ -# Translating Pro Git (2nd Edition) +# Pro Git Übersetzung (2. Edition) -The translations are managed in a decentralized way. Each translation team maintains their own project. Each translation is in its own repository, the Pro Git team simply pulls the changes and builds them into the https://git-scm.com website when ready. +Die Übersetzungen werden dezentral verwaltet. Jedes Übersetzungsteam pflegt sein eigenes Projekt. Jede Übersetzung befindet sich in einem eigenen Repository, das Pro Git-Team zieht einfach die Änderungen und baut sie nach Fertigstellung in die Website https://git-scm.com ein. -## General guidance for translating Pro Git +## Allgemeine Hinweise zur Übersetzung von Pro Git -Pro Git is a book about a technical tool, therefore translating it is difficult compared to a non-technical translation. +Pro Git ist ein Buch über ein technisches Werkzeug, daher ist die Übersetzung im Vergleich zu einer nicht-technischen Übersetzung schwierig. -The following are guidelines to help you on your way: -* Before you begin, read the whole Git Pro book in English, so that you're aware of the content, and are familiar with the style used. -* Ensure you have a good working knowledge of git, so that explaining the technical terms is doable. -* Stick to a common style and format for the translation. -* Be sure to read and understand the basics of [Asciidoc formatting](https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/). Not following the asciidoc syntax can lead to problems with building/compilation of the pdf, epub and html files needed for the book. +Die folgenden Richtlinien sollen Ihnen auf Ihrem Weg helfen: +* Bevor Sie beginnen, lesen Sie das gesamte Git Pro Buch auf Englisch, damit Sie den Inhalt kennen und mit dem verwendeten Stil vertraut werden. +* Stellen Sie sicher, dass Sie über gute Grundkenntnisse in git verfügen, so dass die Erklärung der Fachbegriffe möglich ist. +* Halten Sie sich an einen gemeinsamen Stil und ein gemeinsames Format für die Übersetzung. +* Lesen und verstehen Sie unbedingt die Grundlagen der [Asciidoc-Formatierung](https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/). Die Nichteinhaltung der asciidoc-Syntax kann zu Problemen beim Erstellen/Kompilieren der für das Buch benötigten pdf-, epub- und html-Dateien führen. -## Translating the book to another language +## Das Buch in eine andere Sprache übersetzen -### Helping with a existing project +### Mithilfe bei einem bestehenden Projekt -* Check for an already existing project in the following table. -* Go to the project's page on GitHub. -* Open an issue, introduce yourself and ask where you can help. +* Suchen Sie in der folgenden Tabelle nach einem bereits vorhandenen Projekt. +* Gehen Sie auf die GitHub-Projektseite. +* Eröffnen Sie ein Issue, stellen Sie sich vor und fragen Sie, wo Sie helfen können. -| Language | GitHub page | +| Sprache | GitHub Projektseite | | :------------- | :------------- | | العربية | [progit2-ar/progit2](https://github.com/progit2-ar/progit2) | | Беларуская | [progit/progit2-be](https://github.com/progit/progit2-be) | @@ -51,55 +51,55 @@ The following are guidelines to help you on your way: | 简体中文 | [progit/progit2-zh](https://github.com/progit/progit2-zh) | | 正體中文 | [progit/progit2-zh-tw](https://github.com/progit/progit2-zh-tw) | -### Starting a new translation +### Eine neue Übersetzung beginnen -If there is no project for your language, you can start your own translation. +Wenn es noch kein Projekt für Ihre Sprache gibt, können Sie eine eigene Übersetzung starten. -Base your work on the second edition of the book, available [here](https://github.com/progit/progit2). To do so: - 1. Pick the correct [ISO 639 code](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) for your language. - 1. Create a [GitHub organization](https://help.github.com/articles/creating-a-new-organization-from-scratch/), for example: `progit2-[your code]` on GitHub. - 1. Create a project ``progit2``. - 1. Copy the structure of progit/progit2 (this project) in your project and start translating. +Grundlage Ihrer Arbeit ist die zweite Ausgabe des Buches, die [hier](https://github.com/progit/progit2) verfügbar ist. So sollten Sie vorgehen: + 1. Wählen Sie den richtigen [ISO 639-Code](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) für Ihre Sprache. + 1. Erstellen Sie eine [GitHub-Organisation](https://help.github.com/articles/creating-a-new-organization-from-scratch/), z.B. `progit2-[your code]` auf GitHub. + 1. Erstellen Sie ein Projekt ``progit2``. + 1. Kopieren Sie die Struktur von progit/progit2 (dieses Projekt) in Ihr Projekt und beginnen Sie mit der Übersetzung. -### Updating the status of your translation +### Den Bearbeitungsstatus Ihrer Übersetzung aktualisieren -On https://git-scm.com, the translations are divided into three categories. Once you have reached one of these levels, contact the maintainers of https://git-scm.com/ so that they can pull the changes. +Auf https://git-scm.com sind die Übersetzungen in drei Kategorien eingeteilt. Sobald Sie eine dieser Levels erreicht haben, kontaktieren Sie die Betreuer von https://git-scm.com/, damit sie die Änderungen übernehmen können. -| Category | Completion | +| Kategorie | fertiggestellt | | :------------- | :------------- | -| Translation started for | Introduction translated, not much else. | -| Partial translations available in | up to chapter 6 has been translated. | -| Full translation available in |the book is (almost) fully translated. | +| Übersetzung begonnen für | Einführung übersetzt, sonst nicht viel. | +| unvollständige Übersetzungen verfügbar in | übersetzt bis Kapitel 6. | +| Vollständige Übersetzung verfügbar in | das Buch ist (fast) vollständig übersetzt. | -## Continuous integration with Travis CI +## Kontinuierliche Integration mit Travis CI -Travis CI is a [continuous integration](https://en.wikipedia.org/wiki/Continuous_integration) service that integrates with GitHub. Travis CI is used to ensure that a pull-request doesn't break the build or compilation. Travis CI can also provide compiled versions of the book. +Travis CI ist ein Dienst für [kontinuierliche Integration](https://en.wikipedia.org/wiki/Continuous_integration), der in GitHub integriert werden kann. Travis CI wird verwendet, um sicherzustellen, dass eine Pull-Anforderung den Build oder die Kompilierung nicht unterbricht. Travis CI kann auch kompilierte Versionen des Buches zur Verfügung stellen. -Setting up Travis CI requires administrative control over the repository. +Die Einrichtung von Travis CI erfordert eine administrative Kontrolle über das Repository. -### Registering for Travis continuous integration +### Registrierung für die kontinuierliche Integration von Travis -1. Register a Travis account [here](https://travis-ci.org/). -1. Register your project in Travis. -Please refer to the [Travis documentation](https://docs.travis-ci.com/) for more information. +1. Ein Travis-Konto [hier](https://travis-ci.org/) einrichten. +1. Registrieren Sie Ihr Projekt in Travis. +Weitere Informationen finden Sie in der [Travis-Dokumentation](https://docs.travis-ci.com/). -### Setting up your repository for continuous integration +### Einrichten Ihres Repositorys für eine kontinuierliche Integration -Travis CI works by scanning your project's root directory for a file named `.travis.yml` and following the 'recipe' that it contains. The good news is: there's already a working `.travis.yml` file in the Pro Git 2 source [here](https://raw.githubusercontent.com/progit/progit2-pub/master/travis.yml). -Copy that file, and put it in your working directory. Commit the .yml file and push it to your translation repository; that should fire up a compilation and a check of the book's contents. +Travis CI scannt das Stammverzeichnis Ihres Projekts nach einer Datei mit dem Namen `.travis.yml` und folgt dem darin enthaltenen „Rezept“. Die gute Nachricht ist: Es gibt bereits eine funktionierende `.travis.yml` Datei im Pro Git 2 Quellcode [hier](https://raw.githubusercontent.com/progit/progit2-pub/master/travis.yml). +Kopieren Sie diese Datei und legen Sie sie in Ihr Arbeitsverzeichnis. Commitieren Sie die .yml-Datei und verschieben Sie sie in Ihr Übersetzungs-Repository; das sollte eine Kompilierung und eine Überprüfung des Inhalts des Buches auslösen. -## Setting up a publication chain for e-books +## Einrichtung einer Publikationskette für E-Books -This is a technical task, please ping @jnavila to get started with epub publication. +Das ist eine technische Sache, bitte kontaktieren Sie @jnavila, um mit der Veröffentlichung von epub zu beginnen. -## Beyond Pro Git +## Abgesehen von Pro Git -Translating the book is the first step. Once this is finished, you could consider translating the user interface of Git itself. +Die Übersetzung des Buches ist der erste Schritt. Sobald das fertig ist, können Sie die Benutzeroberfläche von Git selbst übersetzen. -This task requires a more technical knowledge of the tool than the book. Hopefully, after having translated the full book content, you can understand the terms used in the application. If you feel technically up to the task, the repo is [here](https://github.com/git-l10n/git-po) and you just have to follow the [guide](https://github.com/git-l10n/git-po/blob/master/po/README). +Diese Aufgabe erfordert ein besseres technisches Wissen über das Tool als das Buch. Hoffentlich können Sie nach der Übersetzung des gesamten Buchinhalts die in der Anwendung verwendeten Begriffe verstehen. Wenn Sie sich der Aufgabe technisch gewachsen fühlen, ist das Repo [hier](https://github.com/git-l10n/git-po) und Sie müssen nur der [Anleitung](https://github.com/git-l10n/git-po/blob/master/po/README). -Beware though that +Beachten Sie jedoch, dass - * you'll need to use more specific tools to manage localization po files (such as editing them with [poedit](https://poedit.net/) and merging them. You might need to compile git in order to check your work. - * a basic knowledge of how translating applications works is required, which is significantly different from translating books. - * the core Git project uses more stringent [procedures](https://github.com/git-l10n/git-po/blob/master/Documentation/SubmittingPatches) to accept contributions, be sure to abide by them. + * Sie speziellere Tools verwenden müssen, um die Lokalisierungs-Po-Dateien zu handhaben (z.B. um sie mit [poedit](https://poedit.net/) zu bearbeiten) und sie zusammenzuführen. Möglicherweise müssen Sie git kompilieren, um Ihre Arbeit zu überprüfen. + * ein grundlegendes Verständnis über die Übersetzung von Anwendungen erforderlich ist, die sich deutlich von der Übersetzung von Büchern unterscheidet. + * das Core-Projekt Git strengere [Vorschriften](https://github.com/git-l10n/git-po/blob/master/Documentation/SubmittingPatches) für die Annahme von Beiträgen anwendet. Achten Sie darauf, diese einzuhalten. diff --git a/TRANSLATION_NOTES.asc b/TRANSLATION_NOTES.asc index aab7e602..592ac9bd 100644 --- a/TRANSLATION_NOTES.asc +++ b/TRANSLATION_NOTES.asc @@ -1,11 +1,13 @@ -== Translation Notes += Hinweise zur Übersetzung -After forking this repository to translate the work, this file is where the notes for coordinating the translation work would go. -Things like standardizing on words and expressions so that the work is consistent or notes on how the contributing process is to be handled. +Nachdem dieses Repository für die Übersetzung der Arbeit freigegeben wurde, werden in dieser Datei die Hinweise zur Koordination der Übersetzungsarbeit angezeigt. +Zum Beispiel die Standardisierung von Wörtern und Ausdrücken, damit die Arbeit konsistent ist, oder Hinweise darauf, wie der beitragende Prozess zu handhaben ist. -As a translation maintainer, also feel free to modify or completely rewrite the README file to contain instructions specific to your translation. +Als Übersetzungsmanager können Sie die README-Datei auch ändern oder komplett neu schreiben, mit Anweisungen, die speziell auf Ihre Übersetzung zugeschnitten sind. + +In den Dokumenten link:TRANSLATING.md[Pro Git Übersetzung] und link:TRANSLATION_NOTES_DE.asc[Hinweise zur deutschen Übersetzung] finden Sie weitere Informationen. === Translation Status -As the work is translated, please update the `status.json` file to indicate the rough percentage complete each file is. -This will be shown on various pages to let people know how much work is left to be done. +Wenn die Arbeit übersetzt ist, aktualisieren Sie bitte die Datei `status.json`, um den groben Prozentsatz der Fertigstellung jeder Datei anzugeben. +Dies wird auf verschiedenen Seiten gezeigt, um den Leuten mitzuteilen, wie viel Arbeit noch zu tun ist. diff --git a/TRANSLATION_NOTES_DE.asc b/TRANSLATION_NOTES_DE.asc new file mode 100644 index 00000000..99f8bb33 --- /dev/null +++ b/TRANSLATION_NOTES_DE.asc @@ -0,0 +1,155 @@ += Hinweise zur deutschen Übersetzung + +In diesem Dokument werden alle Informationen rund um die deutsche Übersetzung gesammelt. Hiermit möchten wir beispielsweise festlegen, ob der Leser mit „Du“ oder „Sie“ angesprochen wird, ob der Erzähler die 1. Person Singular oder die 1. Person Plural verwendet oder wie technische Fachbegriffe übersetzt werden sollen. + +== Übersetzungsfortschritt + +Beim Übersetzen sollte, zusätzlich zur eigentlichen Übersetzung, der Fortschritt jedes Kapitels in der Datei link:./status.json[`status.json`] hinterlegt werden. Diese Prozentangabe wird auf verschiedenen Seiten verwendet, um die Leser über den Fortschritt der jeweiligen Übersetzung zu informieren. + +== Workflow Git + +Wenn Sie an der deutschen Übersetzung mitarbeiten wollen, können Sie dazu ein link:https://git-scm.com/book/de/v1/Distribuierte-Arbeit-mit-Git-xxx-An-einem-Projekt-mitarbeiten#Kleine,-öffentliche-Projekte[Fork] erstellen und in diesem weiterarbeiten. + +* Bitte erstellen Sie erst dann einen Pull-Request, wenn Sie ein Arbeitspaket abgeschlossen haben. Bitte beschreiben Sie im Pull-Request, was Ihr zu mergender Branch enthält (neue Übersetzungen, Korrekturen usw.). + +* Wir werden Ihren Beitrag prüfen und ein weiterer Helfer wird Ihr Ergebnis Korrektur lesen (Review). Das kann dazu führen, dass Sie Ihre Arbeit noch einmal überarbeiten müssen. Bitte sehen Sie das Review als positive Hilfestellung, damit das Ergebnis insgesamt besser wird, und nehmen Sie die Kritik nicht negativ auf. Wir wollen damit sicherstellen, dass die deutsche Übersetzung einheitlicher wird und in einer guten Qualität zur Verfügung steht. Wenn alles passt, nehmen wir das Ergebnis in den Hauptzweig auf und veröffentlichen es für die bekannten Seiten. + +* Wenn Ihr Ergebnis sehr weit vom Master-Zweig abweicht, kann es passieren, dass wir Sie um einen link:https://git-scm.com/book/de/v1/Git-Branching-Rebasing[Rebase] bitten. + +* Da bei der deutschen Übersetzung ausschließlich deutschsprachige Mitarbeiter mitwirken, sollte die Commit-Beschreibung auf Deutsch erfolgen. Bitte wenden Sie die üblichen Git Commit-Beschreibungskonventionen an. + +== Übersetzungs-Workflow + +* Falls Sie einen Abschnitt übersetzen möchten, der noch nicht übersetzt wurde, sollten Sie nach der Übersetzung den englischen Text entfernen. Bitte entfernen Sie den englischen Text nur für die Passagen, die Sie auch tatsächlich bereits übersetzt haben. + +* Kommandozeilenausgaben sollten so übersetzt werden, dass sie mit der deutschen Version von Git übereinstimmen. Im Zweifel belassen Sie bitte die Kommandozeilenausgabe in Englisch. + +== Allgemeine Regeln + +* Der Leser wird formal mit „Sie“ angesprochen, wobei das „Sie“ auch großgeschrieben wird. Bitte beachten Sie dies auch bei Possessivpronomen, wie beispielsweise „Ihr“, „Ihre“ usw. gilt. Siehe hierzu auch link:http://www.duden.de/sprachwissen/sprachratgeber/gross-oder-kleinschreibung-von--em-du-du--em--und--em-ihr-ihr--em--1[folgender Link]. Andere Sprachen verwenden ebenfalls die formelle Form, wie link:https://github.com/progit/progit2/issues/151[hier] beschrieben. + +== Schreibweise und Übersetzung von Fachbegriffen + +=== Typografie + +Die typografisch korrekte Schreibweise in deutschen Texten enthält ein paar Besonderheiten, die sich optisch doch recht stark von der Schreibweise in englischen Texten unterscheiden. +Um für die Leser ein möglichst vertrautes Schriftbild zu erreichen, sollten wir die folgenden Hinweise konsequent umsetzen. + +Leider ist es nicht möglich einige dieser Sonderzeichen mit der Standardtastatur direkt zu erreichen. +Glücklicherweise können diese Sonderzeichen aber über einen UTF-Code identifiziert und damit übernommen werden. + +Unter Windows (schon seit dem Urahn Windows 3.11) gibt man mit `alt + ` einen String ein, der das Sonderzeichen ausgibt (eine grafische Auflistung kann man mit dem System-Tool „Zeichentabelle“ erhalten). + +Für MacOS X ist link:https://www.die-tastenkombination.de/tastenkombinationen-mac-os-sonderzeichen.html[hier] und link:https://www.maclife.de/tipps-tricks/mac-os-x/drei-wege-zum-sonderzeichen-unter-os-x[hier] eine Auflistung bzw. eine Anleitung zu sehen. Außerdem können mit dem System-Tool „Zeichenübersicht“ alle verfügbaren Zeichen angezeigt werden. + +Bei Linux gibt es zu viele Distributionen und verschiedene Desktop-GUIs, die jeweils unterschiedliche Vorgehensweisen erfordern, um sie in diesem Rahmen erschöpfend auflisten zu können. + +Für die häufigsten Sonderzeichen stellen wir link:Special_Characters.asc[hier] eine Tabelle zur Verfügung, aus der man per `copy+paste` die Sonderzeichen in eigene Texte übernehmen kann. + +=== Begriffe + +Die Übersetzungen orientieren sich an der deutschen Übersetzung der Programmdatei von git (`/usr/bin/git` beziehungsweise `git.exe`). + +Wenn ein Fachbegriff in der folgenden Liste fehlt, überprüfen Sie bitte, ob dieser in der Git-Programmdatei verwendet wird (siehe hierzu link:https://github.com/git/git/blob/master/po/de.po[folgenden Link]). + +Bitte erfinden Sie keine neue deutsche Übersetzung, sondern orientieren Sie sich bitte an der nachfolgenden Liste oder an der deutschen Übersetzung der Git-Programmdatei. + +=== A – D + +[width="100%", frame="topbot", options="header,footer"] +|============================================================================== +|Englisch|Deutsch +|Branch| +Branch; Singular: der Branch; Plural: die Branches; Alternativ kann auch die deutsche Übersetzung „Zweig“ verwendet werden +|Branchname| +Branchname; Singular: der Branchname; Plural: die Branchnamen +|To clone| +Klonen; Ein Repository klonen +|Clone| +Klon; Singular: der Klon; Plural: – +|Commit| +Commit; Singular: der Commit; Plural: die Commits +|To commit| +Committen; er/sie committet; wir committen; Alternativ: Einchecken +|Commit date| +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 message| +Commit-Beschreibung; Singular: die Commit-Beschreibung; Plural: die Commit-Beschreibungen; +Alternativ: die Commit-Nachricht +|Diff| +Diff; Singular: der Diff; Plural: die Diffs; Alternativ: der Vergleich, Ausgabe eines Vergleichs +|============================================================================== + +=== E – J + +[width="100%", frame="topbot", options="header,footer"] +|============================================================================== +|Englisch|Deutsch +|HEAD| +HEAD; Singular: der HEAD; Plural: –; Oft kann HEAD ohne Artikel verwendet werden +|Index| +Staging-Area; Singular: die Staging-Area; Alternativ: der Index +|============================================================================== + +=== K – Q + +[width="100%", frame="topbot", options="header,footer"] +|============================================================================== +|Englisch|Deutsch +|to merge| +mergen, auch zusammenführen oder verschmelzen +|Merging| +Merging +|============================================================================== + + +=== R – T + +[width="100%", frame="topbot", options="header,footer"] +|============================================================================== +|Englisch|Deutsch +|remote| +entfernt, auch extern (je nach Kontext) oder Remote-... +|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] +|Remote repository| +Remote-Repository; Singular: das Remote-Repository; Plural: die Remote-Repositorys +|SHA1 hash| +SHA1 Hash; Singular: der SHA1 Hash; Plural: die SHA1 Hashes +|Snapshot| +Snapshot; Singular: der Snapshot; Plural: die Snapshots; Alternativ kann auch Schnappschuss verwendet werden, häufiger verwendet man allerdings den englischen Begriff +|to stage| +zum Commit vormerken; zur Staging-Area hinzufügen +|staged| +zum Commit vorgemerkt; zur Staging-Area hinzugefügt +|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) +|to track| +versionieren; Zur Versionsverwaltung hinzufügen, auch verfolgen (ev. mit Hinweis: engl. tracked, je nach Kontext) +|============================================================================== + +=== U – Z + +[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 +|working tree| +Verzeichnisbaum +|============================================================================== + +== Als Maintainer helfen + +Wenn Sie nicht nur zur Übersetzung beitragen möchten, sondern uns auch bei der Koordination unterstützen wollen, dann melden Sie sich bitte bei einem Maintainer. diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index c76cf150..68a68b92 100644 --- a/book/01-introduction/sections/about-version-control.asc +++ b/book/01-introduction/sections/about-version-control.asc @@ -1,61 +1,61 @@ -=== About Version Control +=== Was ist Versionsverwaltung? -(((version control))) -What is ``version control'', and why should you care? -Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. -For the examples in this book, you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer. +(((Versionsverwaltung))) +Was ist „Versionsverwaltung“, und warum sollten Sie sich dafür interessieren? +Versionsverwaltung ist ein System, welches die Änderungen an einer oder einer Reihe von Dateien über die Zeit hinweg protokolliert, sodass man später auf eine bestimmte Version zurückgreifen kann. +Die Dateien, die in den Beispielen in diesem Buch unter Versionsverwaltung gestellt werden, enthalten Quelltext von Software, tatsächlich kann in der Praxis nahezu jede Art von Datei per Versionsverwaltung nachverfolgt werden. -If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use. -It allows you to revert selected files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. -Using a VCS also generally means that if you screw things up or lose files, you can easily recover. -In addition, you get all this for very little overhead. +Als Grafik- oder Webdesigner möchte man zum Beispiel in der Lage sein, jede Version eines Bildes oder Layouts nachverfolgen zu können. Als solcher wäre es deshalb ratsam, ein Versionsverwaltungssystem (engl. Version Control System, VCS) einzusetzen. +Ein solches System erlaubt es, einzelne Dateien oder auch ein ganzes Projekt in einen früheren Zustand zurückzuversetzen, nachzuvollziehen, wer zuletzt welche Änderungen vorgenommen hat, die möglicherweise Probleme verursachen, herauszufinden wer eine Änderung ursprünglich vorgenommen hat und viele weitere Dinge. +Ein Versionsverwaltungssystem bietet allgemein die Möglichkeit, jederzeit zu einem vorherigen, funktionierenden Zustand zurückzukehren, auch wenn man einmal Mist gebaut oder aus irgendeinem Grunde Dateien verloren hat. +All diese Vorteile erhält man für einen nur sehr geringen, zusätzlichen Aufwand. -==== Local Version Control Systems +==== Lokale Versionsverwaltung -(((version control,local))) -Many people's version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they're clever). -This approach is very common because it is so simple, but it is also incredibly error prone. -It is easy to forget which directory you're in and accidentally write to the wrong file or copy over files you don't mean to. +(((Versionswerwaltung,lokal))) +Viele Menschen betreiben Versionsverwaltung, indem sie einfach all ihre Dateien in ein separates Verzeichnis kopieren (die Schlaueren darunter verwenden ein Verzeichnis mit Zeitstempel im Namen). +Diese Vorgehensweise ist sehr weit verbreitet und wird gern verwendet, weil sie so einfach ist. Aber sie ist eben auch unglaublich fehleranfällig. +Man arbeitet sehr leicht im falschen Verzeichnis, bearbeitet damit die falschen Dateien oder überschreibt Dateien, die man eigentlich nicht überschreiben wollte. -To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control. +Aus diesem Grund, haben Programmierer bereits vor langer Zeit, lokale Versionsverwaltungssysteme entwickelt, die alle Änderungen an allen relevanten Dateien in einer Datenbank verwalten. -.Local version control. +.Lokale Versionsverwaltung image::images/local.png[Local version control diagram] -One of the most popular VCS tools was a system called RCS, which is still distributed with many computers today. -RCS works by keeping patch sets (that is, the differences between files) in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches. +Eines der populäreren Versionsverwaltungssysteme war RCS, welches auch heute noch mit vielen Computern ausgeliefert wird. +https://www.gnu.org/software/rcs/[RCS] arbeitet nach dem Prinzip, dass für jede Änderung ein Patch (ein Patch umfasst alle Änderungen an einer oder mehreren Dateien) in einem speziellen Format auf der Festplatte gespeichert wird. Um eine bestimmte Version einer Datei wiederherzustellen, wendet es alle Patches bis zur gewünschten Version an und rekonstruiert damit die Datei in der gewünschten Version. -==== Centralized Version Control Systems +==== Zentrale Versionsverwaltung -(((version control,centralized))) -The next major issue that people encounter is that they need to collaborate with developers on other systems. -To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. -These systems (such as CVS, Subversion, and Perforce) have a single server that contains all the versioned files, and a number of clients that check out files from that central place. (((CVS)))(((Subversion)))(((Perforce))) -For many years, this has been the standard for version control. +(((Versionsverwaltung, zentral))) +Ein weiteres großes Problem, mit dem sich viele Leute dann konfrontiert sahen, bestand in der Zusammenarbeit mit anderen Entwicklern auf anderen Systemen. +Um dieses Problem zu lösen, wurden zentralisierte Versionsverwaltungssysteme entwickelt (engl. Centralized Version Control System, CVCS). +Diese Systeme, wozu beispielsweise CVS, Subversion und Perforce gehören, basieren auf einem zentralen Server, der alle versionierten Dateien verwaltet. Die Clients können die Dateien von diesem zentralen Ort abholen und auf ihren PC übertragen. Den Vorgang des Abholens nennt man Auschecken (engl. to check out). (((CVS)))(((Subversion)))(((Perforce))) +Diese Art von System war über viele Jahre hinweg der Standard für Versionsverwaltungssysteme. -.Centralized version control. +.Zentrale Versionsverwaltung image::images/centralized.png[Centralized version control diagram] -This setup offers many advantages, especially over local VCSs. -For example, everyone knows to a certain degree what everyone else on the project is doing. -Administrators have fine-grained control over who can do what, and it's far easier to administer a CVCS than it is to deal with local databases on every client. +Dieser Ansatz hat viele Vorteile, besonders gegenüber lokalen Versionsverwaltungssystemen. +Zum Beispiel weiß jeder mehr oder weniger genau darüber Bescheid, was andere, an einem Projekt Beteiligte gerade tun. +Administratoren haben die Möglichkeit, detailliert festzulegen, wer was tun kann. Und es ist sehr viel einfacher, ein CVCS zu administrieren als lokale Datenbanken auf jedem einzelnen Anwenderrechner zu verwalten. -However, this setup also has some serious downsides. -The most obvious is the single point of failure that the centralized server represents. -If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they're working on. -If the hard disk the central database is on becomes corrupted, and proper backups haven't been kept, you lose absolutely everything -- the entire history of the project except whatever single snapshots people happen to have on their local machines. -Local VCS systems suffer from this same problem -- whenever you have the entire history of the project in a single place, you risk losing everything. +Allerdings hat dieser Aufbau auch einige erhebliche Nachteile. +Der offensichtlichste Nachteil, ist das Risiko eines Systemausfalls, bei Ausfall einer einzelnen Komponente, nämlich dann wenn der zentralisierte Server ausfällt. +Wenn dieser Server nur für eine Stunde nicht verfügbar ist, dann kann in dieser einen Stunde niemand in irgendeiner Form mit anderen zusammenarbeiten oder Dateien, an denen gerade gearbeitet wird, versioniert abspeichern. +Wenn die auf dem zentralen Server eingesetzte Festplatte beschädigt wird und keine Sicherheitskopien erstellt wurden, dann sind all diese Daten unwiederbringlich verloren – die komplette Historie des Projektes, abgesehen natürlich von dem jeweiligen Zustand, den Mitarbeiter gerade zufällig auf ihrem Rechner noch vorliegen haben. +Lokale Versionskontrollsysteme haben natürlich dasselbe Problem: Wenn man die Historie eines Projektes an einer einzigen, zentralen Stelle verwaltet, riskiert man, sie vollständig zu verlieren, wenn irgendetwas an dieser zentralen Stelle ernsthaft schief läuft. -==== Distributed Version Control Systems +==== Verteilte Versionsverwaltung -(((version control,distributed))) -This is where Distributed Version Control Systems (DVCSs) step in. -In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don't just check out the latest snapshot of the files; rather, they fully mirror the repository, including its full history. -Thus, if any server dies, and these systems were collaborating via that server, any of the client repositories can be copied back up to the server to restore it. -Every clone is really a full backup of all the data. +(((Versionsverwaltung, verteilt))) +Und an dieser Stelle kommen verteilte Versionsverwaltungssysteme (engl. Distributed Version Control System, DVCS) ins Spiel. +In einem DVCS (wie z.B. Git, Mercurial, Bazaar oder Darcs) erhalten Anwender nicht einfach nur den jeweils letzten Zustand des Projektes von einem Server: Sie erhalten stattdessen eine vollständige Kopie des Repositorys. +Auf diese Weise kann, wenn ein Server beschädigt wird, jedes beliebige Repository von jedem beliebigen Anwenderrechner zurückkopiert werden und der Server so wiederhergestellt werden. +Jede Kopie, ein sogenannter Klon (engl. clone), ist ein vollständiges Backup der gesamten Projektdaten. -.Distributed version control. +.Verteilte Versionsverwaltung image::images/distributed.png[Distributed version control diagram] -Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. -This allows you to set up several types of workflows that aren't possible in centralized systems, such as hierarchical models. +Darüber hinaus können derartige Systeme hervorragend mit verschiedenen externen Repositorys, sogenannten Remote-Repositorys, umgehen, sodass man mit verschiedenen Gruppen von Leuten simultan auf verschiedene Art und Weise, an einem Projekt zusammenarbeiten kann. +Damit ist es möglich, verschiedene Arten von Arbeitsabläufen zu erstellen und anzuwenden, welche mit zentralisierten Systemen nicht möglich wären. Dazu gehören zum Beispiel hierarchische Arbeitsabläufe. diff --git a/book/01-introduction/sections/command-line.asc b/book/01-introduction/sections/command-line.asc index e7fd185b..b69dcd9c 100644 --- a/book/01-introduction/sections/command-line.asc +++ b/book/01-introduction/sections/command-line.asc @@ -1,11 +1,11 @@ -=== The Command Line +=== Die Kommandozeile -There are a lot of different ways to use Git. -There are the original command-line tools, and there are many graphical user interfaces of varying capabilities. -For this book, we will be using Git on the command line. -For one, the command line is the only place you can run _all_ Git commands -- most of the GUIs implement only a partial subset of Git functionality for simplicity. -If you know how to run the command-line version, you can probably also figure out how to run the GUI version, while the opposite is not necessarily true. -Also, while your choice of graphical client is a matter of personal taste, _all_ users will have the command-line tools installed and available. +Es gibt viele verschiedene Möglichkeiten Git einzusetzen. +Auf der einen Seite gibt es die Werkzeuge, die per Kommandozeile bedient werden und auf der anderen, die vielen grafischen Benutzeroberflächen (engl. graphical user interface, GUI), die sich im Leistungsumfang unterscheiden. +In diesem Buch verwenden wir die Kommandozeile. +In der Kommandozeile können nämlich wirklich *alle* vorhandenen Git Befehle ausgeführt werden. Bei den meisten grafischen Oberflächen ist dies nicht möglich, da aus Gründen der Einfachheit nur ein Teil der Git Funktionalitäten zur Verfügung gestellt werden. +Wenn Sie sich in der Kommandozeilenversion von Git auskennen, finden Sie sich wahrscheinlich auch in einer GUI-Version relativ schnell zurecht, aber andersherum muss das nicht unbedingt zutreffen. +Außerdem ist die Wahl der grafischen Oberfläche eher Geschmackssache, wohingegen die Kommandozeilenversion auf jedem Rechner installiert und verfügbar ist. -So we will expect you to know how to open Terminal in macOS or Command Prompt or PowerShell in Windows. -If you don't know what we're talking about here, you may need to stop and research that quickly so that you can follow the rest of the examples and descriptions in this book. +In diesem Buch gehen wir deshalb davon aus, dass Sie wissen, wie man bei einem Mac ein Terminal öffnet, oder wie man unter Windows die Eingabeaufforderung oder die Powershell öffnet. +Sollten Sie jetzt nur Bahnhof verstehen, sollten Sie an dieser Stelle abbrechen und sich schlau machen, was ein Terminal bzw. Eingabeaufforderung ist und wie man diese bedient. Nur so ist sichergestellt, dass Sie unseren Beispielen und Ausführungen im weiteren Verlauf des Buches folgen können. diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index e694182e..212314f5 100644 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -1,41 +1,41 @@ [[_first_time]] -=== First-Time Git Setup +=== Git Basis-Konfiguration -Now that you have Git on your system, you'll want to do a few things to customize your Git environment. -You should have to do these things only once on any given computer; they'll stick around between upgrades. -You can also change them at any time by running through the commands again. +Nachdem Git jetzt auf Ihrem System installiert ist, sollten Sie Ihre Git Konfiguration noch anpassen. +Dies muss nur einmalig auf dem jeweiligen System durchgeführt werden. Die Konfiguration bleibt bestehen, wenn Sie Git auf eine neuere Version aktualisieren. +Die Git Konfiguration kann auch jederzeit geändert werden, indem die nachfolgenden Befehle einfach noch einmal ausgeführt werden. -Git comes with a tool called `git config` that lets you get and set configuration variables that control all aspects of how Git looks and operates.(((git commands, config))) -These variables can be stored in three different places: +Git umfasst das Werkzeug `git config`, welches die Möglichkeit bietet, Konfigurationswerte zu verändern. Auf diese Weise können Sie anpassen, wie Git aussieht und arbeitet.(((Git Befehle, config))) +Die Konfiguration ist an drei verschiedenen Orten gespeichert: -1. `/etc/gitconfig` file: Contains values applied to every user on the system and all their repositories. - If you pass the option `--system` to `git config`, it reads and writes from this file specifically. - (Because this is a system configuration file, you would need administrative or superuser privilege to make changes to it.) -2. `~/.gitconfig` or `~/.config/git/config` file: Values specific personally to you, the user. - You can make Git read and write to this file specifically by passing the `--global` option, and this affects _all_ of the repositories you work with on your system. -3. `config` file in the Git directory (that is, `.git/config`) of whatever repository you're currently using: Specific to that single repository. - You can force Git to read from and write to this file with the `--local` option, but that is in fact the default. - (Unsurprisingly, you need to be located somewhere in a Git repository for this option to work properly.) +1. Die Datei `/etc/gitconfig`: enthält Werte, die für jeden Benutzer auf dem System und alle seine Repositories gelten. + Wenn Sie die Option `--system` an `git config` übergeben, liest und schreibt sie spezifisch aus dieser Datei. + (Da es sich um eine Systemkonfigurationsdatei handelt, benötigen Sie Administrator- oder Superuser-Rechte, um Änderungen daran vorzunehmen.) +2. Die Datei `~/.gitconfig` oder `~/.config/git/config`: enthält Werte, die für Sie, den Benutzer, per­sönlich bestimmt sind. + Sie können Git dazu bringen, diese Datei gezielt zu lesen und zu schreiben, indem Sie die Option `--global` übergeben, und dies betrifft _alle_ der Repositories, mit denen Sie auf Ihrem System arbeiten. +3. Die Datei `config` im Git Verzeichnis (also `.git/config`) des jeweiligen Repositories, das Sie gerade verwenden: + Sie können Git mit der Option `--local` zwingen, aus dieser Datei zu lesen und in sie zu schreiben, das ist in der Regel die Standardoption. + (Es dürfte Sie nicht überraschen, dass Sie sich irgendwo in einem Git-Repository befinden müssen, damit diese Option ordnungsgemäß funktioniert.) -Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`. + Jede Ebene überschreibt Werte der vorherigen Ebene, so dass Werte in `.git/config` diejenigen in `/etc/gitconfig` aushebeln. -On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`C:\Users\$USER` for most people). -It also still looks for `/etc/gitconfig`, although it's relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer. -If you are using version 2.x or later of Git for Windows, there is also a system-level config file at -`C:\Documents and Settings\All Users\Application Data\Git\config` on Windows XP, and in `C:\ProgramData\Git\config` on Windows Vista and newer. -This config file can only be changed by `git config -f ` as an admin. +Auf Windows Systemen sucht Git nach der Datei `.gitconfig` im `$HOME` Verzeichnis (Normalerweise zeigt `$HOME` bei den meisten Systemen auf `C:\Users\$USER`). +Git schaut immer nach `/etc/gitconfig`, auch wenn die sich relativ zu dem MSys-Wurzelverzeichnis befindet, dem Verzeichnis in das Sie Git installiert haben. +Wenn Sie eine Version 2.x oder neuer von Git für Windows verwenden, gibt es auch eine Konfigurationsdatei auf Systemebene unter +`C:\Dokumente und Einstellungen\Alle Benutzer\Anwendungsdaten\Git\config` unter Windows XP und unter `C:\ProgramData\Git\config` unter Windows Vista und neuer. +Diese Konfigurationsdatei kann nur von `git config -f ` als Admin geändert werden. -You can view all of your settings and where they are coming from using: +Sie können sich alle Ihre Einstellungen ansehen sehen, wo sie herkommen: [source,console] ---- $ git config --list --show-origin ---- -==== Your Identity +==== Ihre Identität -The first thing you should do when you install Git is to set your user name and email address. -This is important because every Git commit uses this information, and it's immutably baked into the commits you start creating: +Nachdem Sie Git installiert haben, sollten Sie als aller erstes Ihren Namen und E-Mail Adresse in Git konfigurieren. +Das ist insofern wichtig,da jeder Git-Commit diese Informationen verwendet und sie unveränderlich in die Commits eingearbeitet werden, die Sie erstellen: [source,console] ---- @@ -43,29 +43,29 @@ $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com ---- -Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system. -If you want to override this with a different name or email address for specific projects, you can run the command without the `--global` option when you're in that project. +Wie schon erwähnt, brauchen Sie diese Konfiguration nur einmal vorzunehmen, wenn Sie die Option `--global` verwenden. Auf Grund der oben erwähnten Prioritäten gilt das dann für alle Ihre Projekte. +Wenn Sie für ein spezielles Projekt einen anderen Namen oder eine andere E-Mail Adresse verwenden möchten, können Sie den Befehl ohne die `--global` Option innerhalb des Projektes ausführen. -Many of the GUI tools will help you do this when you first run them. +Viele der grafischen Oberflächen helfen einem bei diesem Schritt, wenn Sie sie zum ersten Mal ausführen. [[_editor]] -==== Your Editor +==== Ihr Editor -Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. -If not configured, Git uses your system's default editor. +Jetzt, da Ihre Identität eingerichtet ist, können Sie den Standard-Texteditor konfigurieren, der verwendet wird, wenn Git Sie zum Eingeben einer Nachricht auffordert. +Normalerweise verwendet Git den Standard-Texteditor des jeweiligen Systems. -If you want to use a different text editor, such as Emacs, you can do the following: +Wenn Sie einen anderen Texteditor, z.B. Emacs, verwenden wollen, können Sie das wie folgt festlegen: [source,console] ---- $ git config --global core.editor emacs ---- -On a Windows system, if you want to use a different text editor, you must specify the full path to its executable file. -This can be different depending on how your editor is packaged. +Wenn Sie auf einem Windows-System einen anderen Texteditor verwenden möchten, müssen Sie den vollständigen Pfad zu seiner ausführbaren Datei angeben. +Dies kann, je nachdem, wie Ihr Editor eingebunden ist, unterschiedlich sein. -In the case of Notepad++, a popular programming editor, you are likely to want to use the 32-bit version, since at the time of writing the 64-bit version doesn't support all plug-ins. -If you are on a 32-bit Windows system, or you have a 64-bit editor on a 64-bit system, you'll type something like this: +Im Falle von Notepad++, einem beliebten Programmiereditor, sollten Sie wahrscheinlich die 32-Bit-Version verwenden, da die 64-Bit-Version zum Zeitpunkt der Erstellung nicht alle Plug-Ins unterstützt. +Beim Einsatz auf einem 32-Bit-Windows-System oder einem 64-Bit-Editor auf einem 64-Bit-System geben Sie etwa Folgendes ein: [source,console] ---- @@ -74,19 +74,20 @@ $ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -m [NOTE] ==== -Vim, Emacs and Notepad++ are popular text editors often used by developers on Unix-based systems like Linux and macOS or a Windows system. -If you are using another editor, or a 32-bit version, please find specific instructions for how to set up your favorite editor with Git in <>. +Vim, Emacs und Notepad++ sind beliebte Texteditoren, die von Entwicklern häufig auf Unix-basierten Systemen wie Linux und MacOS oder einem Windows-System verwendet werden. +Wenn Sie einen anderen Editor oder eine 32-Bit-Version verwenden, finden Sie in <> spezielle Anweisungen, wie Sie Ihren bevorzugten Editor mit Git einrichten können. + ==== [WARNING] ==== -You may find, if you don't setup your editor like this, you get into a really confusing state when Git attempts to launch it. -An example on a Windows system may include a prematurely terminated Git operation during a Git initiated edit. +Wenn Sie Git nicht so konfigurieren, dass es Ihren Texteditor verwendet und Sie keine Ahnung davon haben, wie man Vim oder Emacs benutzt, werden Sie ein wenig überfordert sein, wenn diese zum ersten Mal von Git gestartet werden. +Ein Beispiel: auf einem Windows-System kann es eine vorzeitig beendete Git-Operation während einer von Git angestoßenen Verarbeitung sein. ==== -==== Checking Your Settings +==== Einstellungen überprüfen -If you want to check your configuration settings, you can use the `git config --list` command to list all the settings Git can find at that point: +Wenn Sie Ihre Konfigurationseinstellungen überprüfen möchten, können Sie mit dem Befehl `git config --list` alle Einstellungen auflisten, die Git derzeit finden kann: [source,console] ---- @@ -100,10 +101,10 @@ color.diff=auto ... ---- -You may see keys more than once, because Git reads the same key from different files (`/etc/gitconfig` and `~/.gitconfig`, for example). -In this case, Git uses the last value for each unique key it sees. +Manche Parameter werden möglicherweise mehrfach aufgelistet, weil Git denselben Parameter in verschiedenen Dateien (z.B. `/etc/gitconfig` und `~/.gitconfig`) gefunden hat. +In diesem Fall verwendet Git dann den jeweils zuletzt aufgelisteten Wert. -You can also check what Git thinks a specific key's value is by typing `git config `:(((git commands, config))) +Außerdem können Sie mit dem Befehl `git config ` prüfen, welchen Wert Git für einen bestimmten Parameter verwendet:(((Git Befehle, config))) [source,console] ---- @@ -113,8 +114,8 @@ John Doe [NOTE] ==== -Since Git might read the same configuration variable value from more than one file, it's possible that you have an unexpected value for one of these values and you don't know why. -In cases like that, you can query Git as to the _origin_ for that value, and it will tell you which configuration file had the final say in setting that value: +Da Git möglicherweise den gleichen Wert der Konfigurationsvariablen aus mehr als einer Datei liest, ist es möglich, dass Sie einen unerwarteten Wert für einen dieser Werte haben und nicht wissen, warum. +In solchen Fällen können Sie Git nach dem _Ursprung (origin)_ für diesen Wert fragen, und es wird Ihnen sagen, mit welcher Konfigurationsdatei der Wert letztendlich festgelegt wurde: [source,console] ---- diff --git a/book/01-introduction/sections/help.asc b/book/01-introduction/sections/help.asc index 23af9762..f63a97fe 100644 --- a/book/01-introduction/sections/help.asc +++ b/book/01-introduction/sections/help.asc @@ -1,7 +1,7 @@ [[_git_help]] -=== Getting Help +=== Hilfe finden -If you ever need help while using Git, there are three equivalent ways to get the comprehensive manual page (manpage) help for any of the Git commands: +Falls Sie einmal Hilfe bei der Anwendung von Git benötigen, gibt es drei Möglichkeiten, die entsprechende Seite aus der Dokumentation (engl. manpage) für jeden Git Befehl anzuzeigen: [source,console] ---- @@ -10,18 +10,18 @@ $ git --help $ man git- ---- -For example, you can get the manpage help for the `git config` command by running(((git commands, help))) +Beispielweise erhalten Sie die Hilfeseite für den `git config` Befehl folgendermaßen:(((Git Befehle, help))) [source,console] ---- $ git help config ---- -These commands are nice because you can access them anywhere, even offline. -If the manpages and this book aren't enough and you need in-person help, you can try the `#git` or `#github` channel on the Freenode IRC server, which can be found at https://freenode.net[]. -These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.(((IRC))) +Diese Befehle sind nützlich, weil Sie sich die Hilfe jederzeit anzeigen lassen können, auch wenn Sie einmal offline sind. +Wenn die Hilfeseiten und dieses Buch nicht ausreichen und Sie persönliche Hilfe brauchen, können Sie den `#git` oder `#github` Kanal auf dem Freenode IRC Server probieren, der unter https://freenode.net zu finden ist. +Diese Kanäle sind in der Regel sehr gut besucht. Normalerweise findet sich unter den vielen Anwendern, die oft sehr viel Erfahrung mit Git haben, irgendjemand, der Ihnen weiterhelfen kann.(((IRC))) -In addition, if you don't need the full-blown manpage help, but just need a quick refresher on the available options for a Git command, you can ask for the more concise ``help'' output with the `-h` or `--help` options, as in: +Wenn Sie nicht die vollständige Manpage-Hilfe benötigen, sondern nur eine kurze Beschreibung der verfügbaren Optionen für einen Git-Befehl, können Sie auch in den kompakteren „Hilfeseiten“ mit den Optionen `-h` oder `--help` nachschauen, wie in: [source,console] ---- @@ -45,4 +45,3 @@ usage: git add [] [--] ... --ignore-missing check if - even missing - files are ignored in dry run --chmod (+|-)x override the executable bit of the listed files ---- - diff --git a/book/01-introduction/sections/history.asc b/book/01-introduction/sections/history.asc index dd1d096f..1cc6f293 100644 --- a/book/01-introduction/sections/history.asc +++ b/book/01-introduction/sections/history.asc @@ -1,20 +1,19 @@ -=== A Short History of Git +=== Kurzer Überblick über die Historie von Git -As with many great things in life, Git began with a bit of creative destruction and fiery controversy. +Wie viele großartige Dinge im Leben, entstand Git aus einer Prise kreativem Chaos und hitziger Diskussion. -The Linux kernel is an open source software project of fairly large scope.(((Linux))) -For most of the lifetime of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files. -In 2002, the Linux kernel project began using a proprietary DVCS called BitKeeper.(((BitKeeper))) +Der Linux Kernel ist ein Open Source Software Projekt von erheblichem Umfang.(((Linux))) +Während der gesamten Entwicklungszeit des Linux Kernels von 1991 bis 2002 wurden Änderungen an diesem, in Form von Patches und archivierten Dateien herumgereicht. 2002 begann man dann, ein proprietäres DVCS mit dem Namen Bitkeeper zu verwenden.(((BitKeeper))) -In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool's free-of-charge status was revoked. -This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper.(((Linus Torvalds))) -Some of the goals of the new system were as follows: +2005 ging die Beziehung zwischen der Community, die den Linux Kernel entwickelte, und des kommerziell ausgerichteten Unternehmens, das BitKeeper entwickelte, in die Brüche. Die zuvor ausgesprochene Erlaubnis, BitKeeper kostenlos zu verwenden, wurde widerrufen. +Dies war für die Linux Entwickler Community (und besonders für Linus Torvalds, der Erfinder von Linux) der Auslöser dafür, ein eigenes Tool zu entwickeln, das auf den Erfahrungen mit BitKeeper basierte.(((Linux Torvalds))) +Die Ziele des neuen Systems waren unter anderem: -* Speed -* Simple design -* Strong support for non-linear development (thousands of parallel branches) -* Fully distributed -* Able to handle large projects like the Linux kernel efficiently (speed and data size) +* Geschwindigkeit +* Einfaches Design +* Gute Unterstützung von nicht-linearer Entwicklung (tausende parallele Entwicklungszweige) +* Vollständig dezentrale Struktur +* Fähigkeit große Projekte, wie den Linux Kernel, effektiv zu verwalten (Geschwindigkeit und Datenumfang) -Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. -It's amazingly fast, it's very efficient with large projects, and it has an incredible branching system for non-linear development (See <>). +Seit seiner Geburt 2005, entwickelte sich Git kontinuierlich weiter und reifte zu einem System heran, das einfach zu bedienen ist, die ursprünglichen Ziele dabei aber weiter beibehält. +Es ist unglaublich schnell, äußerst effizient, wenn es um große Projekte geht, und es hat ein fantastisches Branching Konzept für nicht-lineare Entwicklung (siehe Kapitel 3 <>). diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc index 29dbd701..412195a4 100644 --- a/book/01-introduction/sections/installing.asc +++ b/book/01-introduction/sections/installing.asc @@ -1,83 +1,83 @@ -=== Installing Git +=== Git installieren -Before you start using Git, you have to make it available on your computer. -Even if it's already installed, it's probably a good idea to update to the latest version. -You can either install it as a package or via another installer, or download the source code and compile it yourself. +Bevor Sie mit Git loslegen können, muss es natürlich zuerst installiert werden. +Auch wenn es bereits vorhanden ist, ist es vermutlich eine gute Idee, auf die neueste Version zu aktualisieren. +Sie können es entweder als Paket oder über ein anderes Installationsprogramm installieren oder den Quellcode herunterladen und selbst kompilieren. [NOTE] ==== -This book was written using Git version *2.8.0*. -Though most of the commands we use should work even in ancient versions of Git, some of them might not or might act slightly differently if you're using an older version. -Since Git is quite excellent at preserving backwards compatibility, any version after 2.0 should work just fine. +Dieses Buch wurde auf Basis der Git Version *2.8.0* geschrieben. +Auch wenn die meisten Befehle, die wir anwenden werden, auch in älteren Versionen funktionieren, kann es doch sein, dass die Befehlsausgabe oder das Verhalten leicht anders ist. +Da in Git sehr auf Abwärtskompatibilität geachtet wird, sollten aber alle neueren Versionen nach der Version 2.0 genauso gut funktionieren. ==== -==== Installing on Linux +==== Installation unter Linux (((Linux, installing))) -If you want to install the basic Git tools on Linux via a binary installer, you can generally do so through the package management tool that comes with your distribution. -If you're on Fedora (or any closely-related RPM-based distribution, such as RHEL or CentOS), you can use `dnf`: +Wenn Sie die grundlegenden Git-Tools unter Linux über ein Installationsprogramm installieren möchten, können Sie das in der Regel über das Paketverwaltungstool der Distribution tun. +Wenn Sie mit Fedora (oder einer anderen eng damit verbundenen RPM-basierten Distribution, wie RHEL oder CentOS) arbeiten, können Sie `dnf` verwenden: [source,console] ---- $ sudo dnf install git-all ---- -If you're on a Debian-based distribution, such as Ubuntu, try `apt`: +Auf einem Debian-basierten System, wie Ubuntu, steht `apt` zur Verfügung: [source,console] ---- $ sudo apt install git-all ---- -For more options, there are instructions for installing on several different Unix distributions on the Git website, at https://git-scm.com/download/linux[]. +Auf der Git Homepage http://git-scm.com/download/linux[] findet man weitere Möglichkeiten und Optionen, wie man Git unter einem Unix-basierten Betriebssystem installieren kann. -==== Installing on macOS +==== Installation unter macOS (((macOS, installing))) -There are several ways to install Git on a Mac. -The easiest is probably to install the Xcode Command Line Tools.(((Xcode))) -On Mavericks (10.9) or above you can do this simply by trying to run 'git' from the Terminal the very first time. +Es gibt mehrere Möglichkeiten, Git auf einem Mac zu installieren. +Am einfachsten ist es wahrscheinlich, die Xcode Command Line Tools zu installieren.(((Xcode))) +Bei Mavericks (10.9) oder neueren Versionen kann man dazu einfach 'git' im Terminal eingeben. [source,console] ---- $ git --version ---- -If you don't have it installed already, it will prompt you to install it. +Wenn Git noch nicht installiert ist, erscheint eine Abfrage, ob man es installieren möchte. -If you want a more up to date version, you can also install it via a binary installer. -A macOS Git installer is maintained and available for download at the Git website, at https://git-scm.com/download/mac[]. +Wenn man eine sehr aktuelle Version einsetzen möchte, kann man Git auch über ein Installationsprogramm installieren. +Auf der Git Website http://git-scm.com/download/mac[] findet man die jeweils aktuellste Version und kann sie von dort herunterladen.. -.Git macOS Installer. +.Git macOS Installationsprogramm. image::images/git-osx-installer.png[Git macOS installer.] -You can also install it as part of the GitHub for macOS install. -Their GUI Git tool has an option to install command line tools as well. -You can download that tool from the GitHub for macOS website, at https://desktop.github.com[]. +Ein weitere Möglichkeit ist „GitHub for Mac“ zu installieren. +Es gibt dort eine Option, dass man neben der grafischen Oberfläche auch gleich die Kommandozeilen Werkzeuge mit installieren kann. +„GitHub for Mac“ kann man unter http://mac.github.com[] herunterladen. -==== Installing on Windows +==== Installation unter Windows -There are also a few ways to install Git on Windows.(((Windows, installing))) -The most official build is available for download on the Git website. -Just go to https://git-scm.com/download/win[] and the download will start automatically. -Note that this is a project called Git for Windows, which is separate from Git itself; for more information on it, go to https://gitforwindows.org[]. +Auch für Windows gibt es einige, wenige Möglichkeiten zur Installation von Git.(((Windows, installing))) +Eine offizielle Windows Version findet man direkt auf der Git Homepage. +Gehen Sie dazu auf http://git-scm.com/download/win[] und der Download sollte dann automatisch starten. +Man sollte dabei beachten, dass es sich hierbei um das Projekt Git for Windows handelt, welches unabhängig von Git selbst ist. Weitere Informationen hierzu finden Sie unter http://msysgit.github.io/[]. -To get an automated installation you can use the https://chocolatey.org/packages/git[Git Chocolatey package]. -Note that the Chocolatey package is community maintained. +Um eine automatisierte Installation zu erhalten, können Sie das https://chocolatey.org/packages/git[Git Chocolatey Paket] verwenden. +Beachten Sie, dass das Chocolatey-Paket von der Community gepflegt wird. -Another easy way to get Git installed is by installing GitHub Desktop. -The installer includes a command line version of Git as well as the GUI. -It also works well with PowerShell, and sets up solid credential caching and sane CRLF settings.(((PowerShell)))(((CRLF)))(((credential caching))) -We'll learn more about those things a little later, but suffice it to say they're things you want. -You can download this from the https://desktop.github.com[GitHub Desktop website]. +Eine weitere einfache Möglichkeit, Git zu installieren, ist die Installation von GitHub Desktop. +Das Installationsprogramm enthält neben der GUI, auch eine Kommandozeilenversion von Git. +Diese funktioniert zusammen mit der Powershell tadellos, und richtet die wichtigsten Berechtigungs-Caching (engl. credential caching) und Zeilenenden-Konfigurationen (CRLF) vorab ein.(((Powershell)))(((CRLF)))(((Berechtigungs-Caching))) +Wir werden später etwas mehr darüber erfahren, jetzt reicht es festzustellen, dass es sich um die wünschenswerte Funktionen handelt. +Sie können das ganze „GitHub for Windows“ Paket von der https://desktop.github.com[GitHub Desktop Website] herunterladen. -==== Installing from Source +==== Aus dem Quellcode installieren -Some people may instead find it useful to install Git from source, because you'll get the most recent version. -The binary installers tend to be a bit behind, though as Git has matured in recent years, this has made less of a difference. +Viele Leute kompilieren Git auch auf ihrem eigenen Rechner, weil sie damit, die jeweils aktuellste Version erhalten. +Die vorbereiteten Pakete hinken meist ein wenig hinterher. Heutzutage ist dies nicht mehr ganz so schlimm, da Git einen gewissen Reifegrad erfahren hat. -If you do want to install Git from source, you need to have the following libraries that Git depends on: autotools, curl, zlib, openssl, expat, and libiconv. -For example, if you're on a system that has `dnf` (such as Fedora) or `apt-get` (such as a Debian-based system), you can use one of these commands to install the minimal dependencies for compiling and installing the Git binaries: +Wenn Sie Git aus dem Quellcode installieren möchten, benötigen Sie die folgenden Bibliotheken, von denen Git abhängt: autotools, curl, zlib, openssl, expat und libiconv. +Wenn Sie sich beispielsweise auf einem System befinden, das Paketverwaltungen, wie `dnf` (Fedora) oder `apt-get` (ein Debian-basiertes System) hat, können Sie mit einem dieser Befehle die minimalen Abhängigkeiten für die Kompilierung und Installation der Git-Binärdateien installieren: [source,console] ---- @@ -87,7 +87,7 @@ $ sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev \ gettext libz-dev libssl-dev ---- -In order to be able to add the documentation in various formats (doc, html, info), these additional dependencies are required (Note: users of RHEL and RHEL-derivatives like CentOS and Scientific Linux will have to https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F[enable the EPEL repository] to download the `docbook2X` package): +Um die Dokumentation in verschiedenen Formaten (doc, html, info) zu erstellen, sind weitere Abhängigkeiten notwendig (Hinweis: Benutzer von RHEL und RHEL-Derivaten wie CentOS und Scientific Linux müssen das https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F[EPEL-Repository aktivieren], um das Paket `docbook2X` herunterzuladen): [source,console] ---- @@ -95,14 +95,14 @@ $ sudo dnf install asciidoc xmlto docbook2X $ sudo apt-get install asciidoc xmlto docbook2x ---- -If you're using a Debian-based distribution (Debian/Ubuntu/Ubuntu-derivatives), you also need the `install-info` package: +Wenn Sie eine Debian-basierte Distribution (Debian, Ubuntu oder deren Derivate) verwenden, benötigen Sie auch das Paket `install-info`: [source,console] ---- $ sudo apt-get install install-info ---- -If you're using a RPM-based distribution (Fedora/RHEL/RHEL-derivatives), you also need the `getopt` package (which is already installed on a Debian-based distro): +Wenn Sie eine RPM-basierte Distribution (Fedora, RHEL oder deren Derivate) verwenden, benötigen Sie auch das Paket `getopt` (welches auf einer Debian-basierten Distribution bereits installiert ist): [source,console] ---- @@ -110,20 +110,18 @@ $ sudo dnf install getopt $ sudo apt-get install getopt ---- -Additionally, if you're using Fedora/RHEL/RHEL-derivatives, you need to do this +Wenn Sie Fedora- oder RHEL-Derivate verwenden, müssen Sie wegen der unterschiedlichen Paketnamen zusätzlich einen Symlink erstellen indem Sie folgenden Befehl ausführen: [source,console] ---- $ sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi ---- -due to binary name differences. +Wenn Sie alle notwendigen Abhängigkeiten installiert haben, können Sie sich als nächstes die jeweils aktuellste Version als Tarball von verschiedenen Stellen herunterladen. +Man findet die Quellen auf der Kernel.org Website unter https://www.kernel.org/pub/software/scm/git[], oder einen Mirror auf der GitHub Website unter https://github.com/git/git/releases[]. +Auf der GitHub Seite ist es einfacher herauszufinden, welches die jeweils aktuellste Version ist. Auf kernel.org dagegen werden auch Signaturen, zur Verifikation des Downloads, der jeweiligen Pakete zur Verfügung gestellt. -When you have all the necessary dependencies, you can go ahead and grab the latest tagged release tarball from several places. -You can get it via the kernel.org site, at https://www.kernel.org/pub/software/scm/git[], or the mirror on the GitHub website, at https://github.com/git/git/releases[]. -It's generally a little clearer what the latest version is on the GitHub page, but the kernel.org page also has release signatures if you want to verify your download. - -Then, compile and install: +Nachdem man sich so die Quellen beschafft hat, kann man Git kompilieren und installieren: [source,console] ---- @@ -135,7 +133,7 @@ $ make all doc info $ sudo make install install-doc install-html install-info ---- -After this is done, you can also get Git via Git itself for updates: +Jetzt nachdem Git installiert ist, kann man sich Git Updates auch per Git beschaffen: [source,console] ---- diff --git a/book/01-introduction/sections/what-is-git.asc b/book/01-introduction/sections/what-is-git.asc index f9792f8b..8ab4deaa 100644 --- a/book/01-introduction/sections/what-is-git.asc +++ b/book/01-introduction/sections/what-is-git.asc @@ -1,108 +1,107 @@ -=== What is Git? +=== Was ist Git? -So, what is Git in a nutshell? -This is an important section to absorb, because if you understand what Git is and the fundamentals of how it works, then using Git effectively will probably be much easier for you. -As you learn Git, try to clear your mind of the things you may know about other VCSs, such as CVS, Subversion or Perforce -- doing so will help you avoid subtle confusion when using the tool. -Even though Git's user interface is fairly similar to these other VCSs, Git stores and thinks about information in a very different way, and understanding these differences will help you avoid becoming confused while using it.(((Subversion)))(((Perforce))) +Also, was ist Git in Kürze? +Das ist ein wichtiger Teil, den es zu beachten gilt, denn wenn Sie verstehen, was Git und das grundlegenden Konzept seiner Arbeitsweise ist, dann wird die effektive Nutzung von Git für Sie wahrscheinlich viel einfacher sein. +Wenn Sie Git erlernen, versuchen Sie, Ihren Kopf von den Dingen zu befreien, die Sie über andere VCSs wissen, wie CVS, Subversion oder Perforce – das wird Ihnen helfen, unangenehme Missverständnisse bei der Verwendung des Tools zu vermeiden. +Auch wenn die Benutzeroberfläche von Git diesen anderen VCSs sehr ähnlich ist, speichert und betrachtet Git Informationen auf eine ganz andere Weise, und das Verständnis dieser Unterschiede hilft Ihnen Unklarheiten bei der Verwendung zu vermeiden.(((Subversion)))(((Perforce))) -==== Snapshots, Not Differences +==== Snapshots und nicht die Unterschiedes -The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. -Conceptually, most other systems store information as a list of file-based changes. -These other systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they store as a set of files and the changes made to each file over time (this is commonly described as _delta-based_ version control). +Der Hauptunterschied zwischen Git und anderen Versionsverwaltungssystemen (insbesondere auch Subversion und vergleichbare Systeme) besteht in der Art und Weise wie Git die Daten betrachtet. +Konzeptionell speichern die meisten anderen Systeme Informationen als eine Liste von dateibasierten Änderungen. +Diese Systeme (CVS, Subversion, Perforce, Bazaar usw.) betrachten die Informationen, die sie verwalten, als eine Reihe von Dateien an denen im Laufe der Zeit Änderungen vorgenommen werden (dies wird allgemein als deltabasierte Versionskontrolle bezeichnet). -.Storing data as changes to a base version of each file. +.Speichern von Daten als Änderung an einzelnen Dateien auf Basis einer Ursprungsdatei. image::images/deltas.png[Storing data as changes to a base version of each file.] -Git doesn't think of or store its data this way. -Instead, Git thinks of its data more like a series of snapshots of a miniature filesystem. -With Git, every time you commit, or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. -To be efficient, if files have not changed, Git doesn't store the file again, just a link to the previous identical file it has already stored. -Git thinks about its data more like a *stream of snapshots*. +Git arbeitet nicht auf diese Art und Weise. +Stattdessen betrachtet Git seine Daten eher wie eine Reihe von Schnappschüssen eines Mini-Dateisystems. +Git macht jedes Mal, wenn Sie den Status Ihres Projekts committen, das heißt den gegenwärtigen Status Ihres Projekts als eine Version in Git speichern, ein Abbild von all Ihren Dateien wie sie gerade aussehen und speichert einen Verweis in diesem Schnappschuss. +Um dies möglichst effizient und schnell tun zu können, kopiert Git unveränderte Dateien nicht, sondern legt lediglich eine Verknüpfung zu der vorherigen Version der Datei an. +Git betrachtet seine Daten eher wie einen *Stapel von Schnappschüssen*. -.Storing data as snapshots of the project over time. +.Speichern der Daten-Historie eines Projekts in Form von Schnappschüssen. image::images/snapshots.png[Git stores data as snapshots of the project over time.] -This is an important distinction between Git and nearly all other VCSs. -It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. -This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS. -We'll explore some of the benefits you gain by thinking of your data this way when we cover Git branching in <>. +Das ist ein wichtiger Unterschied zwischen Git und praktisch allen anderen Versionsverwaltungssystemen. +In Git wurden daher fast alle Aspekte der Versionsverwaltung neu überdacht, die in anderen Systemen mehr oder weniger von ihrer jeweiligen Vorgängergeneration übernommen worden waren. +Git arbeitet im Großen und Ganzen eher wie ein mit einigen unglaublich mächtigen Werkzeugen ausgerüstetes Mini-Dateisystem, statt nur als Versionsverwaltungssystem. Auf einige der Vorteile, die es mit sich bringt, Daten in dieser Weise zu verwalten, werden wir in Kapitel 3, <>, eingehen, wenn wir das Git Branching Konzept kennenlernen. -==== Nearly Every Operation Is Local +==== Fast jede Funktion arbeitet lokal -Most operations in Git need only local files and resources to operate -- generally no information is needed from another computer on your network. -If you're used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. -Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous. +Die meisten Aktionen in Git benötigen nur lokale Dateien und Ressourcen, um ausgeführt zu werden – im Allgemeinen werden keine Informationen von einem anderen Computer in Ihrem Netzwerk benötigt. +Wenn Sie an ein CVCS gewöhnt sind, in dem die meisten Operationen diesen Netzwerk-Latenz-Overhead haben, wird Sie dieser Aspekt von Git denken lassen, dass die Götter der Geschwindigkeit Git mit außerirdischen Kräften gesegnet haben. +Die allermeisten Operationen können nahezu ohne jede Verzögerung ausgeführt werden, da die vollständige Historie eines Projekts bereits auf dem jeweiligen Rechner verfügbar ist. -For example, to browse the history of the project, Git doesn't need to go out to the server to get the history and display it for you -- it simply reads it directly from your local database. -This means you see the project history almost instantly. -If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally. +Um beispielsweise die Historie des Projekts zu durchsuchen, braucht Git sie nicht von einem externen Server zu holen – es liest diese einfach aus der lokalen Datenbank. +Das heißt, die vollständige Projekthistorie ist ohne jede Verzögerung verfügbar. +Wenn man sich die Änderungen einer aktuellen Version einer Datei im Vergleich zu vor einem Monat, anschauen möchte, dann kann Git den Stand von vor einem Monat in der lokalen Historie nachschlagen und einen lokalen Vergleich zur vorliegenden Datei durchführen. Für diesen Anwendungsfall benötigt Git keinen externen Server, weder um Dateien dort nachzuschlagen, noch um Unterschiede dort bestimmen zu lassen. -This also means that there is very little you can't do if you're offline or off VPN. -If you get on an airplane or a train and want to do a little work, you can commit happily (to your _local_ copy, remember?) until you get to a network connection to upload. -If you go home and can't get your VPN client working properly, you can still work. -In many other systems, doing so is either impossible or painful. -In Perforce, for example, you can't do much when you aren't connected to the server; in Subversion and CVS, you can edit files, but you can't commit changes to your database (because your database is offline). -This may not seem like a huge deal, but you may be surprised what a big difference it can make. +Das bedeutet natürlich außerdem, dass es fast nichts gibt, was man nicht tun kann, nur weil man gerade offline ist oder keinen Zugriff auf ein VPN hat. +Wenn man also gerade im Flugzeug oder Zug ein wenig arbeiten will, kann man problemlos seine Arbeit einchecken und dann wenn man wieder mit einem Netzwerk verbunden ist, die Dateien auf einen Server hochladen. +Wenn man zu Hause sitzt, aber der VPN Client gerade mal wieder nicht funktioniert, kann man immer noch arbeiten. +Bei vielen anderen Systemen wäre dies unmöglich oder äußerst kompliziert umzusetzen. +In Perforce können Sie beispielsweise nicht viel tun, wenn Sie nicht mit dem Server verbunden sind; in Subversion und CVS können Sie Dateien bearbeiten, aber Sie können keine Änderungen zu Ihren Daten übertragen (weil die Datenbank offline ist). +Das scheint keine große Sache zu sein, aber Sie werden überrascht sein, was für einen großen Unterschied es machen kann. -==== Git Has Integrity +==== Git stellt Integrität sicher -Everything in Git is checksummed before it is stored and is then referred to by that checksum. -This means it's impossible to change the contents of any file or directory without Git knowing about it. -This functionality is built into Git at the lowest levels and is integral to its philosophy. -You can't lose information in transit or get file corruption without Git being able to detect it. +Von allen zu speichernden Daten berechnet Git Prüfsummen (engl. checksum) und speichert diese als Referenz zusammen mit den Daten ab. +Das macht es unmöglich, dass sich Inhalte von Dateien oder Verzeichnissen ändern, ohne dass Git das mitbekommt. +Git basiert auf dieser Funktionalität und sie ist ein integraler Teil der Git Philosophie. +Man kann Informationen deshalb z.B. nicht während der Übermittlung verlieren oder unwissentlich beschädigte Dateien verwenden, ohne dass Git in der Lage wäre, dies festzustellen. -The mechanism that Git uses for this checksumming is called a SHA-1 hash.(((SHA-1))) -This is a 40-character string composed of hexadecimal characters (0–9 and a–f) and calculated based on the contents of a file or directory structure in Git. -A SHA-1 hash looks something like this: +Der Mechanismus, den Git verwendet, um diese Prüfsummen zu erstellen, heißt SHA-1 Hash.(((SHA-1))) +Eine solche Prüfsumme ist eine 40 Zeichen lange Zeichenkette, die aus hexadezimalen Zeichen (0-9 und a-f) besteht und wird von Git aus den Inhalten einer Datei oder Verzeichnisstruktur berechnet. +Ein SHA-1 Hash sieht wie folgt aus: [source] ---- 24b9da6552252987aa493b52f8696cd6d3b00373 ---- -You will see these hash values all over the place in Git because it uses them so much. -In fact, Git stores everything in its database not by file name but by the hash value of its contents. +Diese Hashes begegnen einem überall bei der Arbeit, weil sie so ausgiebig von Git genutzt werden. +Tatsächlich speichert Git alles in seiner Datenbank nicht nach Dateinamen, sondern nach dem Hash-Wert seines Inhalts. -==== Git Generally Only Adds Data +==== Git fügt im Regelfall nur Daten hinzu -When you do actions in Git, nearly all of them only _add_ data to the Git database. -It is hard to get the system to do anything that is not undoable or to make it erase data in any way. -As with any VCS, you can lose or mess up changes you haven't committed yet, but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository. +Wenn Sie Aktionen in Git durchführen, werden fast alle von ihnen nur Daten zur Git-Datenbank _hinzufügen_. +Deshalb ist es sehr schwer, das System dazu zu bewegen, irgendetwas zu tun, das nicht wieder rückgängig zu machen ist, oder dazu, Daten in irgendeiner Form zu löschen. +Wie in jedem anderen VCS, kann man in Git Daten verlieren oder durcheinander bringen, solange man sie noch nicht eingecheckt hat. Aber sobald man einen Schnappschuss in Git eingecheckt hat, ist es sehr schwierig, diese Daten wieder zu verlieren, insbesondere wenn man regelmäßig seine lokale Datenbank auf ein anderes Repository hochlädt. -This makes using Git a joy because we know we can experiment without the danger of severely screwing things up. -For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see <>. +Unter anderem deshalb macht es so viel Spaß mit Git zu arbeiten. Man weiß genau, man kann ein wenig experimentieren, ohne befürchten zu müssen, irgendetwas zu zerstören oder durcheinander zu bringen. +Wer sich genauer dafür interessiert, wie Git Daten speichert und wie man Daten, die scheinbar verloren sind, wiederherstellen kann, dem wird das Kapitel 2, <>, ans Herz gelegt.. -==== The Three States +==== Die drei Zustände -Pay attention now -- here is the main thing to remember about Git if you want the rest of your learning process to go smoothly. -Git has three main states that your files can reside in: _modified_, _staged_, and _committed_: +Jetzt heißt es aufgepasst! – Es folgt die wichtigste Information, die man sich merken muss, wenn man Git erlernen und dabei Fallstricke vermeiden will. +Git definiert drei Hauptzustände, in denen sich eine Datei befinden kann: committet (engl. _committed_), geändert (engl. _modified_) und für Commit vorgemerkt (engl. _staged_). -* Modified means that you have changed the file but have not committed it to your database yet. -* Staged means that you have marked a modified file in its current version to go into your next commit snapshot. -* Committed means that the data is safely stored in your local database. +* *Modified* bedeutet, dass eine Datei geändert, aber noch nicht in die lokale Datenbank eingecheckt wurde. +* *Staged* bedeutet, dass eine geänderte Datei in ihrem gegenwärtigen Zustand für den nächsten Commit vorgemerkt ist. +* *Committed* bedeutet, dass die Daten sicher in der lokalen Datenbank gespeichert sind. -This leads us to the three main sections of a Git project: the working tree, the staging area, and the Git directory. +Das führt uns zu den drei Hauptbereichen eines Git-Projekts: dem Verzeichnisbaum, der sogenannten Staging-Area und dem Git-Verzeichnis. -.Working tree, staging area, and Git directory. +.Verzeichnisbaum, Staging-Area und Git-Verzeichnis. image::images/areas.png["Working tree, staging area, and Git directory."] -The working tree is a single checkout of one version of the project. -These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify. +Der Verzeichnisbaum ist ein einzelner Abschnitt einer Version des Projekts. +Diese Dateien werden aus der komprimierten Datenbank im Git-Verzeichnis geholt und auf der Festplatte so abgelegt, damit Sie sie verwenden oder ändern können. -The staging area is a file, generally contained in your Git directory, that stores information about what will go into your next commit. -Its technical name in Git parlance is the ``index'', but the phrase ``staging area'' works just as well. +Die Staging-Area ist in der Regel eine Datei, die sich in Ihrem Git-Verzeichnis befindet und Informationen darüber speichert, was in Ihren nächsten Commit einfließen soll. +Der technische Name im Git-Sprachgebrauch ist „Index“, aber der Ausdruck „Staging Area“ funktioniert genauso gut. -The Git directory is where Git stores the metadata and object database for your project. -This is the most important part of Git, and it is what is copied when you _clone_ a repository from another computer. +Im Git-Verzeichnis werden die Metadaten und die Objektdatenbank für Ihr Projekt gespeichert. +Das ist der wichtigste Teil von Git, dieser Teil wird kopiert, wenn man ein Repository von einem anderen Rechner _klont_. -The basic Git workflow goes something like this: +Der grundlegende Git-Arbeitsablauf sieht in etwa so aus: -1. You modify files in your working tree. -2. You selectively stage just those changes you want to be part of your next commit, which adds _only_ those changes to the staging area. -3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory. +1. Sie ändern Dateien in Ihrem Verzeichnisbaum. +2. Sie stellen selektiv Änderungen bereit, die Sie bei Ihrem nächsten Commit berücksichtigen möchten, wodurch nur diese Änderungen in den Staging-Bereich aufgenommen werden. +3. Sie führen einen Commit aus, der die Dateien so übernimmt, wie sie sich in der Staging-Area befinden und diesen Snapshot dauerhaft in Ihrem Git-Verzeichnis speichert. -If a particular version of a file is in the Git directory, it's considered _committed_. -If it has been modified and was added to the staging area, it is _staged_. -And if it was changed since it was checked out but has not been staged, it is _modified_. -In <>, you'll learn more about these states and how you can either take advantage of them or skip the staged part entirely. +Wenn sich eine bestimmte Version einer Datei im Git-Verzeichnis befindet, wird sie als _committed_ betrachtet. +Wenn sie geändert und in die Staging-Area hinzugefügt wurde, gilt sie als für den Commit _vorgemerkt_ (engl. _staged_). +Und wenn sie geändert, aber noch nicht zur Staging-Area hinzugefügt wurde, gilt sie als _geändert_ (engl. _modified_). +Im Kapitel 2, <>, werden diese drei Zustände noch näher erläutert und wie man diese sinnvoll einsetzen kann oder alternativ, wie man den Zwischenschritt der Staging-Area überspringen kann. diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index ea7a21ca..e3ea053a 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -1,47 +1,47 @@ [[_getting_a_repo]] -=== Getting a Git Repository +=== Ein Git Repository anlegen -You typically obtain a Git repository in one of two ways: +Sie haben zwei Möglichkeiten, ein Git Repository auf Ihrem Rechner anzulegen. -1. You can take a local directory that is currently not under version control, and turn it into a Git repository, or -2. You can _clone_ an existing Git repository from elsewhere. +1. Sie können ein lokales Verzeichnis, das sich derzeit nicht unter Versionskontrolle befindet, in ein Git-Repository verwandeln, oder +2. Sie können ein bestehendes Git-Repository von einem anderen Ort aus _klonen_. -In either case, you end up with a Git repository on your local machine, ready for work. +In beiden Fällen erhalten Sie ein einsatzbereites Git-Repository auf Ihrem lokalen Rechner. -==== Initializing a Repository in an Existing Directory +==== Ein Repository in einem bestehenden Verzeichnis einrichten -If you have a project directory that is currently not under version control and you want to start controlling it with Git, you first need to go to that project's directory. -If you've never done this, it looks a little different depending on which system you're running: +Wenn Sie ein Projektverzeichnis haben, das sich derzeit nicht unter Versionskontrolle befindet, und Sie mit der Kontrolle über Git beginnen möchten, müssen Sie zunächst in das Verzeichnis dieses Projekts wechseln. +Wenn Sie dies noch nie getan haben, sieht es je nachdem, welches System Sie verwenden, etwas anders aus: -for Linux: +für Linux: [source,console] ---- $ cd /home/user/my_project ---- -for macOS: +für macOS: [source,console] ---- $ cd /Users/user/my_project ---- -for Windows: +für Windows: [source,console] ---- $ cd /c/user/my_project ---- -and type: +dann folgenden Befehl eingeben: [source,console] ---- $ git init ---- -This creates a new subdirectory named `.git` that contains all of your necessary repository files -- a Git repository skeleton. -At this point, nothing in your project is tracked yet. -(See <> for more information about exactly what files are contained in the `.git` directory you just created.)(((git commands, init))) +Der Befehl erzeugt ein Unterverzeichnis `.git`, in dem alle relevanten Git Repository Daten enthalten sind, also ein Git Repository Grundgerüst. +Zu diesem Zeitpunkt werden noch keine Dateien in Git versioniert. +(In Kapitel 10, <>, finden Sie weitere Informationen, welche Dateien im `.git` Verzeichnis enthalten sind und was ihre Aufgabe ist.)(((Git Befehle, init))) -If you want to start version-controlling existing files (as opposed to an empty directory), you should probably begin tracking those files and do an initial commit. -You can accomplish that with a few `git add` commands that specify the files you want to track, followed by a `git commit`: +Wenn Sie bereits existierende Dateien versionieren möchten (und es sich nicht nur um ein leeres Verzeichnis handelt), dann sollten Sie den aktuellen Stand in einem initialen Commit starten. +Mit dem Befehl `git add` legen Sie fest, welche Dateien versioniert werden sollen und mit dem Befehl `git commit` erzeugen Sie einen neuen Commit: [source,console] ---- @@ -50,38 +50,38 @@ $ git add LICENSE $ git commit -m 'initial project version' ---- -We'll go over what these commands do in just a minute. -At this point, you have a Git repository with tracked files and an initial commit. +Wir werden gleich noch einmal genauer auf diese Befehle eingehen. +Im Moment ist nur wichtig, dass Sie verstehen, dass Sie jetzt ein Git Repository erzeugt und einen ersten Commit angelegt haben. [[_git_cloning]] -==== Cloning an Existing Repository +==== Ein existierendes Repository klonen -If you want to get a copy of an existing Git repository -- for example, a project you'd like to contribute to -- the command you need is `git clone`. -If you're familiar with other VCS systems such as Subversion, you'll notice that the command is "clone" and not "checkout". -This is an important distinction -- instead of getting just a working copy, Git receives a full copy of nearly all data that the server has. -Every version of every file for the history of the project is pulled down by default when you run `git clone`. -In fact, if your server disk gets corrupted, you can often use nearly any of the clones on any client to set the server back to the state it was in when it was cloned (you may lose some server-side hooks and such, but all the versioned data would be there -- see <> for more details). +Wenn Sie eine Kopie eines existierenden Git Repositorys anlegen wollen – um beispielsweise an einem Projekt mitzuarbeiten – können Sie den Befehl `git clone` verwenden. +Wenn Sie bereits Erfahrung mit einem anderen VCS System, wie Subversion, gesammelt haben, fällt Ihnen bestimmt sofort auf, dass der Befehl „clone“ und nicht etwa „checkout“ lautet. +Das ist ein wichtiger Unterschied, den Sie unbedingt verstehen sollten – Anstatt nur eine einfache Arbeitskopie vom Projekt zu erzeugen, lädt Git nahezu alle Daten, die der Server bereithält, auf den lokalen Rechner. +Jede Version von jeder Datei der Projekt-Historie wird automatisch heruntergeladen, wenn Sie `git clone` ausführen. +Wenn Ihre Serverfestplatte beschädigt wird, können Sie oft nahezu jeden der Klone auf irgendeinem Client verwenden, um den Server wieder in den Zustand zurückzusetzen, in dem er sich zum Zeitpunkt des Klonens befand (Sie werden vielleicht einige serverseitige Hooks und dergleichen verlieren, aber alle versionierten Daten wären vorhanden - siehe Kapitel 4, <>, für weitere Details). -You clone a repository with `git clone `.(((git commands, clone))) -For example, if you want to clone the Git linkable library called `libgit2`, you can do so like this: +Sie können ein Repository mit dem Befehl `git clone [url]` klonen.(((Git Befehle, clone))) +Um beispielsweise das Repository der verlinkbaren Git Bibliothek `libgit2` zu klonen, führen Sie den folgenden Befehl aus: [source,console] ---- $ git clone https://github.com/libgit2/libgit2 ---- -That creates a directory named `libgit2`, initializes a `.git` directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. -If you go into the new `libgit2` directory that was just created, you'll see the project files in there, ready to be worked on or used. +Git legt dann ein Verzeichnis `libgit2` an, initialisiert in diesem ein `.git` Verzeichnis, lädt alle Daten des Repositorys herunter, und checkt eine Arbeitskopie der aktuellsten Version aus. +Wenn Sie in das neue `libgit2` Verzeichnis wechseln, finden Sie dort die Projektdateien und können gleich damit arbeiten. -If you want to clone the repository into a directory named something other than `libgit2`, you can specify the new directory name as an additional argument: +Wenn Sie das Repository in ein Verzeichnis mit einem anderen Namen als `libgit2` klonen möchten, können Sie das wie folgt durchführen: [source,console] ---- $ git clone https://github.com/libgit2/libgit2 mylibgit ---- -That command does the same thing as the previous one, but the target directory is called `mylibgit`. +Dieser Befehl tut das gleiche wie der vorhergehende, aber das Zielverzeichnis lautet diesmal `mylibgit`. -Git has a number of different transfer protocols you can use. -The previous example uses the `https://` protocol, but you may also see `git://` or `user@server:path/to/repo.git`, which uses the SSH transfer protocol. -<> will introduce all of the available options the server can set up to access your Git repository and the pros and cons of each. +Git unterstützt eine Reihe unterschiedlicher Übertragungsprotokolle. +Das vorhergehende Beispiel verwendet das `https://` Protokoll, aber Ihnen können auch die Angaben `git://` oder `user@server:path/to/repo.git` begegnen, welches das SSH-Transfer-Protokoll verwendet. +Kapitel 4, <>, stellt alle verfügbaren Optionen vor, die der Server für den Zugriff auf Ihr Git-Repository hat und die Vor- und Nachteile der einzelnen Optionen, die man einrichten kann. diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index e48751fc..a4b2a33d 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -1,26 +1,26 @@ -=== Recording Changes to the Repository +=== Änderungen nachverfolgen und im Repository speichern -At this point, you should have a _bona fide_ Git repository on your local machine, and a checkout or _working copy_ of all of its files in front of you. -Typically, you'll want to start making changes and committing snapshots of those changes into your repository each time the project reaches a state you want to record. +An dieser Stelle sollten Sie ein _originalgetreues_ Git-Repository auf Ihrem lokalen Computer und eine Checkout- oder Arbeitskopie aller seiner Dateien vor sich haben. +Normalerweise werden Sie damit beginnen wollen, Änderungen vorzunehmen und Schnappschüsse dieser Änderungen in Ihr Repository zu übertragen, wenn das Projekt so weit fortgeschritten ist, dass Sie es sichern möchten. -Remember that each file in your working directory can be in one of two states: _tracked_ or _untracked_. -Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. -In short, tracked files are files that Git knows about. +Denken Sie daran, dass sich jede Datei in Ihrem Arbeitsverzeichnis in einem von zwei Zuständen befinden kann: _tracked_ oder _untracked_ – Änderungen an der Datei werden verfolgt (engl. _tracked_) oder eben nicht (engl. _untracked_). +Alle Dateien, die sich im letzten Schnappschuss (Commit) befanden, werden in der Versionsverwaltung nachverfolgt. Sie können entweder unverändert, modifiziert oder für den nächsten Commit vorgemerkt (staged) sein. +Kurz gesagt sind getrackte, versionierte Dateien, Daten, die Git kennt. -Untracked files are everything else -- any files in your working directory that were not in your last snapshot and are not in your staging area. -When you first clone a repository, all of your files will be tracked and unmodified because Git just checked them out and you haven't edited anything. +Alle anderen Dateien in Ihrem Arbeitsverzeichnis dagegen, sind nicht versioniert: das sind all diejenigen Dateien, die nicht schon im letzten Schnappschuss enthalten waren und die sich nicht in der Staging-Area befinden. +Wenn Sie ein Repository zum ersten Mal klonen, sind alle Dateien versioniert und unverändert. Nach dem Klonen wurden sie ja ausgecheckt und bis dahin haben Sie ja auch noch nichts an ihnen verändert. -As you edit files, Git sees them as modified, because you've changed them since your last commit. -As you work, you selectively stage these modified files and then commit all those staged changes, and the cycle repeats. +Sobald Sie anfangen, versionierte Dateien zu bearbeiten, erkennt Git diese als modifiziert, weil sie sich im Vergleich zum letzten Commit verändert haben. +Die geänderten Dateien können Sie dann für den nächsten Commit vormerken und schließlich alle Änderungen, die sich in der Staging-Area befinden, einchecken/committen. Danach wiederholt sich der Zyklus. -.The lifecycle of the status of your files. +.Der Status Ihrer Dateien im Überblick. image::images/lifecycle.png[The lifecycle of the status of your files.] [[_checking_status]] -==== Checking the Status of Your Files +==== Zustand von Dateien prüfen -The main tool you use to determine which files are in which state is the `git status` command.(((git commands, status))) -If you run this command directly after a clone, you should see something like this: +Das wichtigste Hilfsmittel, um den Zustand zu überprüfen, in dem sich Ihre Dateien gerade befinden, ist der Befehl `git status`.(((Git Befehle, status))) +Wenn Sie diesen Befehl unmittelbar nach dem Klonen eines Repositorys ausführen, sollte er in etwa folgende Ausgabe liefern: [source,console] ---- @@ -30,14 +30,14 @@ Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean ---- -This means you have a clean working directory; in other words, none of your tracked files are modified. -Git also doesn't see any untracked files, or they would be listed here. -Finally, the command tells you which branch you're on and informs you that it has not diverged from the same branch on the server. -For now, that branch is always ``master'', which is the default; you won't worry about it here. -<> will go over branches and references in detail. +Dieser Zustand wird auch als sauberes Arbeitsverzeichnis (engl. clean working directory) bezeichnet. +Mit anderen Worten, es gibt keine Dateien, die unter Versionsverwaltung stehen und seit dem letzten Commit geändert wurden – andernfalls würden sie hier aufgelistet werden. +Außerdem teilt Ihnen der Befehl mit, auf welchem Branch Sie gerade arbeiten und informiert Sie darüber, dass dieser sich im Vergleich zum Branch auf dem Server nicht verändert hat. +Momentan ist dieser Zweig immer `master`, was der Vorgabe entspricht; Sie müssen sich jetzt nicht darum kümmern. +Wir werden im Kapitel <> auf Branches detailliert eingehen. -Let's say you add a new file to your project, a simple `README` file. -If the file didn't exist before, and you run `git status`, you see your untracked file like so: +Nehmen wir einmal an, Sie fügen eine neue Datei mit dem Namen `README` zu Ihrem Projekt hinzu. +Wenn die Datei zuvor nicht existiert hat und Sie jetzt `git status` ausführen, zeigt Git die bisher nicht versionierte Datei wie folgt an: [source,console] ---- @@ -53,23 +53,23 @@ Untracked files: nothing added to commit but untracked files present (use "git add" to track) ---- -You can see that your new `README` file is untracked, because it's under the ``Untracked files'' heading in your status output. -Untracked basically means that Git sees a file you didn't have in the previous snapshot (commit); Git won't start including it in your commit snapshots until you explicitly tell it to do so. -It does this so you don't accidentally begin including generated binary files or other files that you did not mean to include. -You do want to start including `README`, so let's start tracking the file. +Alle Dateien, die im Abschnitt „Untracked files“ aufgelistet werden, sind Dateien, die bisher noch nicht versioniert sind. Dort wird jetzt auch die Datei `README` angezeigt. +Mit anderen Worten, die Datei README wird in diesem Bereich gelistet, weil sie im letzten Schnappschuss nicht enthalten war. Git nimmt eine solche Datei nicht automatisch in die Versionsverwaltung auf, sondern Sie müssen Git dazu ausdrücklich auffordern. +Ansonsten würden generierte Binärdateien oder andere Dateien, die Sie nicht in Ihrem Repository haben möchten, automatisch hinzugefügt werden. Das möchte man in den meisten Fällen vermeiden. +Jetzt wollen wir aber Änderungen an der Datei `README` verfolgen und fügen sie deshalb zur Versionsverwaltung hinzu. [[_tracking_files]] -==== Tracking New Files +==== Neue Dateien zur Versionsverwaltung hinzufügen -In order to begin tracking a new file, you use the command `git add`.(((git commands, add))) -To begin tracking the `README` file, you can run this: +Um eine neue Datei zu versionieren, können Sie den Befehl `git add` verwenden.(((Git Befehle, add))) +Für Ihre neue `README` Datei, können Sie folgendes ausführen: [source,console] ---- $ git add README ---- -If you run your status command again, you can see that your `README` file is now tracked and staged to be committed: +Wenn Sie den `git status` Befehl erneut ausführen, werden Sie sehen, dass sich Ihre README Datei jetzt unter Versionsverwaltung befindet und für den nächsten Commit vorgemerkt ist: [source,console] ---- @@ -83,15 +83,15 @@ Changes to be committed: ---- -You can tell that it's staged because it's under the ``Changes to be committed'' heading. -If you commit at this point, the version of the file at the time you ran `git add` is what will be in the subsequent historical snapshot. -You may recall that when you ran `git init` earlier, you then ran `git add ` -- that was to begin tracking files in your directory.(((git commands, init)))(((git commands, add))) -The `git add` command takes a path name for either a file or a directory; if it's a directory, the command adds all the files in that directory recursively. +Sie können erkennen, dass die Datei für den nächsten Commit vorgemerkt ist, weil sie unter der Rubrik „Changes to be committed“ aufgelistet ist. +Wenn Sie jetzt einen Commit anlegen, wird der Schnappschuss den Zustand der Datei festhalten, den sie zum Zeitpunkt des Befehls `git add` hat. +Sie erinnern sich vielleicht daran, wie Sie vorhin `git init` und anschließend `git add ` ausgeführt haben. Mit diesen Befehlen haben Sie die Dateien in Ihrem Verzeichnis zur Versionsverwaltung hinzugefügt.(((Git Befehle, init)))(((Git Befehle, add))) +Der `git add` Befehl akzeptiert einen Pfadnamen einer Datei oder eines Verzeichnisses. Wenn Sie ein Verzeichnis angeben, fügt `git add` alle Dateien in diesem Verzeichnis und allen Unterverzeichnissen rekursiv hinzu. -==== Staging Modified Files +==== Geänderte Dateien zur Staging-Area hinzufügen -Let's change a file that was already tracked. -If you change a previously tracked file called `CONTRIBUTING.md` and then run your `git status` command again, you get something that looks like this: +Lassen Sie uns jetzt eine bereits versionierte Datei ändern. +Wenn Sie zum Beispiel eine bereits unter Versionsverwaltung stehende Datei mit dem Dateinamen `CONTRIBUTING.md` ändern und danach den Befehl `git status` erneut ausführen, erhalten Sie in etwa folgende Ausgabe: [source,console] ---- @@ -111,11 +111,11 @@ Changes not staged for commit: ---- -The `CONTRIBUTING.md` file appears under a section named ``Changes not staged for commit'' -- which means that a file that is tracked has been modified in the working directory but not yet staged. -To stage it, you run the `git add` command. -`git add` is a multipurpose command -- you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved. -It may be helpful to think of it more as ``add precisely this content to the next commit'' rather than ``add this file to the project''.(((git commands, add))) -Let's run `git add` now to stage the `CONTRIBUTING.md` file, and then run `git status` again: +Die Datei `CONTRIBUTING.md` erscheint im Abschnitt „Changed but not staged for commit“ – das bedeutet, dass eine versionierte Datei im Arbeitsverzeichnis verändert worden ist, aber noch nicht für den Commit vorgemerkt wurde. +Um sie vorzumerken, führen Sie den Befehl `git add` aus. +Der Befehl `git add` wird zu vielen verschiedenen Zwecken eingesetzt. Man verwendet ihn, um neue Dateien zur Versionsverwaltung hinzuzufügen, Dateien für einen Commit vorzumerken und verschiedene andere Dinge – beispielsweise, einen Konflikt aus einem Merge als aufgelöst zu kennzeichnen. +Leider wird der Befehl `git add` wird oft missverstanden, viele assoziieren damit, dass damit Dateien zum Projekt hinzufügt werden. Wie Sie aber gerade gelernt haben, wird der Befehl auch noch für viele andere Dinge eingesetzt. Wenn Sie den Befehl `git add` einsetzen, sollten Sie das eher so sehen, dass Sie damit einen bestimmten Inhalt für den nächsten Commit vormerken.(((git commands, add))) +Lassen Sie uns nun mit `git add` die Datei `CONTRIBUTING.md` zur Staging-Area hinzufügen und danach das Ergebnis mit `git status` kontrollieren: [source,console] ---- @@ -131,10 +131,10 @@ Changes to be committed: ---- -Both files are staged and will go into your next commit. -At this point, suppose you remember one little change that you want to make in `CONTRIBUTING.md` before you commit it. -You open it again and make that change, and you're ready to commit. -However, let's run `git status` one more time: +Beide Dateien sind nun für den nächsten Commit vorgemerkt. +Nehmen wir an, Sie wollen jetzt aber noch eine weitere Änderung an der Datei `CONTRIBUTING.md` vornehmen, bevor Sie den Commit tatsächlich starten. +Sie öffnen die Datei erneut, ändern sie entsprechend ab und eigentlich wären Sie ja jetzt bereit den Commit durchzuführen. +Allerdings lassen Sie uns vorher noch einmal den Befehl `git status` ausführen: [source,console] ---- @@ -156,12 +156,12 @@ Changes not staged for commit: ---- -What the heck? -Now `CONTRIBUTING.md` is listed as both staged _and_ unstaged. -How is that possible? -It turns out that Git stages a file exactly as it is when you run the `git add` command. -If you commit now, the version of `CONTRIBUTING.md` as it was when you last ran the `git add` command is how it will go into the commit, not the version of the file as it looks in your working directory when you run `git commit`. -If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file: +Was zum Kuckuck ...? +Jetzt wird die Datei `CONTRIBUTING.md` sowohl in der Staging-Area, als auch als geändert aufgelistet. +Wie ist das möglich? +Die Erklärung dafür ist, dass Git eine Datei in exakt dem Zustand für den Commit vormerkt, in dem sie sich befindet, wenn Sie den Befehl `git add` ausführen. +Wenn Sie den Commit jetzt anlegen, wird die Version der Datei `CONTRIBUTING.md` denjenigen Inhalt haben, den sie hatte, als Sie `git add` zuletzt ausgeführt haben – und nicht denjenigen, den sie in dem Moment hat, wenn Sie den Befehl `git commit` ausführen. +Wenn Sie stattdessen die gegenwärtige Version im Commit haben möchten, müssen Sie erneut `git add` ausführen, um die Datei der Staging-Area hinzuzufügen: [source,console] ---- @@ -176,11 +176,11 @@ Changes to be committed: modified: CONTRIBUTING.md ---- -==== Short Status +==== Kompakter Status -While the `git status` output is pretty comprehensive, it's also quite wordy. -Git also has a short status flag so you can see your changes in a more compact way. -If you run `git status -s` or `git status --short` you get a far more simplified output from the command: +Die Ausgabe von `git status` ist sehr umfassend und auch ziemlich wortreich. +Git hat auch ein Kurzformat, mit dem Sie Ihre Änderungen kompakter sehen können. +Wenn Sie `git status -s` oder `git status -short` ausführen, erhalten Sie eine kürzere Darstellung des Befehls: [source,console] ---- @@ -192,18 +192,18 @@ M lib/simplegit.rb ?? LICENSE.txt ---- -New files that aren't tracked have a `??` next to them, new files that have been added to the staging area have an `A`, modified files have an `M` and so on. -There are two columns to the output -- the left-hand column indicates the status of the staging area and the right-hand column indicates the status of the working tree. -So for example in that output, the `README` file is modified in the working directory but not yet staged, while the `lib/simplegit.rb` file is modified and staged. -The `Rakefile` was modified, staged and then modified again, so there are changes to it that are both staged and unstaged. +Neue Dateien, die nicht versioniert werden, haben `??` neben sich, neue Dateien, die dem Staging-Area hinzugefügt wurden, haben ein `A`, geänderte Dateien haben ein `M` usw. +Es gibt zwei Spalten für die Ausgabe – die linke Spalte zeigt den Status der Staging-Area und die rechte Spalte den Status des Verzeichnisbaums. +So ist beispielsweise in der Bildschirmausgabe oben, die Datei `README` im Arbeitsverzeichnis geändert, aber noch nicht staged, während die Datei `lib/simplegit.rb` geändert und staged ist. +Das `Rakefile` wurde modifiziert, staged und dann wieder modifiziert, so dass es Änderungen an ihm gibt, die sowohl staged als auch unstaged sind. [[_ignoring]] -==== Ignoring Files +==== Ignorieren von Dateien -Often, you'll have a class of files that you don't want Git to automatically add or even show you as being untracked. -These are generally automatically generated files such as log files or files produced by your build system. -In such cases, you can create a file listing patterns to match them named `.gitignore`.(((ignoring files))) -Here is an example `.gitignore` file: +Häufig gibt es eine Reihe von Dateien, die Git nicht automatisch hinzufügen oder schon gar nicht als „nicht versioniert“ (eng. untracked) anzeigen soll. +Dazu gehören in der Regel automatisch generierte Dateien, wie Log-Dateien oder Dateien, die von Ihrem Build-System erzeugt werden. +In solchen Fällen können Sie die Datei `.gitignore` erstellen, die eine Liste mit Vergleichsmustern enthält.(((ignoring files))) +Hier ist eine `.gitignore` Beispieldatei: [source,console] ---- @@ -212,24 +212,24 @@ $ cat .gitignore *~ ---- -The first line tells Git to ignore any files ending in ``.o'' or ``.a'' -- object and archive files that may be the product of building your code. -The second line tells Git to ignore all files whose names end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files. -You may also include a log, tmp, or pid directory; automatically generated documentation; and so on. -Setting up a `.gitignore` file for your new repository before you get going is generally a good idea so you don't accidentally commit files that you really don't want in your Git repository. +Die erste Zeile weist Git an, alle Dateien zu ignorieren, die auf „.o“ oder „.a“ enden – Objekt- und Archivdateien, die das Ergebnis der Codegenerierung sein könnten. +Die zweite Zeile weist Git an, alle Dateien zu ignorieren, deren Name mit einer Tilde (`~`) enden, was von vielen Texteditoren wie Emacs zum Markieren temporärer Dateien verwendet wird. +Sie können auch ein Verzeichnis log, tmp oder pid hinzufügen, eine automatisch generierte Dokumentation usw. +Es ist im Allgemeinen eine gute Idee, die `.gitignore` Datei für Ihr neues Repository einzurichten, noch bevor Sie loslegen. So können Sie nicht versehentlich Dateien committen, die Sie wirklich nicht in Ihrem Git-Repository haben möchten. -The rules for the patterns you can put in the `.gitignore` file are as follows: +Die Richtlinien für Vergleichsmuster, die Sie in der Datei `.gitignore` eingeben können, lauten wie folgt: -* Blank lines or lines starting with `#` are ignored. -* Standard glob patterns work, and will be applied recursively throughout the entire working tree. -* You can start patterns with a forward slash (`/`) to avoid recursivity. -* You can end patterns with a forward slash (`/`) to specify a directory. -* You can negate a pattern by starting it with an exclamation point (`!`). +* Leerzeilen oder Zeilen, die mit `#` beginnen, werden ignoriert. +* Standard Platzhalter-Zeichen funktionieren und werden rekursiv im gesamten Verzeichnisbaum angewendet. +* Sie können Vergleichsmuster mit einem Schrägstrich (`/`) **beginnen**, um die Rekursivität zu verhindern. +* Sie können Vergleichsmuster mit einem Schrägstrich (`/`) **beenden**, um ein Verzeichnis anzugeben. +* Sie können ein Vergleichsmuster verbieten, indem Sie es mit einem Ausrufezeichen (`!`) beginnen. -Glob patterns are like simplified regular expressions that shells use. -An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen (`[0-9]`) matches any character between them (in this case 0 through 9). -You can also use two asterisks to match nested directories; `a/**/z` would match `a/z`, `a/b/z`, `a/b/c/z`, and so on. +Platzhalter-Zeichen sind wie einfache, reguläre Ausdrücke, die von der Shell genutzt werden. +Ein Sternchen (`*`) entspricht null oder mehr Zeichen; `[abc]` entspricht jedem Zeichen innerhalb der eckigen Klammern (in diesem Fall a, b oder c); ein Fragezeichen (`?`) entspricht einem einzelnen Zeichen und eckige Klammern, die durch einen Bindestrich (`[0-9]`) getrennte Zeichen einschließen, passen zu jedem Zeichen dazwischen (in diesem Fall von 0 bis 9). +Sie können auch zwei Sterne verwenden, um verschachtelte Verzeichnisse abzugleichen; `a/**/z` würde zu `a/z`, `a/b/z`, `a/b/c/z`, `a/b/c/z`, usw. passen. -Here is another example `.gitignore` file: +Hier ist eine weitere `.gitignore` Beispieldatei: [source] ---- @@ -254,29 +254,29 @@ doc/**/*.pdf [TIP] ==== -GitHub maintains a fairly comprehensive list of good `.gitignore` file examples for dozens of projects and languages at https://github.com/github/gitignore[] if you want a starting point for your project. +GitHub unterhält eine ziemlich umfassende Liste guter `.gitignore` Beispiel-Dateien für Dutzende von Projekten und Sprachen auf https://github.com/github/gitignore[], falls Sie einen Ansatzpunkt für Ihr Projekt suchen. ==== [NOTE] ==== -In the simple case, a repository might have a single `.gitignore` file in its root directory, which applies recursively to the entire repository. -However, it is also possible to have additional `.gitignore` files in subdirectories. -The rules in these nested `.gitignore` files apply only to the files under the directory where they are located. -(The Linux kernel source repository has 206 `.gitignore` files.) +Im einfachsten Fall kann ein Repository eine einzelne `.gitignore` Datei in seinem Root-Verzeichnis haben, die rekursiv für das gesamte Repository gilt. +Es ist aber auch möglich, weitere `.gitignore` Dateien in Unterverzeichnissen anzulegen. +Die Regeln dieser verschachtelten `.gitignore` Dateien gelten nur für die in dem Verzeichnis (und unterhalb) liegenden Dateien. +(Das Linux-Kernel-Source-Repository hat beispielsweise 206 `.gitignore` Dateien.) -It is beyond the scope of this book to get into the details of multiple `.gitignore` files; see `man gitignore` for the details. +Es würde den Rahmen dieses Buches sprengen detaillierter auf den Einsatz mehrerer `.gitignore` Dateien einzugehen; siehe die Manpage `man gitignore` für weitere Innformationen. ==== [[_git_diff_staged]] -==== Viewing Your Staged and Unstaged Changes +==== Überprüfen der Staged und Unstaged Änderungen -If the `git status` command is too vague for you -- you want to know exactly what you changed, not just which files were changed -- you can use the `git diff` command.(((git commands, diff))) -We'll cover `git diff` in more detail later, but you'll probably use it most often to answer these two questions: What have you changed but not yet staged? -And what have you staged that you are about to commit? -Although `git status` answers those questions very generally by listing the file names, `git diff` shows you the exact lines added and removed -- the patch, as it were. +Wenn der Befehl `git status` für Sie zu vage ist – Sie wollen genau wissen, was Sie geändert haben, nicht nur welche Dateien geändert wurden – können Sie den Befehl `git diff` verwenden.(((git commands, diff))) +Wir werden `git diff` später ausführlicher behandeln, aber Sie werden es wahrscheinlich am häufigsten verwenden, um diese beiden Fragen zu beantworten: Was hat sich geändert, ist aber noch nicht zum Commit vorgemerkt (engl. staged)? +Und was haben Sie zum Commit vorgemerkt und können es demnächst committen? +Der Befehl `git status` beantwortet diese Fragen ganz allgemein, indem er die Dateinamen auflistet, `git diff` zeigt Ihnen aber genau die hinzugefügten und entfernten Zeilen – sozusagen den Patch. -Let's say you edit and stage the `README` file again and then edit the `CONTRIBUTING.md` file without staging it. -If you run your `git status` command, you once again see something like this: +Nehmen wir an, Sie bearbeiten und merken die Datei `README` zum Commit vor (eng. stage) und bearbeiten dann die Datei `CONTRIBUTING.md`, ohne sie zu „stagen“. +Wenn Sie den Befehl `git status` ausführen, sehen Sie erneut so etwas wie das hier: [source,console] ---- @@ -295,7 +295,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -To see what you've changed but not yet staged, type `git diff` with no other arguments: +Um die Änderungen zu sehen, die Sie noch nicht zum Commit vorgemerkt haben, geben Sie den Befehl `git diff`, ohne weitere Argumente, ein: [source,console] ---- @@ -316,11 +316,11 @@ index 8ebb991..643e24f 100644 that highlights your work in progress (and note in the PR title that it's ---- -That command compares what is in your working directory with what is in your staging area. -The result tells you the changes you've made that you haven't yet staged. +Dieses Kommando vergleicht, was sich in Ihrem Arbeitsverzeichnis befindet, mit dem, was sich in Ihrer Staging-Area befindet. +Die Bildschirmanzeige gibt Ihnen an, welche Änderungen Sie vorgenommen haben, die noch nicht „gestaged“ sind. -If you want to see what you've staged that will go into your next commit, you can use `git diff --staged`. -This command compares your staged changes to your last commit: +Wenn Sie wissen wollen, was Sie zum Commit vorgemerkt haben, das in Ihren nächsten Commit einfließt, können Sie `git diff --staged` verwenden. +Dieser Befehl vergleicht Ihre zum Commit vorgemerkten Änderungen mit Ihrem letzten Commit: [source,console] ---- @@ -334,11 +334,11 @@ index 0000000..03902a1 +My Project ---- -It's important to note that `git diff` by itself doesn't show all changes made since your last commit -- only changes that are still unstaged. -If you've staged all of your changes, `git diff` will give you no output. +Es ist wichtig zu wissen, dass `git diff` von sich aus nicht alle Änderungen seit Ihrem letzten Commit anzeigt – nur die Änderungen, die noch „unstaged“ sind. +Wenn Sie alle Ihre Änderungen bereits „gestaged“ haben, wird `git diff` Ihnen keine Antwort geben. -For another example, if you stage the `CONTRIBUTING.md` file and then edit it, you can use `git diff` to see the changes in the file that are staged and the changes that are unstaged. -If our environment looks like this: +Ein weiteres Beispiel: wenn Sie die Datei `CONTRIBUTING.md` zum Commit vormerken und dann wieder bearbeiten, können Sie mit `git diff` die Änderungen in der „staged“ Datei und die „unstaged“ Änderungen sehen. +Wenn Sie folgendes gemacht haben: [source,console] ---- @@ -359,7 +359,7 @@ Changes not staged for commit: modified: CONTRIBUTING.md ---- -Now you can use `git diff` to see what is still unstaged: +Jetzt können Sie mit `git diff` sehen, was noch nicht zum Commit vorgemerkt ist: [source,console] ---- @@ -375,7 +375,7 @@ index 643e24f..87f08c8 100644 +# test line ---- -and `git diff --cached` to see what you've staged so far (`--staged` and `--cached` are synonyms): +und `git diff --cached` zeigt Ihnen, was Sie bisher zum Commit vorgemerkt haben (`--staged` und `--cached` sind Synonyme, sie bewirken das Gleiche): [source,console] ---- @@ -397,32 +397,32 @@ index 8ebb991..643e24f 100644 ---- [NOTE] -.Git Diff in an External Tool +.Git Diff mit einem externen Tool ==== -We will continue to use the `git diff` command in various ways throughout the rest of the book. -There is another way to look at these diffs if you prefer a graphical or external diff viewing program instead. -If you run `git difftool` instead of `git diff`, you can view any of these diffs in software like emerge, vimdiff and many more (including commercial products). -Run `git difftool --tool-help` to see what is available on your system. +Wir werden den Befehl `git diff` im weiteren Verlauf des Buches auf vielfältige Weise verwenden. +Es gibt eine weitere Methode, diese Diffs zu betrachten, wenn Sie lieber ein graphisches oder externes Diff-Viewing-Programm bevorzugen. +Wenn Sie `git difftool` anstelle von `git diff` verwenden, können Sie alle diese Unterschiede in einer Software wie emerge, vimdiff und viele andere (einschließlich kommerzieller Produkte) anzeigen lassen. +Führen Sie den Befehl `git difftool --tool-help` aus, um zu sehen, was auf Ihrem System verfügbar ist. ==== [[_committing_changes]] -==== Committing Your Changes +==== Die Änderungen committen -Now that your staging area is set up the way you want it, you can commit your changes. -Remember that anything that is still unstaged -- any files you have created or modified that you haven't run `git add` on since you edited them -- won't go into this commit. -They will stay as modified files on your disk. -In this case, let's say that the last time you ran `git status`, you saw that everything was staged, so you're ready to commit your changes.(((git commands, status))) -The simplest way to commit is to type `git commit`:(((git commands, commit))) +Nachdem Ihre Staging-Area nun so eingerichtet ist, wie Sie es wünschen, können Sie Ihre Änderungen committen. +Denken Sie daran, dass alles, was noch nicht zum Commit vorgemerkt ist – alle Dateien, die Sie erstellt oder geändert haben und für die Sie seit Ihrer Bearbeitung nicht mehr `git add` ausgeführt haben – nicht in diesen Commit einfließen werden. +Sie bleiben aber als geänderte Dateien auf Ihrer Festplatte erhalten. +In diesem Beispiel nehmen wir an, dass Sie beim letzten Mal, als Sie `git status` ausgeführt haben, gesehen haben, dass alles zum Commit vorgemerkt wurde und bereit sind, Ihre Änderungen zu committen.(((git commands, status))) +Am einfachsten ist es, wenn Sie `git commit` eingeben:(((git commands, commit))) [source,console] ---- $ git commit ---- -Doing so launches your editor of choice. -(This is set by your shell's `EDITOR` environment variable -- usually vim or emacs, although you can configure it with whatever you want using the `git config --global core.editor` command as you saw in <>).(((editor, changing default)))(((git commands, config))) +Dadurch wird der Editor Ihrer Wahl gestartet. +(Das wird durch die Umgebungsvariable `EDITOR` Ihrer Shell festgelegt – normalerweise vim oder emacs, wie Sie es mit dem Befehl `git config --global core.editor` beliebig konfigurieren können und wie Sie es in Kapitel 1, <>, gesehen haben).(((editor, changing default)))(((git commands, config))) -The editor displays the following text (this example is a Vim screen): +Der Editor zeigt den folgenden Text an (dieses Beispiel ist eine Vim-Ansicht): [source] ---- @@ -442,13 +442,13 @@ The editor displays the following text (this example is a Vim screen): ".git/COMMIT_EDITMSG" 9L, 283C ---- -You can see that the default commit message contains the latest output of the `git status` command commented out and one empty line on top. -You can remove these comments and type your commit message, or you can leave them there to help you remember what you're committing. -(For an even more explicit reminder of what you've modified, you can pass the `-v` option to `git commit`. -Doing so also puts the diff of your change in the editor so you can see exactly what changes you're committing.) -When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out). +Sie können erkennen, dass die Standard-Commit-Meldung die neueste Ausgabe des auskommentierten Befehls `git status` und eine leere Zeile darüber enthält. +Sie können diese Kommentare entfernen und Ihre Commit-Nachricht eingeben oder Sie können sie dort stehen lassen, damit Sie sich merken können, was Sie committen. +(Für eine noch bessere Gedächtnisstütze über das, was Sie geändert haben, können Sie die Option `-v` an `git commit` übergeben. +Dadurch wird auch die Differenz Ihrer Änderung in den Editor geschrieben, so dass Sie genau sehen können, welche Änderungen Sie committen.) +Wenn Sie den Editor verlassen, erstellt Git Ihren Commit mit dieser Commit-Nachricht (mit den Kommentaren und ausgeblendetem diff). -Alternatively, you can type your commit message inline with the `commit` command by specifying it after a `-m` flag, like this: +Alternativ können Sie Ihre Commit-Nachricht auch inline mit dem Befehl `commit -m` eingeben. Das `-m` Flag ermöglicht die direkte Eingabe eines Kommentar-Textes: [source,console] ---- @@ -458,19 +458,19 @@ $ git commit -m "Story 182: Fix benchmarks for speed" create mode 100644 README ---- -Now you've created your first commit! -You can see that the commit has given you some output about itself: which branch you committed to (`master`), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit. +Jetzt haben Sie Ihren ersten Commit erstellt! +Sie können sehen, dass der Commit eine Nachricht über sich selbst ausgegeben hat: in welchen Branch Sie committed haben (`master`), welche SHA-1-Prüfsumme der Commit hat (`463dc4f`), wie viele Dateien geändert wurden, und Statistiken über hinzugefügte und entfernte Zeilen im Commit. -Remember that the commit records the snapshot you set up in your staging area. -Anything you didn't stage is still sitting there modified; you can do another commit to add it to your history. -Every time you perform a commit, you're recording a snapshot of your project that you can revert to or compare to later. +Denken Sie daran, dass der Commit den Snapshot aufzeichnet, den Sie in Ihrer Staging-Area eingerichtet haben. +Alles, was von Ihnen nicht zum Commit vorgemerkt wurde, liegt immer noch als modifiziert da. Sie können einen weiteren Commit durchführen, um es zu Ihrer Historie hinzuzufügen. +Jedes Mal, wenn Sie einen Commit ausführen, zeichnen Sie einen Schnappschuss Ihres Projekts auf, auf den Sie zurückgreifen oder mit einem späteren Zeitpunkt vergleichen können. -==== Skipping the Staging Area +==== Die Staging Area überspringen (((staging area, skipping))) -Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. -If you want to skip the staging area, Git provides a simple shortcut. -Adding the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part: +Obwohl es außerordentlich nützlich sein kann, Commits so zu erstellen, wie Sie es wünschen, ist die Staging-Area manchmal etwas komplexer, als Sie es für Ihren Workflow benötigen. +Wenn Sie die Staging-Area überspringen möchten, bietet Git eine einfache Kurzform. +Durch das Hinzufügen der Option `-a` zum Befehl `git commit` wird jede Datei, die bereits vor dem Commit versioniert war, automatisch von Git zum Commit vorgemerkt (engl. staged), so dass Sie den Teil `git add` überspringen können: [source,console] ---- @@ -489,18 +489,18 @@ $ git commit -a -m 'added new benchmarks' 1 file changed, 5 insertions(+), 0 deletions(-) ---- -Notice how you don't have to run `git add` on the `CONTRIBUTING.md` file in this case before you commit. -That's because the `-a` flag includes all changed files. -This is convenient, but be careful; sometimes this flag will cause you to include unwanted changes. +Beachten Sie, dass Sie in diesem Fall `git add` nicht auf der Datei `CONTRIBUTING.md` ausführen müssen, bevor Sie committen. +Das liegt daran, dass das `-a` Flag alle geänderten Dateien einschließt. +Das ist bequem, aber seien Sie vorsichtig. Manchmal führt dieses Flag dazu, dass Sie ungewollte Änderungen vornehmen. [[_removing_files]] -==== Removing Files +==== Dateien löschen (((files, removing))) -To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. -The `git rm` command does that, and also removes the file from your working directory so you don't see it as an untracked file the next time around. +Um eine Datei aus Git zu entfernen, müssen Sie sie aus der Versionsverwaltung entfernen (genauer gesagt, aus Ihrem Staging-Bereich löschen) und dann committen. +Der Befehl `git rm` erledigt das und entfernt die Datei auch aus Ihrem Arbeitsverzeichnis, so dass Sie sie beim nächsten Mal nicht mehr als „untracked“ Datei sehen. -If you simply remove the file from your working directory, it shows up under the ``Changes not staged for commit'' (that is, _unstaged_) area of your `git status` output: +Wenn Sie die Datei einfach aus Ihrem Arbeitsverzeichnis entfernen, erscheint sie unter dem "Changes not staged for commit"-Bereich (das ist die _unstaged_-Area) Ihrer `git status`-Ausgabe: [source,console] ---- @@ -517,7 +517,7 @@ Changes not staged for commit: no changes added to commit (use "git add" and/or "git commit -a") ---- -Then, if you run `git rm`, it stages the file's removal: +Wenn Sie dann `git rm` ausführen, wird die Entfernung der Datei zum Commit vorgemerkt: [source,console] ---- @@ -532,58 +532,58 @@ Changes to be committed: deleted: PROJECTS.md ---- -The next time you commit, the file will be gone and no longer tracked. -If you modified the file or had already added it to the staging area, you must force the removal with the `-f` option. -This is a safety feature to prevent accidental removal of data that hasn't yet been recorded in a snapshot and that can't be recovered from Git. +Wenn Sie das nächste Mal einen Commit ausführen, ist die Datei weg und ist nicht mehr versioniert (engl. tracked). +Wenn Sie die Datei geändert oder bereits zur Staging-Area hinzugefügt haben, müssen Sie das Entfernen mit der Option `-f` erzwingen. +Hierbei handelt es sich um eine Sicherheitsfunktion, die ein versehentliches Entfernen von Dateien verhindert, die noch nicht in einem Snapshot aufgezeichnet wurden und die nicht von Git wiederhergestellt werden können. -Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. -In other words, you may want to keep the file on your hard drive but not have Git track it anymore. -This is particularly useful if you forgot to add something to your `.gitignore` file and accidentally staged it, like a large log file or a bunch of `.a` compiled files. -To do this, use the `--cached` option: +Eine weitere nützliche Sache, die Sie möglicherweise nutzen möchten, ist, die Datei in Ihrem Verzeichnisbaum zu behalten, sie aber aus Ihrer Staging-Area zu entfernen. +Mit anderen Worten, Sie können die Datei auf Ihrer Festplatte behalten, aber nicht mehr von Git protokollieren/versionieren lassen. +Das ist besonders dann nützlich, wenn Sie vergessen haben, etwas zu Ihrer `.gitignore` Datei hinzuzufügen und diese versehentlich „gestaged“ haben, wie eine große Logdatei oder eine Reihe von `.a` kompilierten Dateien. +Das erreichen Sie mit der Option `--cacheed`: [source,console] ---- $ git rm --cached README ---- -You can pass files, directories, and file-glob patterns to the `git rm` command. -That means you can do things such as: +Sie können Dateien, Verzeichnisse und Platzhalter-Zeichen an den Befehl `git rm` übergeben. +Das bedeutet, dass Sie folgende Möglichkeit haben: [source,console] ---- $ git rm log/\*.log ---- -Note the backslash (`\`) in front of the `*`. -This is necessary because Git does its own filename expansion in addition to your shell's filename expansion. -This command removes all files that have the `.log` extension in the `log/` directory. -Or, you can do something like this: +Beachten Sie den Backslash (`\`) vor dem `*`. +Der ist notwendig, weil Git zusätzlich zur Dateinamen-Erweiterung Ihrer Shell eine eigene Dateinamen-Erweiterung vornimmt. +Mit dem Befehl oben werden alle Dateien entfernt, die die Erweiterung `.log` im Verzeichnis `log/` haben. +oder, Sie können etwas Ähnliches ausführen: [source,console] ---- $ git rm \*~ ---- -This command removes all files whose names end with a `~`. +Das Kommando entfernt alle Dateien, deren Name mit einer `~` endet. [[_git_mv]] -==== Moving Files +==== Dateien verschieben (((files, moving))) -Unlike many other VCS systems, Git doesn't explicitly track file movement. -If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. -However, Git is pretty smart about figuring that out after the fact -- we'll deal with detecting file movement a bit later. +Im Gegensatz zu vielen anderen VCS-Systemen verfolgt (engl. track) Git das Verschieben von Dateien nicht ausdrücklich. +Wenn Sie eine Datei in Git umbenennen, werden keine Metadaten in Git gespeichert, die dem System mitteilen, dass Sie die Datei umbenannt haben. +Allerdings ist Git ziemlich clever, das im Nachhinein herauszufinden – wir werden uns etwas später mit der Erkennung von Datei-Verschiebungen befassen. -Thus it's a bit confusing that Git has a `mv` command. -If you want to rename a file in Git, you can run something like: +Daher ist es etwas verwirrend, dass Git einen Befehl `mv` vorweisen kann. +Wenn Sie eine Datei in Git umbenennen möchten, dann können Sie beispielsweise Folgendes ausführen: [source,console] ---- $ git mv file_from file_to ---- -and it works fine. -In fact, if you run something like this and look at the status, you'll see that Git considers it a renamed file: +Das funktioniert gut. +Tatsache ist, wenn Sie so einen Befehl ausführen und sich den Status ansehen, werden Sie sehen, dass Git es für eine umbenannte Datei hält: [source,console] ---- @@ -597,7 +597,7 @@ Changes to be committed: renamed: README.md -> README ---- -However, this is equivalent to running something like this: +Unabhängig davon, ist dieser Befehl zu dem Folgenden gleichwertig: [source,console] ---- @@ -606,6 +606,6 @@ $ git rm README.md $ git add README ---- -Git figures out that it's a rename implicitly, so it doesn't matter if you rename a file that way or with the `mv` command. -The only real difference is that `git mv` is one command instead of three -- it's a convenience function. -More importantly, you can use any tool you like to rename a file, and address the add/rm later, before you commit. +Git erkennt, dass es sich um eine umbenannte Datei handelt, so dass es egal ist, ob Sie eine Datei auf diese Weise oder mit dem Befehl `mv` umbenennen. +Der alleinige, reale Unterschied ist, dass `git mv` ein einziger Befehl ist statt deren drei - es ist eine Komfortfunktion. +Wichtiger ist, dass Sie jedes beliebige Tool verwenden können, um eine Datei umzubenennen und das add/rm später aufrufen können, bevor Sie committen. diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index a6780602..e7ad7718 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -1,5 +1,5 @@ [[_undoing]] -=== Undoing Things +=== Ungewollte Änderungen rückgängig machen At any stage, you may want to undo something. Here, we'll review a few basic tools for undoing changes that you've made. diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 373cc128..57bb4089 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -1,18 +1,18 @@ [[_viewing_history]] -=== Viewing the Commit History +=== Anzeigen der Commit-Historie -After you have created several commits, or if you have cloned a repository with an existing commit history, you'll probably want to look back to see what has happened. -The most basic and powerful tool to do this is the `git log` command. +Nachdem Sie mehrere Commits erstellt haben oder wenn Sie ein Repository mit einer bestehenden Commit-Historie geklont haben, werden Sie wahrscheinlich zurückschauen wollen, um zu erfahren, was geschehen ist. +Das wichtigste und mächtigste Werkzeug dafür ist der Befehl `git log`. -These examples use a very simple project called ``simplegit''. -To get the project, run +Diese Beispiele verwenden ein sehr vereinfachtes Projekt namens „simplegit“. +Um das Projekt zu erstellen, führen Sie diesen Befehl aus: [source,console] ---- $ git clone https://github.com/schacon/simplegit-progit ---- -When you run `git log` in this project, you should get output that looks something like this:(((git commands, log))) +Wenn Sie `git log` in diesem Projekt aufrufen, sollten Sie eine Ausgabe erhalten, die ungefähr so aussieht:(((git commands, log))) [source,console] ---- @@ -36,14 +36,14 @@ Date: Sat Mar 15 10:31:28 2008 -0700 first commit ---- -By default, with no arguments, `git log` lists the commits made in that repository in reverse chronological order; that is, the most recent commits show up first. -As you can see, this command lists each commit with its SHA-1 checksum, the author's name and email, the date written, and the commit message. +Standardmäßig listet `git log`, ohne Argumente, die in diesem Repository vorgenommenen Commits in umgekehrter chronologischer Reihenfolge auf, d.h. die neuesten Commits werden als erstes angezeigt. +Wie Sie sehen können, listet dieser Befehl jeden Commit mit seiner SHA-1-Prüfsumme, dem Namen und der E-Mail Adresse des Autors, dem Erstellungs-Datum und der Commit-Beschreibung auf. -A huge number and variety of options to the `git log` command are available to show you exactly what you're looking for. -Here, we'll show you some of the most popular. +Eine Vielzahl und Vielfalt von Optionen für den Befehl `git log` stehen zur Verfügung, um Ihnen exakt das anzuzeigen, wonach Sie gesucht haben. +Hier zeigen wir Ihnen einige der gängigsten. -One of the more helpful options is `-p` or `--patch`, which shows the difference (the _patch_ output) introduced in each commit. -You can also limit the number of log entries displayed, such as using `-2` to show only the last two entries. +Eine der hilfreichsten Optionen ist `-p` oder `--patch`. Sie zeigt den Unterschied (die _patch_-Ausgabe) an, der bei jedem Commit eingefügt wird. +Sie können auch die Anzahl der anzuzeigenden Protokolleinträge begrenzen, z.B. mit `-2` nur die letzten beiden Einträge darstellen. [source,console] ---- @@ -89,10 +89,10 @@ index a0a60ae..47c6340 100644 -end ---- -This option displays the same information but with a diff directly following each entry. -This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added. -You can also use a series of summarizing options with `git log`. -For example, if you want to see some abbreviated stats for each commit, you can use the `--stat` option: +Diese Option zeigt die gleichen Informationen an, jedoch mit dem Unterschied dass sie direkt hinter jedem Eintrag stehen. +Diese Funktion ist sehr hilfreich für die Code-Überprüfung oder zum schnellen Durchsuchen der Vorgänge während einer Reihe von Commits, die ein Teammitglied hinzugefügt hat. +Sie können auch eine Reihe von Optionen zur Verdichtung mit `git log` verwenden. +Wenn Sie beispielsweise einige gekürzte Statistiken für jede Übertragung sehen möchten, können Sie die Option `--stat` verwenden: [source,console] ---- @@ -127,14 +127,14 @@ Date: Sat Mar 15 10:31:28 2008 -0700 3 files changed, 54 insertions(+) ---- -As you can see, the `--stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. -It also puts a summary of the information at the end. +Wie Sie sehen können, gibt die Option `--stat` unter jedem Commit-Eintrag eine Liste der geänderten Dateien aus. Wie viele Dateien geändert wurden und wie viele Zeilen in diesen Dateien hinzugefügt und entfernt wurden. +Sie enthält auch eine Zusammenfassung am Ende des Berichts. -Another really useful option is `--pretty`. -This option changes the log output to formats other than the default. -A few prebuilt options are available for you to use. -The `oneline` option prints each commit on a single line, which is useful if you're looking at a lot of commits. -In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively: +Eine weitere wirklich nützliche Option ist `--pretty`. +Diese Option ändert das Format der Log-Ausgabe in ein anderes als das Standard-Format. +Ihnen stehen einige vorgefertigte Optionen zur Verfügung. +Die Option `oneline` druckt jeden Commit in einer einzigen Zeile, was besonders nützlich ist, wenn Sie sich viele Commits ansehen. +Darüber hinaus zeigen die Optionen `short`, `full`, und `fuller` die Ausgabe im etwa gleichen Format, allerdings mit weniger bzw. mehr Informationen: [source,console] ---- @@ -144,8 +144,8 @@ ca82a6dff817ec66f44342007202690a93763949 changed the version number a11bef06a3f659402fe7563abf99ad00de2209e6 first commit ---- -The most interesting option is `format`, which allows you to specify your own log output format. -This is especially useful when you're generating output for machine parsing -- because you specify the format explicitly, you know it won't change with updates to Git:(((log formatting))) +Die interessanteste Option ist `format`, mit der Sie Ihr eigenes Log-Ausgabeformat festlegen können. +Dieses Verfahren ist besonders nützlich, wenn Sie Ausgaben für das maschinelle Parsen generieren – da Sie das Format explizit angeben, wissen Sie, dass es sich mit Updates von Git nicht ändert:(((log formatting))) [source,console] ---- @@ -155,37 +155,37 @@ ca82a6d - Scott Chacon, 6 years ago : changed the version number a11bef0 - Scott Chacon, 6 years ago : first commit ---- -<> lists some of the more useful options that `format` takes. +<> listet einige der nützlichsten Optionen auf, die `format` bietet. [[pretty_format]] -.Useful options for `git log --pretty=format` +.Nützliche Optionen für `git log --pretty=format` [cols="1,4",options="header"] |================================ -| Option | Description of Output -| `%H` | Commit hash -| `%h` | Abbreviated commit hash -| `%T` | Tree hash -| `%t` | Abbreviated tree hash -| `%P` | Parent hashes -| `%p` | Abbreviated parent hashes -| `%an` | Author name -| `%ae` | Author email -| `%ad` | Author date (format respects the --date=option) -| `%ar` | Author date, relative -| `%cn` | Committer name -| `%ce` | Committer email -| `%cd` | Committer date -| `%cr` | Committer date, relative -| `%s` | Subject +| Option | Beschreibung der Ausgabe +| `%H` | Commit Hash +| `%h` | gekürzter Commit Hash +| `%T` | Hash-Baum +| `%t` | gekürzter Hash-Baum +| `%P` | Eltern-Hashes +| `%p` | gekürzte Eltern-Hashes +| `%an` | Name des Autors +| `%ae` | E-Mail Adresse des Autors +| `%ad` | Erstellungs-Datum des Autors (Format berücksichtigt --date=option) +| `%ar` | relatives Erstellungs-Datum des Autors +| `%cn` | Name des Committers +| `%ce` | E-Mail Adresse des Committers +| `%cd` | Erstellungs-Datum des Committers +| `%cr` | relatives Erstellungs-Datum des Committers +| `%s` | Thema |================================ -You may be wondering what the difference is between _author_ and _committer_. -The author is the person who originally wrote the work, whereas the committer is the person who last applied the work. -So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit -- you as the author, and the core member as the committer. -We'll cover this distinction a bit more in <>. +Sie fragen sich vielleicht, worin der Unterschied zwischen _Autor_ und _Committer_ besteht. +Der Autor ist die Person, die das Werk ursprünglich geschrieben hat, während der Committer die Person ist, die das Werk zuletzt bearbeitet hat. +Wenn Sie also einen Patch an ein Projekt senden und eines der Core-Mitglieder den Patch einbindet, erhalten Sie beide die Anerkennung - Sie als Autor und das Core-Mitglied als Committer. +Wir werden diese Unterscheidung näher erläutern in Kapitel 5, <>. -The `oneline` and `format` options are particularly useful with another `log` option called `--graph`. -This option adds a nice little ASCII graph showing your branch and merge history: +Die Optionen `oneline` und `format` sind vor allem bei einer anderen `log`-Option mit Bezeichnung `--graph` hilfreich. +Diese Option fügt ein schönes kleines ASCII-Diagramm hinzu, das Ihren Branch und den Merge-Verlauf zeigt: [source,console] ---- @@ -202,85 +202,85 @@ $ git log --pretty=format:"%h %s" --graph * 11d191e Merge branch 'defunkt' into local ---- -This type of output will become more interesting as we go through branching and merging in the next chapter. +Dieser Ausgabetyp wird immer interessanter, wenn wir im nächsten Kapitel über das Branching und Merging sprechen. -Those are only some simple output-formatting options to `git log` -- there are many more. -<> lists the options we've covered so far, as well as some other common formatting options that may be useful, along with how they change the output of the log command. +Das sind nur einige einfache Optionen zur Ausgabe-Formatierung von `git log` – es gibt noch viele mehr. +<> listet die bisher von uns behandelten Optionen auf, sowie einige andere gängige Format-Optionen, die sinnvoll sein können, um die Ausgabe des log-Befehls zu ändern. [[log_options]] -.Common options to `git log` +.Allgemeine Optionen für `git log` [cols="1,4",options="header"] |================================ -| Option | Description -| `-p` | Show the patch introduced with each commit. -| `--stat` | Show statistics for files modified in each commit. -| `--shortstat` | Display only the changed/insertions/deletions line from the --stat command. -| `--name-only` | Show the list of files modified after the commit information. -| `--name-status` | Show the list of files affected with added/modified/deleted information as well. -| `--abbrev-commit` | Show only the first few characters of the SHA-1 checksum instead of all 40. -| `--relative-date` | Display the date in a relative format (for example, ``2 weeks ago'') instead of using the full date format. -| `--graph` | Display an ASCII graph of the branch and merge history beside the log output. -| `--pretty` | Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format). -| `--oneline` | Shorthand for `--pretty=oneline --abbrev-commit` used together. +| Option | Beschreibung +| `-p` | Zeigt den Patch an, der mit den jeweiligen Commits eingefügt wurde. +| `--stat` | Anzeige der Statistiken für Dateien, die in den einzelnen Commits geändert wurden. +| `--shortstat` | Anzeige nur der geänderten/eingefügten/gelöschten Zeile des Befehls --stat. +| `--name-only` | Listet die Dateien auf, die nach den Commit-Informationen geändert wurden. +| `--name-status` | Listet die Dateien auf, die von hinzugefügten, geänderten oder gelöschten Informationen betroffen sind. +| `--abbrev-commit` | Zeigt nur die ersten paar Zeichen der SHA-1-Prüfsumme an, nicht aber alle 40. +| `--relative-date` | Zeigt das Datum in einem relativen Format an (z.B. „vor 2 Wochen“), anstatt das volle Datumsformat zu verwenden. +| `--graph` | Zeigt ein ASCII-Diagramm der Branch an und verbindet die Historie mit der Log-Ausgabe. +| `--pretty` | Zeigt Commits in einem anderen Format an. Zu den Optionen gehören oneline, short, full, fuller und format (womit Sie Ihr eigenes Format angeben können). +| `--oneline` | Kurzform für die gleichzeitige Verwendung von `--pretty=oneline` und `--abbrev-commit`. |================================ -==== Limiting Log Output +==== Einschränken der Log-Ausgabe -In addition to output-formatting options, `git log` takes a number of useful limiting options; that is, options that let you show only a subset of commits. -You've seen one such option already -- the `-2` option, which displays only the last two commits. -In fact, you can do `-`, where `n` is any integer to show the last `n` commits. -In reality, you're unlikely to use that often, because Git by default pipes all output through a pager so you see only one page of log output at a time. +Zusätzlich zu den Optionen für die Ausgabe-Formatierung bietet `git log` eine Reihe nützlicher einschränkender Optionen, d.h. Optionen, mit denen Sie nur eine Teilmenge von Commits anzeigen können. +Sie haben eine solche Option bereits gesehen – die Option `-2`, die nur die letzten beiden Commits anzeigt. +In Wahrheit können Sie `-` verwenden, wobei `n` eine beliebige ganze Zahl ist, um die letzten `n` Commits anzuzeigen. +In der Praxis werden Sie das kaum verwenden, da Git standardmäßig alle Ausgaben über einen Pager leitet, so dass Sie jeweils nur eine Seite der Log-Ausgabe sehen. -However, the time-limiting options such as `--since` and `--until` are very useful. -For example, this command gets the list of commits made in the last two weeks: +Die zeitbeschränkenden Optionen wie `--since` und `--until` sind sehr nützlich. +Dieser Befehl ruft z.B. die Liste der in den letzten beiden Wochen durchgeführten Commits ab: [source,console] ---- $ git log --since=2.weeks ---- -This command works with lots of formats -- you can specify a specific date like `"2008-01-15"`, or a relative date such as `"2 years 1 day 3 minutes ago"`. +Dieser Befehl funktioniert mit vielen Formaten – Sie können ein bestimmtes Datum wie `„2008-01-15“` angeben, oder ein relatives Datum wie `„vor 2 Jahren 1 Tag 3 Minuten“`. -You can also filter the list to commits that match some search criteria. -The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. +Sie können die Liste auch nach Commits filtern, die bestimmten Suchkriterien entsprechen. +Mit der Option `--author` können Sie nach einem bestimmten Autoren filtern, und mit der Option `--grep` können Sie nach Schlüsselwörtern in den Übertragungsmeldungen suchen. [NOTE] ==== -You can specify more than one instance of both the `--author` and `--grep` search criteria, which -will limit the commit output to commits that match _any_ of the `--author` patterns and _any_ -of the `--grep` patterns; however, adding the `--all-match` option further limits the output to -just those commits that match _all_ `--grep` patterns. +Sie können mehr als eine Instanz der Suchkriterien `--author` und `--grep` angeben, +was die Commit-Ausgabe auf Commits beschränkt, die _jedem_ der `--author`-Muster und _jedem_ der `--grep`-Muster entsprechen; +durch Hinzufügen der Option `--all-match` wird die Ausgabe jedoch weiter auf diejenigen Commits beschränkt, +die _allen_ `--grep`-Mustern entsprechen. ==== -Another really helpful filter is the `-S` option (colloquially referred to as Git's ``pickaxe'' option), which takes a string and shows only those commits that changed the number of occurrences of that string. -For instance, if you wanted to find the last commit that added or removed a reference to a specific function, you could call: +Ein weiterer wirklich hilfreicher Filter ist die Option `-S` (umgangssprachlich als Git's „Pickel“-Option bezeichnet), die eine Zeichenkette übernimmt und nur die Commits anzeigt, die die Anzahl der Vorkommen dieses Strings geändert haben. +Wenn Sie beispielsweise das letzte Commit suchen möchten, das einen Verweis auf eine bestimmte Funktion hinzugefügt oder entfernt hat, können Sie Folgendes aufrufen: [source,console] ---- $ git log -S function_name ---- -The last really useful option to pass to `git log` as a filter is a path. -If you specify a directory or file name, you can limit the log output to commits that introduced a change to those files. -This is always the last option and is generally preceded by double dashes (`--`) to separate the paths from the options. +Zuletzt eine wirklich nützliche Option, die Sie als Filter an `git log` übergeben können, der Pfad. +Wenn Sie ein Verzeichnis oder einen Dateinamen angeben, können Sie die Log-Ausgabe auf Commits beschränken, die eine Änderung an diesen Dateien vorgenommen haben. +Das ist immer die letzte Option und wird in der Regel durch Doppelstriche (`--`) eingeleitet, um Pfade von den Optionen zu trennen. In <> we'll list these and a few other common options for your reference. [[limit_options]] -.Options to limit the output of `git log` +.Optionen zur Anpassen der Ausgabe von `git log` [cols="2,4",options="header"] |================================ -| Option | Description -| `-` | Show only the last n commits -| `--since`, `--after` | Limit the commits to those made after the specified date. -| `--until`, `--before` | Limit the commits to those made before the specified date. -| `--author` | Only show commits in which the author entry matches the specified string. -| `--committer` | Only show commits in which the committer entry matches the specified string. -| `--grep` | Only show commits with a commit message containing the string -| `-S` | Only show commits adding or removing code matching the string +| Option | Beschreibung +| `-` | Zeigt nur die letzten n Commits an +| `--since`, `--after` | Begrenzt die angezeigten Commits auf die, die nach dem angegebenen Datum gemacht wurden. +| `--until`, `--before` | Begrenzt die angezeigten Commits auf die, die vor dem angegebenen Datum gemacht wurden. +| `--author` | Zeigt nur Commits an, bei denen der Autoren-Eintrag mit der angegebenen Zeichenkette übereinstimmt. +| `--committer` | Zeigt nur Commits an, bei denen der Committer-Eintrag mit der angegebenen Zeichenkette übereinstimmt. +| `--grep` | Zeigt nur Commits an, deren Commit-Beschreibung die Zeichenkette enthält +| `-S` | Zeigt nur Commits an, die solchen Code hinzufügen oder entfernen, der mit der Zeichenkette übereinstimmt |================================ -For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano in the month of October 2008 and are not merge commits, you can run something like this:(((log filtering))) +Wenn Sie zum Beispiel sehen möchten, welche der Commits, die Testdateien in der Git-Quellcode-Historie ändern, die von Junio Hamano im Monat Oktober 2008 committed wurden und keine Merge-Commits sind, können Sie etwa so aufrufen:(((log filtering))) [source,console] ---- @@ -294,11 +294,11 @@ d1a43f2 - reset --hard/read-tree --reset -u: remove unmerged new paths b0ad11e - pull: allow "git pull origin $something:$current_branch" into an unborn branch ---- -Of the nearly 40,000 commits in the Git source code history, this command shows the 6 that match those criteria. +Von den fast 40.000 Commits in der Git-Quellcode-Historie zeigt dieser Befehl die 6 Commits an, die diesen Kriterien entsprechen. [TIP] -.Preventing the display of merge commits +.Die Anzeige von Merge-Commits unterdrücken ==== -Depending on the workflow used in your repository, it's possible that a sizable percentage of the commits in your log history are just merge commits, which typically aren't very informative. -To prevent the display of merge commits cluttering up your log history, simply add the log option `--no-merges`. +Abhängig von dem in Ihrem Repository verwendeten Workflow ist es möglich, dass ein beträchtlicher Prozentsatz der Commits in Ihrer Log-Historie nur Merge-Commits sind, die in der Regel nicht sehr informativ sind. +Um zu vermeiden, dass die Anzeige von Merge-Commits Ihren Log-Verlauf überflutet, fügen Sie einfach die Log-Option `--no-merges` hinzu. ==== diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index 946cf5ae..b30bf501 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -1,98 +1,98 @@ -=== The Protocols +=== Die Protokolle -Git can use four distinct protocols to transfer data: Local, HTTP, Secure Shell (SSH) and Git. -Here we'll discuss what they are and in what basic circumstances you would want (or not want) to use them. +Git kann vier verschiedene Protokolle für die Datenübertragung verwenden: Lokal, HTTP, Secure Shell (SSH) und Git. +Hier werden wir klären, worum es sich handelt und unter welchen Rahmenbedingungen Sie sie verwenden könnten (oder nicht sollten). -==== Local Protocol +==== Lokales Protokoll (((protocols, local))) -The most basic is the _Local protocol_, in which the remote repository is in another directory on the same host. -This is often used if everyone on your team has access to a shared filesystem such as an NFS mount, or in the less likely case that everyone logs in to the same computer. -The latter wouldn't be ideal, because all your code repository instances would reside on the same computer, making a catastrophic loss much more likely. +Das einfachste ist das _lokale Protokoll_, bei dem sich das entfernte Repository in einem anderen Verzeichnis auf demselben Host befindet. +Es wird häufig verwendet, wenn jeder in Ihrem Team Zugriff auf ein freigegebenes Dateisystem wie z.B. ein NFS-Mount hat, oder in dem selteneren Fall, dass sich jeder auf dem gleichen Computer anmeldet. +Letzteres wäre nicht ideal, da sich alle Ihre Code-Repository-Instanzen auf demselben Computer befinden würden, was einen katastrophalen Verlust viel wahrscheinlicher macht. -If you have a shared mounted filesystem, then you can clone, push to, and pull from a local file-based repository. -To clone a repository like this, or to add one as a remote to an existing project, use the path to the repository as the URL. -For example, to clone a local repository, you can run something like this: +Wenn Sie ein gemeinsam genutztes gemountetes Dateisystem haben, können Sie ein lokales dateibasiertes Repository klonen, dort hin verschieben (engl. push to) und daraus ziehen (engl. pull). +Verwenden Sie den Pfad zum Repository als URL, um ein solches Repository zu klonen oder einem vorhandenen Projekt ein Remote-Repository hinzuzufügen. +Um beispielsweise ein lokales Repository zu klonen, können Sie Folgendes ausführen: [source,console] ---- $ git clone /srv/git/project.git ---- -Or you can do this: +oder auch das: [source,console] ---- $ git clone file:///srv/git/project.git ---- -Git operates slightly differently if you explicitly specify `file://` at the beginning of the URL. -If you just specify the path, Git tries to use hardlinks or directly copy the files it needs. -If you specify `file://`, Git fires up the processes that it normally uses to transfer data over a network, which is generally much less efficient. -The main reason to specify the `file://` prefix is if you want a clean copy of the repository with extraneous references or objects left out -- generally after an import from another VCS or something similar (see <> for maintenance tasks). -We'll use the normal path here because doing so is almost always faster. +Git funktioniert etwas anders, wenn Sie `file://` explizit am Anfang der URL angeben. +Wenn Sie nur den Pfad angeben, versucht Git, Hardlinks zu verwenden oder die benötigten Dateien direkt zu kopieren. +Wenn Sie `file://` angeben, löst Git Prozesse aus, die normalerweise zum Übertragen von Daten über ein Netzwerk verwendet werden, was im Allgemeinen viel weniger effizient ist. +Der Hauptgrund für die Angabe des Präfix `file://` ist, wenn Sie eine saubere Kopie des Repositorys mit fremden Referenzen oder weggelassenen Objekten wünschen – in der Regel nach einem Import aus einem anderen VCS oder ähnlichem (siehe <> für Wartungsaufgaben. +Wir werden hier den normalen Pfad verwenden, denn das ist fast immer schneller. -To add a local repository to an existing Git project, you can run something like this: +Um ein lokales Repository zu einem bestehenden Git-Projekt hinzuzufügen, kann so vorgegangen werden: [source,console] ---- $ git remote add local_proj /srv/git/project.git ---- -Then, you can push to and pull from that remote via your new remote name `local_proj` as though you were doing so over a network. +Dann können Sie über Ihren neuen Remote-Namen `local_proj` auf dieses Remote-Repository pushen und von dort abrufen, als ob Sie dies über ein Netzwerk tun würden. -===== The Pros +===== Vorteile -The pros of file-based repositories are that they're simple and they use existing file permissions and network access. -If you already have a shared filesystem to which your whole team has access, setting up a repository is very easy. -You stick the bare repository copy somewhere everyone has shared access to and set the read/write permissions as you would for any other shared directory. -We'll discuss how to export a bare repository copy for this purpose in <>. +Die Vorteile dateibasierter Repositorys liegen darin, dass sie einfach sind und vorhandene Datei- und Netzwerk-Berechtigungen verwenden. +Wenn Sie bereits über ein freigegebenes Dateisystem verfügen, auf das Ihr gesamtes Team Zugriff hat, ist das Einrichten eines Repositorys sehr einfach. +Sie speichern die leere Repository-Kopie an einer Stelle, auf die jeder Zugriff hat, und legen die Lese- und Schreibberechtigungen wie bei jedem anderen freigegebenen Verzeichnis fest. +Informationen zum Exportieren einer Bare-Repository-Kopie für diesen Zweck finden Sie unter <>. -This is also a nice option for quickly grabbing work from someone else's working repository. -If you and a co-worker are working on the same project and they want you to check something out, running a command like `git pull /home/john/project` is often easier than them pushing to a remote server and you subsequently fetching from it. +Das ist auch eine elegante Möglichkeit, um schnell Arbeiten aus dem Arbeits-Repository eines anderen zu holen. +Wenn Sie und ein Mitarbeiter am gleichen Projekt arbeiten und Sie etwas überprüfen möchten, ist es oft einfacher, einen Befehl wie `git pull /home/john/project` auszuführen, als auf einen Remote-Server zu pushen und anschließend von dort zu holen. -===== The Cons +===== Nachteile -The cons of this method are that shared access is generally more difficult to set up and reach from multiple locations than basic network access. -If you want to push from your laptop when you're at home, you have to mount the remote disk, which can be difficult and slow compared to network-based access. +Der Nachteil dieser Methode ist, dass der gemeinsame Zugriff in der Regel schwieriger einzurichten ist damit man von mehreren Standorten aus erreichbar ist als der einfache Netzwerkzugriff. +Wenn Sie von zu Hause mit Ihrem Laptop aus pushen möchten, müssen Sie das entfernte Verzeichnis einhängen (engl. mounten), was im Vergleich zum netzwerkbasierten Zugriff schwierig und langsamer sein kann. -It's important to mention that this isn't necessarily the fastest option if you're using a shared mount of some kind. -A local repository is fast only if you have fast access to the data. -A repository on NFS is often slower than the repository over SSH on the same server, allowing Git to run off local disks on each system. +Es ist wichtig zu erwähnen, dass es nicht unbedingt die schnellste Option ist, wenn Sie einen gemeinsamen Mount verwenden. +Ein lokales Repository ist nur dann schnell, wenn Sie schnellen Zugriff auf die Daten haben. +Ein Repository auf NFS-Mounts ist oft langsamer als der Zugriff auf das Repository über SSH auf demselben Server, während Git lokale Festplatten in jedem System nutzt. -Finally, this protocol does not protect the repository against accidental damage. -Every user has full shell access to the ``remote'' directory, and there is nothing preventing them from changing or removing internal Git files and corrupting the repository. +Schließlich schützt dieses Protokoll das Repository nicht vor unbeabsichtigten Schäden. + Jeder Benutzer hat vollen Shell-Zugriff auf das „remote“ Verzeichnis, und nichts hindert ihn daran, interne Git-Dateien zu ändern oder zu entfernen und das Repository zu beschädigen. -==== The HTTP Protocols +==== HTTP Protokolle -Git can communicate over HTTP using two different modes. -Prior to Git 1.6.6, there was only one way it could do this which was very simple and generally read-only. -In version 1.6.6, a new, smarter protocol was introduced that involved Git being able to intelligently negotiate data transfer in a manner similar to how it does over SSH. -In the last few years, this new HTTP protocol has become very popular since it's simpler for the user and smarter about how it communicates. -The newer version is often referred to as the _Smart_ HTTP protocol and the older way as _Dumb_ HTTP. -We'll cover the newer Smart HTTP protocol first. +Git kann über HTTP in zwei verschiedenen Modi kommunizieren. +Vor Git 1.6.6 gab es nur einen einzigen Weg, der sehr einfach und im Allgemeinen „read-only“ war. +Mit der Version 1.6.6 wurde ein neues, intelligenteres Protokoll eingeführt, bei dem Git in der Lage ist, den Datentransfer intelligent auszuhandeln, ähnlich wie bei SSH. +In den letzten Jahren ist dieses neue HTTP-Protokoll sehr beliebt geworden, da es für den Benutzer einfacher und intelligenter in der Kommunikation ist. +Die neuere Version wird oft als _Smart_ HTTP Protokoll und die ältere als _Dumb_ HTTP bezeichnet. +Wir werden zuerst das neuere Smart HTTP-Protokoll besprechen. ===== Smart HTTP (((protocols, smart HTTP))) -Smart HTTP operates very similarly to the SSH or Git protocols but runs over standard HTTPS ports and can use various HTTP authentication mechanisms, meaning it's often easier on the user than something like SSH, since you can use things like username/password authentication rather than having to set up SSH keys. +Smart HTTP funktioniert sehr ähnlich wie die Protokolle SSH oder Git, läuft aber über Standard HTTPS-Ports und kann verschiedene HTTP-Authentifizierungsmechanismen verwenden, was bedeutet, dass es für den Benutzer oft einfacher ist als so etwas wie SSH, da Sie Eingaben wie Benutzername/Passwort-Authentifizierung verwenden können, anstatt SSH-Schlüssel einrichten zu müssen. -It has probably become the most popular way to use Git now, since it can be set up to both serve anonymously like the `git://` protocol, and can also be pushed over with authentication and encryption like the SSH protocol. -Instead of having to set up different URLs for these things, you can now use a single URL for both. -If you try to push and the repository requires authentication (which it normally should), the server can prompt for a username and password. -The same goes for read access. +Es ist wahrscheinlich der beliebteste Weg, heute Git zu verwenden, da es so eingerichtet werden kann, dass es sowohl anonym wie das Protokoll `git://` arbeitet, als auch mit Authentifizierung und Verschlüsselung wie das SSH-Protokoll betrieben werden kann. +Anstatt dafür verschiedene URLs einrichten zu müssen, können Sie nun eine einzige URL für beides verwenden. +Wenn Sie versuchen, einen Push durchzuführen und das Repository eine Authentifizierung erfordert (was normalerweise der Fall sein sollte), kann der Server nach einem Benutzernamen und einem Passwort fragen. +Gleiches gilt für den Lesezugriff. -In fact, for services like GitHub, the URL you use to view the repository online (for example, https://github.com/schacon/simplegit[]) is the same URL you can use to clone and, if you have access, push over. +Für Dienste, wie GitHub, ist die URL, die Sie verwenden, um das Repository online anzuzeigen (z.B. https://github.com/schacon/simplegit[]), die gleiche URL, mit der Sie klonen und, wenn Sie Zugriff haben, verschieben können. ===== Dumb HTTP (((protocols, dumb HTTP))) -If the server does not respond with a Git HTTP smart service, the Git client will try to fall back to the simpler _Dumb_ HTTP protocol. -The Dumb protocol expects the bare Git repository to be served like normal files from the web server. -The beauty of Dumb HTTP is the simplicity of setting it up. -Basically, all you have to do is put a bare Git repository under your HTTP document root and set up a specific `post-update` hook, and you're done (See <>). -At that point, anyone who can access the web server under which you put the repository can also clone your repository. -To allow read access to your repository over HTTP, do something like this: +Wenn der Server nicht mit einem Git HTTP Smart Service antwortet, versucht der Git Client, auf das einfachere _Dumb_ HTTP Protokoll zurückzugreifen.. +Das Dumb-Protokoll erwartet von dem Bare-Git-Repository, dass es vom Webserver wie normale Dateien handelt wird. +Das Schöne an Dumb HTTP ist die Einfachheit der Einrichtung. +Im Grunde genommen müssen Sie nur ein leeres Git-Repository unter Ihre HTTP-Dokument-Root legen und einen bestimmten `post-update` Hook einrichten, und schon sind Sie fertig (siehe <>). +Ab diesem Zeitpunkt kann jeder, der auf den Webserver zugreifen kann, unter dem Sie das Repository ablegen, auch Ihr Repository klonen. +Um Lesezugriff auf Ihr Repository über HTTP zu ermöglichen, gehen Sie wie folgt vor: [source,console] ---- @@ -103,103 +103,103 @@ $ mv hooks/post-update.sample hooks/post-update $ chmod a+x hooks/post-update ---- -That's all.(((hooks, post-update))) -The `post-update` hook that comes with Git by default runs the appropriate command (`git update-server-info`) to make HTTP fetching and cloning work properly. -This command is run when you push to this repository (over SSH perhaps); then, other people can clone via something like +Das war's.(((hooks, post-update))) +Der `post-update` Hook, der standardmäßig mit Git geliefert wird, führt den entsprechenden Befehl (`git update-server-info`) aus, um das HTTP-Abrufen und -Kloning ordnungsgemäß zu ermöglichen. +Dieser Befehl wird ausgeführt, wenn Sie in dieses Repository pushen (vielleicht über SSH); dann können andere Leute klonen über so etwas wie: [source,console] ---- $ git clone https://example.com/gitproject.git ---- -In this particular case, we're using the `/var/www/htdocs` path that is common for Apache setups, but you can use any static web server -- just put the bare repository in its path. -The Git data is served as basic static files (see the <> chapter for details about exactly how it's served). +In diesem speziellen Fall verwenden wir den Pfad `/var/www/htdocs`, der für Apache-Installationen üblich ist, Sie können aber jeden statischen Webserver verwenden – legen Sie einfach das leere Repository in seinen Pfad. +Die Git-Daten werden als einfache statische Dateien bereitgestellt (siehe Kapitel <> für Bedienungsdetails). -Generally you would either choose to run a read/write Smart HTTP server or simply have the files accessible as read-only in the Dumb manner. -It's rare to run a mix of the two services. +Im Allgemeinen würden Sie sich entweder einen Smart HTTP-Server zum Lesen und Schreiben betreiben oder die Dateien einfach als schreibgeschützt im Dumb-Modus zur Verfügung stellen. +Seltener wird ein Mix aus beiden Diensten angeboten. -===== The Pros +===== Vorteile -We'll concentrate on the pros of the Smart version of the HTTP protocol. +Wir werden uns auf die Vorteile der Smart Version des HTTP-Protokolls konzentrieren. -The simplicity of having a single URL for all types of access and having the server prompt only when authentication is needed makes things very easy for the end user. -Being able to authenticate with a username and password is also a big advantage over SSH, since users don't have to generate SSH keys locally and upload their public key to the server before being able to interact with it. -For less sophisticated users, or users on systems where SSH is less common, this is a major advantage in usability. -It is also a very fast and efficient protocol, similar to the SSH one. +Die Tatsache, dass eine einzige URL für alle Zugriffsarten und der Server-Prompt nur dann gebraucht wird, wenn eine Authentifizierung erforderlich ist, macht die Sache für den Endbenutzer sehr einfach. +Die Authentifizierung mit einem Benutzernamen und einem Passwort ist ebenfalls ein großer Vorteil gegenüber SSH, da Benutzer keine SSH-Schlüssel lokal generieren und ihren öffentlichen Schlüssel auf den Server hochladen müssen, bevor sie mit ihm interagieren können. +Für weniger anspruchsvolle Benutzer oder Benutzer auf Systemen, auf denen SSH weniger verbreitet ist, ist dies ein großer Vorteil in der Benutzerfreundlichkeit. +Es ist auch ein sehr schnelles und effizientes Protokoll, ähnlich dem SSH-Protokoll. -You can also serve your repositories read-only over HTTPS, which means you can encrypt the content transfer; or you can go so far as to make the clients use specific signed SSL certificates. +Sie können Ihre Repositorys auch schreibgeschützt über HTTPS bereitstellen, d.h. Sie können die Inhaltsübertragung verschlüsseln oder Sie können sogar so weit gehen, dass Clients bestimmte signierte SSL-Zertifikate verwenden müssen. -Another nice thing is that HTTPS are such commonly used protocols that corporate firewalls are often set up to allow traffic through these ports. +Eine weitere schöne Sache ist, dass HTTPS ein so häufig verwendetes Protokoll ist, dass Unternehmens-Firewalls oft so eingerichtet sind, dass sie den Datenverkehr über diese Ports ermöglichen. -===== The Cons +===== Nachteile -Git over HTTPS can be a little more tricky to set up compared to SSH on some servers. -Other than that, there is very little advantage that other protocols have over Smart HTTP for serving Git content. +Git über HTTPS kann im Vergleich zu SSH auf einigen Servern etwas komplizierter einzurichten sein. +Abgesehen davon gibt es sehr wenig Vorteile, die andere Protokolle gegenüber Smart HTTP für die Bereitstellung von Git-Inhalten haben. -If you're using HTTP for authenticated pushing, providing your credentials is sometimes more complicated than using keys over SSH. -There are, however, several credential caching tools you can use, including Keychain access on macOS and Credential Manager on Windows, to make this pretty painless. -Read <> to see how to set up secure HTTP password caching on your system. +Wenn Sie HTTP für authentifiziertes Pushen verwenden, ist die Bereitstellung Ihrer Anmeldeinformationen manchmal komplizierter als die Verwendung von Schlüsseln über SSH. +Es gibt jedoch mehrere Tools zum Zwischenspeichern von Berechtigungen, die Sie verwenden könnten, darunter Keychain-Zugriff auf MacOS und Credential Manager unter Windows, um das ziemlich zu Vereinfachen. +Lesen Sie den Abschnitt <>, um zu erfahren, wie Sie ein sicheres HTTP-Passwort-Caching auf Ihrem System einrichten können. -==== The SSH Protocol +==== SSH Protocol (((protocols, SSH))) -A common transport protocol for Git when self-hosting is over SSH. -This is because SSH access to servers is already set up in most places -- and if it isn't, it's easy to do. -SSH is also an authenticated network protocol and, because it's ubiquitous, it's generally easy to set up and use. +Ein gängiges Transportprotokoll für Git, wenn das Self-Hosting über SSH läuft. +Der SSH-Zugriff auf den Server ist in den meisten Fällen bereits eingerichtet – und wenn nicht, ist es einfach zu bewerkstelligen. +SSH ist auch ein authentifiziertes Netzwerkprotokoll, und da es allgegenwärtig ist, ist es im Allgemeinen einfach einzurichten und zu verwenden. -To clone a Git repository over SSH, you can specify an `ssh://` URL like this: +Um ein Git-Repository über SSH zu klonen, können Sie eine entsprechende `ssh://` URL angeben: [source,console] ---- $ git clone ssh://[user@]server/project.git ---- -Or you can use the shorter scp-like syntax for the SSH protocol: +Oder Sie können die kürzere scp-ähnliche Syntax für das SSH-Protokoll verwenden: [source,console] ---- $ git clone [user@]server:project.git ---- -In both cases above, if you don't specify the optional username, Git assumes the user you're currently logged in as. +Wenn Sie in beiden Fällen oben keinen optionalen Benutzernamen angeben, benutzt Git den User, mit dem Sie aktuell angemeldet sind. -===== The Pros +===== Vorteile -The pros of using SSH are many. -First, SSH is relatively easy to set up -- SSH daemons are commonplace, many network admins have experience with them, and many OS distributions are set up with them or have tools to manage them. -Next, access over SSH is secure -- all data transfer is encrypted and authenticated. -Last, like the HTTPS, Git and Local protocols, SSH is efficient, making the data as compact as possible before transferring it. +Die Vorteile bei der Verwendung von SSH sind vielfältig. +Erstens ist SSH relativ einfach einzurichten – SSH-Daemons sind weit verbreitet, viele Netzwerkadministratoren haben Erfahrung mit ihnen und viele Betriebssystem-Distributionen werden mit ihnen eingerichtet oder haben Werkzeuge, um sie zu verwalten. +Als nächstes ist der Zugriff über SSH sicher – der gesamte Datentransfer wird verschlüsselt und authentifiziert. +Schließlich ist SSH, wie die Protokolle HTTPS, Git und Local effizient und komprimiert die Daten vor der Übertragung so stark wie möglich. -===== The Cons +===== Nachteile -The negative aspect of SSH is that it doesn't support anonymous access to your Git repository. -If you're using SSH, people _must_ have SSH access to your machine, even in a read-only capacity, which doesn't make SSH conducive to open source projects for which people might simply want to clone your repository to examine it. -If you're using it only within your corporate network, SSH may be the only protocol you need to deal with. -If you want to allow anonymous read-only access to your projects and also want to use SSH, you'll have to set up SSH for you to push over but something else for others to fetch from. +Die negative Seite von SSH ist, dass es keinen anonymen Zugriff auf Ihr Git-Repository unterstützt. +Wenn Sie SSH verwenden, _müssen_ Benutzer über einen SSH-Zugriff auf Ihren Computer verfügen, auch wenn sie nur über Lesezugriff verfügen. Das macht SSH in Open Source-Projekten ungeeignet, wenn, möglicherweise, die Benutzer Ihr Repository einfach nur klonen möchten, um es zu überprüfen. +Wenn Sie es nur in Ihrem Unternehmensnetzwerk verwenden, ist SSH möglicherweise das einzige Protokoll, mit dem Sie sich befassen müssen. +Wenn Sie anonymen schreibgeschützten Zugriff auf Ihre Projekte und die Verwendung von SSH zulassen möchten, müssen Sie SSH einrichten, damit Sie Push-Vorgänge ausführen können, aber noch zusätzliche Optionen damit andere Benutzer auch abrufen können. -==== The Git Protocol +==== Git Protokoll (((protocols, git))) -Finally, we have the Git protocol. -This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. -In order for a repository to be served over the Git protocol, you must create a `git-daemon-export-ok` file -- the daemon won't serve a repository without that file in it -- but, other than that, there is no security. -Either the Git repository is available for everyone to clone, or it isn't. -This means that there is generally no pushing over this protocol. -You can enable push access but, given the lack of authentication, anyone on the internet who finds your project's URL could push to that project. -Suffice it to say that this is rare. - -===== The Pros - -The Git protocol is often the fastest network transfer protocol available. -If you're serving a lot of traffic for a public project or serving a very large project that doesn't require user authentication for read access, it's likely that you'll want to set up a Git daemon to serve your project. -It uses the same data-transfer mechanism as the SSH protocol but without the encryption and authentication overhead. - -===== The Cons - -The downside of the Git protocol is the lack of authentication. -It's generally undesirable for the Git protocol to be the only access to your project. -Generally, you'll pair it with SSH or HTTPS access for the few developers who have push (write) access and have everyone else use `git://` for read-only access. -It's also probably the most difficult protocol to set up. -It must run its own daemon, which requires `xinetd` or `systemd` configuration or the like, which isn't always a walk in the park. -It also requires firewall access to port 9418, which isn't a standard port that corporate firewalls always allow. -Behind big corporate firewalls, this obscure port is commonly blocked. +Und schließlich haben wir das Git-Protokoll. +Es ist ein spezieller Daemon, der mit Git ausgeliefert wird, der auf einem dedizierten Port (9418) lauscht und der einen Dienst bereitstellt, ähnlich dem des SSH-Protokolls, aber ohne jegliche Authentifizierung +Damit ein Repository über das Git-Protokoll bedient werden kann, müssen Sie eine `git-daemon-export-ok` Datei erstellen – der Daemon wird ohne diese Datei kein Repository bedienen, weil es sonst keine Sicherheit gibt. +Entweder ist das Git-Repository für jeden zugänglich, um zu klonen, oder für Keinen. +Das bedeutet, dass es in der Regel keinen Push über dieses Protokoll gibt. +Sie können den Push-Zugriff aktivieren, aber angesichts der fehlenden Authentifizierung kann jeder im Internet, der die URL Ihres Projekts findet, zu diesem Projekt pushen. +Es reicht aus, zu sagen, dass das selten vorkommt. + +===== Vorteile + +Das Git-Protokoll ist oft als erstes Netzwerkübertragungsprotokoll verfügbar. +Wenn Sie viel Traffic für ein öffentliches Projekt bereitstellen oder ein sehr großes Projekt, das keine Benutzerauthentifizierung für den Lesezugriff benötigt, dann wollen Sie voraussichtlich einen Git-Daemon einrichten, der Ihr Projekt unterstützt. +Er verwendet den gleichen Datenübertragungsmechanismus wie das SSH-Protokoll, jedoch ohne den Aufwand für Verschlüsselung und Authentifizierung. + +===== Nachteile + +Der Nachteil des Git-Protokolls ist die fehlende Authentifizierung. +Es ist generell nachteilig, wenn das Git-Protokoll der einzige Zugang zu Ihrem Projekt ist. +Im Allgemeinen werden Sie es mit einem SSH- oder HTTPS-Zugriff für die wenigen Entwickler koppeln, die Push (Schreib-)Zugriff haben und alle anderen `git://` für den Lesezugriff verwenden lassen. +Es ist wahrscheinlich auch das am schwierigsten einzurichtende Protokoll. +Es muss seinen eigenen Daemon laufen lassen, der eine `xinetd` oder `systemd` Konfiguration oder dergleichen erfordert, was nicht immer ein Park-Spaziergang ist. +Es erfordert auch einen Firewall-Zugang auf Port 9418, der kein Standardport ist, den Unternehmens-Firewalls immer zulassen. +Hinter großen Firmen-Firewalls wird dieser „obskure“ Port häufig blockiert. diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 56a13aa2..506c4c35 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -1,116 +1,119 @@ [[_contributing_project]] -=== Contributing to a Project +=== An einem Projekt mitarbeiten (((contributing))) -The main difficulty with describing how to contribute to a project are the numerous variations on how to do that. -Because Git is very flexible, people can and do work together in many ways, and it's problematic to describe how you should contribute -- every project is a bit different. -Some of the variables involved are active contributor count, chosen workflow, your commit access, and possibly the external contribution method. - -The first variable is active contributor count -- how many users are actively contributing code to this project, and how often? -In many instances, you'll have two or three developers with a few commits a day, or possibly less for somewhat dormant projects. -For larger companies or projects, the number of developers could be in the thousands, with hundreds or thousands of commits coming in each day. -This is important because with more and more developers, you run into more issues with making sure your code applies cleanly or can be easily merged. -Changes you submit may be rendered obsolete or severely broken by work that is merged in while you were working or while your changes were waiting to be approved or applied. -How can you keep your code consistently up to date and your commits valid? - -The next variable is the workflow in use for the project. -Is it centralized, with each developer having equal write access to the main codeline? -Does the project have a maintainer or integration manager who checks all the patches? -Are all the patches peer-reviewed and approved? -Are you involved in that process? -Is a lieutenant system in place, and do you have to submit your work to them first? - -The next variable is your commit access. -The workflow required in order to contribute to a project is much different if you have write access to the project than if you don't. -If you don't have write access, how does the project prefer to accept contributed work? -Does it even have a policy? -How much work are you contributing at a time? -How often do you contribute? - -All these questions can affect how you contribute effectively to a project and what workflows are preferred or available to you. -We'll cover aspects of each of these in a series of use cases, moving from simple to more complex; you should be able to construct the specific workflows you need in practice from these examples. +Die größte Schwierigkeit bei der Beschreibung der Mitarbeit an einem Projekt besteht darin, dass es eine große Anzahl von Variationen gibt, wie dies geschehen kann. +Da Git sehr flexibel ist, bietet es den Menschen viele Möglichkeiten der Zusammenarbeit, und es ist problematisch zu beschreiben, wie Sie mitarbeiten sollten, da jedes Projekt ein bisschen anders ist. +Einige der variablen Größen dabei sind die Anzahl der aktiven Mitarbeiter, der gewählte Arbeitsablauf, Ihre Zugriffsrechte und möglicherweise eine externe Methode der Mitarbeit. + +Die erste variable Größe ist die Anzahl der aktiven Mitarbeiter - wie viele Nutzer steuern aktiv Code zu diesem Projekt bei und wie häufig? +In vielen Fällen gibt es zwei oder drei Entwickler mit ein paar Commits pro Tag, oder auch weniger bei irgendwie ruhenden Projekten. +Bei größeren Firmen oder Projekten kann die Anzahl der Entwickler in die Tausende reichen mit hunderten oder tausenden eingehenden Commits pro Tag. +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. +Änderungen, die Sie übermitteln, können sich als überflüssig oder dysfunktional erweisen durch Beiträge, die inzwischen eingefügt wurden, während Sie noch an ihren Änderungen arbeiteten oder darauf warteten, dass diese geprüft oder angewendet werden. +Wie können Sie Ihren Code permanent auf dem neusten Stand halten und dafür sorgen, dass Ihre Commits gültig sind? + +Die nächste Variable ist der für das Projekt verwendete Arbeitsablauf. +Ist es ein zentralisierter Arbeitsablauf, in dem jeder Entwickler die gleichen Schreibrechte auf die Hauptentwicklungslinie hat? +Gibt es bei dem Projekt einen Projektbetreiber oder Integrationsmanager, der alle Patches prüft? +Werden die Patches durch eine bestimmte Gruppe oder öffentlich, z. B. durch die Community, geprüft? +Sind Sie selbst an diesem Prozess beteiligt? +Gibt es ein Leutnant-System und müssen Sie Ihre Arbeit zunächst an einen solchen übermitteln? + +Eine weiteres Thema sind ihre Commit-Zugriffsrechte. +Der erforderliche Arbeitsablauf, um Änderungen zu einem Projekt beizusteuern, ist ein ganz anderer, wenn Sie über Schreibrechte verfügen, als wenn das nicht der Fall ist. +Und wenn Sie keine Schreibrechte haben, in welcher Form müssen Sie ihre Änderungen bei diesem Projekt vorzugsweise übermitteln? +Gibt es dafür überhaupt eine Richtlinie? +Wie umfangreich sind die Änderungen, die Sie jeweils beisteuern? +Und wie häufig tun Sie das? + +All diese Aspekte haben Einfluss darauf, wie Sie effektiv an einem Projekt mitarbeiten können und welche Arbeitsabläufe bevorzugt werden oder verfügbar für Sie sind. +Wir werden verschiedene Aspekte davon in einer Reihe von Fallbeispielen betrachten, 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]] -==== Commit Guidelines +==== Richtlinien für Commits -Before we start looking at the specific use cases, here's a quick note about commit messages. -Having a good guideline for creating commits and sticking to it makes working with Git and collaborating with others a lot easier. -The Git project provides a document that lays out a number of good tips for creating commits from which to submit patches -- you can read it in the Git source code in the `Documentation/SubmittingPatches` file. +Bevor wir damit beginnen, spezifische Anwendungsfälle zu betrachten, hier noch eine kurze Anmerkung zu Commit-Nachrichten. +Ein gute Richtlinie für das Erzeugen von Commits zu haben und sich daran zu halten, macht die Arbeit mit Git und die Zusammenarbeit mit anderen um vieles leichter. +Das Git-Projekt stellt ein Dokument bereit, welches eine Reihe von guten Tipps für das Erzeugen von Commits zum Übermitteln von Patches beinhaltet. Sie können die Tipps in der Datei `Documentation/SubmittingPatches` im Git-Quellcode nachlesen. (((git commands, diff, check))) -First, your submissions should not contain any whitespace errors. -Git provides an easy way to check for this -- before you commit, run `git diff --check`, which identifies possible whitespace errors and lists them for you. +Als Erstes wollen Sie keinerlei Leerzeichenfehler übermitteln. +Git bietet eine einfache Möglichkeit, dies zu überprüfen - bevor Sie einen Commit vornehmen, führen Sie die Anweisung `git diff --check` aus, welche mögliche Leerzeichenfehler erkennt und für Sie auflistet. -.Output of `git diff --check`. -image::images/git-diff-check.png[Output of `git diff --check`.] +.Ausgabe von `git diff --check`. +image::images/git-diff-check.png[Ausgabe von `git diff --check`.] -If you run that command before committing, you can tell if you're about to commit whitespace issues that may annoy other developers. +Wenn Sie diese Anweisung vor einem Commit ausführen, können Sie erkennen, ob Sie dabei sind, Leerzeichenfehler zu übermitteln, welche andere Entwickler verärgern könnten. -Next, try to make each commit a logically separate changeset. -If you can, try to make your changes digestible -- don't code for a whole weekend on five different issues and then submit them all as one massive commit on Monday. -Even if you don't commit during the weekend, use the staging area on Monday to split your work into at least one commit per issue, with a useful message per commit. -If some of the changes modify the same file, try to use `git add --patch` to partially stage files (covered in detail in <>). -The project snapshot at the tip of the branch is identical whether you do one commit or five, as long as all the changes are added at some point, so try to make things easier on your fellow developers when they have to review your changes. +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 <<_interactive_staging>>). +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. -This approach also makes it easier to pull out or revert one of the changesets if you need to later. -<> describes a number of useful Git tricks for rewriting history and interactively staging files -- use these tools to help craft a clean and understandable history before sending the work to someone else. +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. +<<_rewriting_history>> 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. -The last thing to keep in mind is the commit message. -Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier. -As a general rule, your messages should start with a single line that's no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation. -The Git project requires that the more detailed explanation include your motivation for the change and contrast its implementation with previous behavior -- this is a good guideline to follow. -Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug." -Here is a https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[template originally written by Tim Pope]: +Ein weitere Sache, die Sie nicht vergessen sollten, ist die Commit-Nachricht. +Wenn man sich angewöhnt, aussagekräftige und hochwertige Commit-Nachrichten zu schreiben, ist die Benutzung von Git viel einfacher und es erleichtert die Zusammenarbeit. +In der Regel sollte Ihre Commit-Nachricht mit einer einzelnen Zeile anfangen, die nicht länger als 50 Zeichen sein sollte und die Änderungen kurz und bündig beschreibt, gefolgt von einer leeren Zeile, welcher eine ausführlichere Beschreibung der Änderungen folgt. +Das Git-Projekt fordert, dass die detailliertere Erklärung Ihre Motivation für die Änderungen beinhaltet und deren Implementierung dem vorhergehenden Verhalten gegenüberstellt. Das ist eine gute Richtlinie, an die man sich halten sollte. +Es empfiehlt sich außerdem, die Gegenwartsform des Imperativ 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 ein https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[Muster, welches ursprünglich von Tim Pope stammt]: [source,text] ---- -Capitalized, short (50 chars or less) summary +Kurze (50 Zeichen oder weniger) Zusammenfassung der Änderungen -More detailed explanatory text, if necessary. Wrap it to about 72 -characters or so. In some contexts, the first line is treated as the -subject of an email and the rest of the text as the body. The blank -line separating the summary from the body is critical (unless you omit -the body entirely); tools like rebase can get confused if you run the -two together. +Detailliert erklärender Text, wenn nötig. Beschränken Sie diesen auf +ca. 72 Zeichen. In Abhängigkeit vom Kontext wird die erste Zeile +manchmal wie die Betreff-Zeile einer E-Mail behandelt und der übrige +Text wie der Textkörper der Nachricht. Die leere Zeile, welche die +Zusammenfassung vom Text trennt, ist kritisch (außer Sie lassen den Text +komplett weg); Werkzeuge wie Rebase können durcheinander kommen, wenn +Sie beide gleichzeitig verwenden. -Write your commit message in the imperative: "Fix bug" and not "Fixed bug" -or "Fixes bug." This convention matches up with commit messages generated -by commands like git merge and git revert. +Weitere Absätze folgen jeweils nach leeren Zeilen. -Further paragraphs come after blank lines. +. Aufzählungspunkte kann man auch verwenden -- Bullet points are okay, too +* Typischer Weise nutzt man Bindestriche oder Sternchen + als Aufzählungszeichen, denen ein einzelnes Leerzeichen + vorangestellt wird, die einzelnen Punkte werden durch + leere Zeilen getrennt, die Konventionen variieren hier -- Typically a hyphen or asterisk is used for the bullet, followed by a - single space, with blank lines in between, but conventions vary here - -- Use a hanging indent + einen hängenden Einzug benutzen ---- -If all your commit messages follow this model, things will be much easier for you and the developers with whom you collaborate. -The Git project has well-formatted commit messages -- try running `git log --no-merges` there to see what a nicely-formatted project-commit history looks like. +Wenn alle Ihre Commit-Nachrichten so aussehen, werden die Dinge für Sie und die Entwickler, mit denen Sie zusammenarbeiten, viel einfacher sein. +Das Git-Projekt selbst hat wohl-formatierte Commit-Nachrichten – führen Sie mal die Anweisung `git log --no-merges` aus, um zu sehen, wie ein angenehm formatierter Commit-Verlauf eines Projektes aussieht. + +In den folgenden Beispielen und fast überall in diesem Buch finden Sie der Kürze halber keine angenehm formatierten Meldungen wie diese. Stattdessen wird die Anweisung `git commit` zusammen mit der Option `-m` verwendet. +Also folgen Sie meinen Worten und nicht meinem Beispiel. + [NOTE] -.Do as we say, not as we do. +.Mach es wie wir sagen, nicht wie wir es tun. ==== -For the sake of brevity, many of the examples in this book don't have nicely-formatted commit messages like this; instead, we simply use the `-m` option to `git commit`. +Der Kürze halber haben viele der Beispiele in diesem Buch keine gut formatierten Commit-Nachrichten wie diese. Stattdessen verwenden wir einfach die Option `-m`, um `-m` auszuführen. -In short, do as we say, not as we do. +Kurz, mach es wie wir sagen, nicht wie wir es tun. ==== [[_private_team]] -==== Private Small Team +==== Privates kleines Team (((contributing, private small team))) -The simplest setup you're likely to encounter is a private project with one or two other developers. -``Private,'' in this context, means closed-source -- not accessible to the outside world. -You and the other developers all have push access to the repository. +Das einfachste Szenario, dem Sie sehr wahrscheinlich begegnen werden, ist ein vertrauliches Projekt mit einem oder zwei Entwicklern. +„Private“ in diesem Zusammenhang bedeutet „closed source“ - nicht öffentlich zugänglich für die Außenwelt. +Sie und die anderen Entwickler haben alle Schreibzugriff auf das Repository. -In this environment, you can follow a workflow similar to what you might do when using Subversion or another centralized system. -You still get the advantages of things like offline committing and vastly simpler branching and merging, but the workflow can be very similar; the main difference is that merges happen client-side rather than on the server at commit time. -Let's see what it might look like when two developers start to work together with a shared repository. -The first developer, John, clones the repository, makes a change, and commits locally. -(The protocol messages have been replaced with `...` in these examples to shorten them somewhat.) +Sie können sich in diesem Umfeld an einen Arbeitsablauf halten, den Sie genauso auch bei Subversion oder einem anderen zentralisierten System verwenden könnten. +Sie genießen dann immer noch die Vorteile von Dingen, wie Commits offline durchführen zu können und erheblich einfacher Branches anzulegen und zusammenzuführen, der Arbeitsablauf kann sehr ähnlich sein. Der Hauptunterschied ist, dass das Zusammenführen eher auf der Client-Seite stattfindet als auf dem Server beim Durchführen eines Commits. +Lassen Sie uns betrachten, wie es aussehen könnte, wenn zwei Entwickler damit beginnen, an einem gemeinsamen Repository zu arbeiten. +Der erste Entwickler, John, klont das Repository, nimmt eine Änderung vor und führt lokal einen Commit durch. +(Die Protokoll-Nachrichten wurden in diesen Beispielen durch `...` ersetzt, um das Ganze etwas zu kürzen.) [source,console] ---- @@ -125,7 +128,7 @@ $ git commit -am 'remove invalid default value' 1 files changed, 1 insertions(+), 1 deletions(-) ---- -The second developer, Jessica, does the same thing -- clones the repository and commits a change: +Die zweite Entwicklerin, Jessica, tut dasselbe. Sie klont das Repository, ändert etwas und führt einen Commit durch. [source,console] ---- @@ -140,7 +143,7 @@ $ git commit -am 'add reset task' 1 files changed, 1 insertions(+), 0 deletions(-) ---- -Now, Jessica pushes her work to the server, which works just fine: +Nun lädt Jessica ihre Arbeit auf den Server hoch: [source,console] ---- @@ -151,12 +154,12 @@ To jessica@githost:simplegit.git 1edee6b..fbff5bc master -> master ---- -The last line of the output above shows a useful return message from the push operation. -The basic format is `.. fromref -> toref`, where `oldref` means the old reference, `newref` means the new reference, `fromref` is the name of the local reference being pushed, and `toref` is the name of the remote reference being updated. -You'll see similar output like this below in the discussions, so having a basic idea of the meaning will help in understanding the various states of the repositories. -More details are available in the documentation for https://git-scm.com/docs/git-push[git-push]. +Die letzte Zeile der obigen Ausgabe zeigt eine nützliche Rückmeldung aus aus der Push-Operation. +Das Ausgangsformat ist `.. fromref -> toref`, wobei `oldref` die alte Referenz bedeutet, `newref` die neue Referenz bedeutet, `fromref` der Name der zu verschiebenden lokalen Referenz ist und `toref` der Name der zu aktualisierenden Fernreferenz ist. +Sie werden ähnliche Ausgaben wie diese unten in den Diskussionsrunden sehen, so dass eine grundlegende Vorstellung der Bedeutung hilft, die verschiedenen Zustände der Repositorien zu verstehen. +Weitere Details finden Sie in der Dokumentation zu https://git-scm.com/docs/git-push[git-push]. -Continuing with this example, shortly afterwards, John makes some changes, commits them to his local repository, and tries to push them to the same server: +In Fortsetzung dieses Beispiels nimmt John kurz darauf einige Änderungen vor, überträgt sie in sein lokales Repository und versucht, sie auf den gleichen Server zu verschieben: [source,console] ---- @@ -167,12 +170,12 @@ To john@githost:simplegit.git error: failed to push some refs to 'john@githost:simplegit.git' ---- -In this case, John's push fails because of Jessica's earlier push of _her_ changes. -This is especially important to understand if you're used to Subversion, because you'll notice that the two developers didn't edit the same file. -Although Subversion automatically does such a merge on the server if different files are edited, with Git, you must _first_ merge the commits locally. -In other words, John must first fetch Jessica's upstream changes and merge them into his local repository before he will be allowed to push. +John ist es nicht gestattet, seine Änderungen hochzuladen, weil Jessica vorher _ihre_ hochgeladen hat. +Dies zu verstehen, ist besonders wichtig, wenn Sie dem Umgang mit Subversion gewöhnt sind, weil Sie bemerkt haben werden, dass die beiden Entwickler nicht die gleiche Datei bearbeitet haben. +Obwohl Subversion automatisch das Zusammenführen auf dem Server durchführt, wenn zwei verschiedene Dateien bearbeitet werden, müssen Sie die Commits bei Git _zuerst_ lokal zusammenführen. +Anders ausgedrückt: John muss erst Jessicas Änderungen abholen und lokal mit seinen zusammenführen, bevor ihm das Hochladen gestattet wird. -As a first step, John fetches Jessica's work (this only _fetches_ Jessica's upstream work, it does not yet merge it into John's work): +Als ersten Schritt ruft John Jessicas Arbeit ab (dies ruft nur Jessicas Vorgängerarbeit ab, er verbindet sie noch nicht mit Johns Arbeit): [source,console] ---- @@ -182,12 +185,12 @@ From john@githost:simplegit + 049d078...fbff5bc master -> origin/master ---- -At this point, John's local repository looks something like this: +Zu diesem Zeitpunkt sieht Johns lokales Repository ungefähr so aus: -.John's divergent history. +.Johns abzweigender Verlauf. image::images/small-team-1.png[John's divergent history.] -Now John can merge Jessica's work that he fetched into his own local work: +Jetzt kann John Jessicas Arbeit, die er abgerufen hat, mit seiner eigenen lokalen Arbeit zusammenführen: [source,console] ---- @@ -197,12 +200,12 @@ Merge made by the 'recursive' strategy. 1 files changed, 1 insertions(+), 0 deletions(-) ---- -As long as that local merge goes smoothly, John's updated history will now look like this: +Das Zusammenführen läuft problemlos - Johns Commit-Verlauf sieht jetzt so aus: -.John's repository after merging `origin/master`. +.Johns Repository nach dem Zusammenführen mit `origin/master`. image::images/small-team-2.png[John's repository after merging `origin/master`.] -At this point, John might want to test this new code to make sure none of Jessica's work affects any of his and, as long as everything seems fine, he can finally push the new merged work up to the server: +Jetzt kann John seinen Code überprüfen, um sicherzustellen, dass dieser immer noch ordnungsgemäß funktioniert, und dann kann er seine neue, zusammengeführte Arbeit auf den Server hochladen: [source,console] ---- @@ -212,18 +215,18 @@ To john@githost:simplegit.git fbff5bc..72bbc59 master -> master ---- -In the end, John's commit history will look like this: +Schließlich sieht Johns Commit-Verlauf so aus: -.John's history after pushing to the `origin` server. +.Johns Verlauf nach dem Hochladen auf den `origin`-Server. image::images/small-team-3.png[John's history after pushing to the `origin` server.] -In the meantime, Jessica has created a new topic branch called `issue54`, and made three commits to that branch. -She hasn't fetched John's changes yet, so her commit history looks like this: +Jesicca hat in der Zwischenzeit an einem neuen Branch gearbeitet. Sie hat einen Branch namens `issue54` erzeugt und auf diesem Branch drei Commits durchgeführt. +Noch hat sie Johns Änderungen nicht vom Server abgeholt, sodass ihr Commit-Verlauf jetzt so aussieht: -.Jessica's topic branch. +.Jessicas Branches. image::images/small-team-4.png[Jessica's topic branch.] -Suddenly, Jessica learns that John has pushed some new work to the server and she wants to take a look at it, so she can fetch all new content from the server that she does not yet have with: +Plötzlich erfährt Jessica, dass John neue Arbeit auf den Server geschoben hat und sie will sich das ansehen. Deshalb muss sie alle neuen Inhalte vom Server abrufen über die sie noch nicht verfügt: [source,console] ---- @@ -234,14 +237,14 @@ From jessica@githost:simplegit fbff5bc..72bbc59 master -> origin/master ---- -That pulls down the work John has pushed up in the meantime. -Jessica's history now looks like this: +Das lädt alle Änderungen herunter, die John in der Zwischenzeit hochgeladen hat. +Jessicas Verlauf sieht nun so aus: -.Jessica's history after fetching John's changes. +.Jessicas Verlauf nach dem Abholen von Johns Änderungen. image::images/small-team-5.png[Jessica's history after fetching John's changes.] -Jessica thinks her topic branch is ready, but she wants to know what part of John's fetched work she has to merge into her work so that she can push. -She runs `git log` to find out: +Jessica denkt, dass ihr Branch fertig ist, aber sie möchte wissen, welchen Teil von Johns abgerufenen Arbeiten sie in ihre Arbeit einbinden muss, damit sie ihrerseits hochladen kann. +Sie führt die Anweisung `git log` aus, um es herauszufinden: [source,console] ---- @@ -253,15 +256,15 @@ Date: Fri May 29 16:01:27 2009 -0700 remove invalid default value ---- -The `issue54..origin/master` syntax is a log filter that asks Git to display only those commits that are on the latter branch (in this case `origin/master`) that are not on the first branch (in this case `issue54`). -We'll go over this syntax in detail in <>. +Bei der Syntax `issue54..origin/master` handelt es sich um einen log-Filter, der Git anweist, nur die Commits aufzulisten, welche auf dem letzteren Branch durchgeführt wurden (in diesem Fall `origin/master`) und die sich nicht auf dem ersten Branch befinden (in diesem Fall `issue54`). +Wir werden diese Syntax detailliert in <> erläutern. -From the above output, we can see that there is a single commit that John has made that Jessica has not merged into her local work. -If she merges `origin/master`, that is the single commit that will modify her local work. +Fürs Erste können wir an der Ausgabe erkennen, dass es einen einzelnen Commit von John gibt, den Jessica noch nicht bei sich eingefügt hat. +Dieser einzelne Commit modifiziert ihre lokalen Änderungen, wenn sie ihren Branch mit `origin/master` zusammenführt. -Now, Jessica can merge her topic work into her master branch, merge John's work (`origin/master`) into her `master` branch, and then push back to the server again. +Jetzt kann Jessica ihren "issue54"-Branch mit ihrem `master`-Branch zusammenführen, danach Johns Arbeit (`origin/master`) mit ihrem `master`-Branch zusammenführen und dann das Ganze auf den Server hochladen. -First (having committed all of the work on her `issue54` topic branch), Jessica switches back to her master branch in preparation for integrating all this work: +Zuerst wechselt sie zu ihrem `master`-Branch, um alle diese Änderungen zu integrieren: [source,console] ---- @@ -270,9 +273,9 @@ Switched to branch 'master' Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. ---- -Jessica can merge either `origin/master` or `issue54` first -- they're both upstream, so the order doesn't matter. -The end snapshot should be identical no matter which order she chooses; only the history will be different. -She chooses to merge the `issue54` branch first: +Sie kann entweder `origin/master` oder `issue54` zuerst integrieren, da sie beide "stromaufwärts" angeordnet sind, spielt die Reihefolge keine Rolle. +Der Snapshot am Ende sollte identisch sein, egal, welche Reihenfolge sie wählt, nur der Verlauf wird ein wenig anders sein. +Sie entscheidet sich dafür, `issue54` zuerst einfließen zu lassen. [source,console] ---- @@ -284,8 +287,8 @@ Fast forward 2 files changed, 6 insertions(+), 1 deletions(-) ---- -No problems occur; as you can see it was a simple fast-forward merge. -Jessica now completes the local merging process by merging John's earlier fetched work that is sitting in the `origin/master` branch: +Es treten keine Probleme auf; wie Sie sehen können, war es ein einfacher "Fast-Forward". +Jessica vervollständigt nun den lokalen Merge-Prozess, indem sie Johns früher geholte Arbeit zusammenführt, die im Branch `origin/master` liegt: [source,console] ---- @@ -296,12 +299,12 @@ Merge made by the 'recursive' strategy. 1 files changed, 1 insertions(+), 1 deletions(-) ---- -Everything merges cleanly, and Jessica's history now looks like this: +Alles lässt sich sauber zusammenführen und Jessicas Verlauf sieht jetzt so aus: -.Jessica's history after merging John's changes. +.Jessicas Verlauf nach dem Zusammenführen mit Johns Änderungen. image::images/small-team-6.png[Jessica's history after merging John's changes.] -Now `origin/master` is reachable from Jessica's `master` branch, so she should be able to successfully push (assuming John hasn't pushed even more changes in the meantime): +Jetzt ist `origin/master` von Jessicas `master`-Branch aus erreichbar, sodass sie in der Lage sein sollte, erfolgreich hochladen zu können (vorausgesetzt, John hat nicht inzwischen schon wieder etwas hochgeladen): [source,console] ---- @@ -311,32 +314,32 @@ To jessica@githost:simplegit.git 72bbc59..8059c15 master -> master ---- -Each developer has committed a few times and merged each other's work successfully. +Jeder Entwickler hat einige Commits durchgeführt und jeweils die Arbeiten des anderen mit den eigenen zusammengeführt. -.Jessica's history after pushing all changes back to the server. +.Jessicas Verlauf nach dem Hochladen aller Änderungen auf den Server. image::images/small-team-7.png[Jessica's history after pushing all changes back to the server.] -That is one of the simplest workflows. -You work for a while (generally in a topic branch), and merge that work into your `master` branch when it's ready to be integrated. -When you want to share that work, you fetch and merge your `master` from `origin/master` if it has changed, and finally push to the `master` branch on the server. -The general sequence is something like this: +Das ist einer der einfachsten Arbeitsabläufe. +Sie arbeiten eine Weile, gewöhnlich an einem Themenbranch, und führen diesen mit ihrem master-Branch zusammen, wenn dieser soweit fertig ist, dass er integriert werden kann. +Wenn Sie diese Arbeit mit anderen teilen wollen, führen Sie die Änderungen mit ihrem eigenen `master`-Branch zusammen, holen eventuelle Änderungen vom Branch `origin/master` ab und führen diese mit ihren `master`-Branch zusammen, und schließlich laden sie alles auf den `master`-Branch auf den Server hoch. +Der generelle Ablauf sieht ungefähr so aus: -.General sequence of events for a simple multiple-developer Git workflow. +.Genereller Ablauf von Ereignissen für einen einfachen Arbeitsablauf mit mehreren Entwicklern. image::images/small-team-flow.png[General sequence of events for a simple multiple-developer Git workflow.] -==== Private Managed Team +==== Geführte private Teams (((contributing, private managed team))) -In this next scenario, you'll look at contributor roles in a larger private group. -You'll learn how to work in an environment where small groups collaborate on features, after which those team-based contributions are integrated by another party. +In diesem Szenario werden Sie die Funktionen von Mitarbeitern in einem größeren, nicht öffentlich arbeitenden Team betrachten. +Sie werden erfahren, wie Sie in einem Umfeld arbeiten können, wo in kleinen Gruppen an der Entwicklung einzelner Features gearbeitet wird und dann diese team-basierten Beiträge durch einen anderen Beteiligten integriert werden. -Let's say that John and Jessica are working together on one feature (call this ``featureA''), while Jessica and a third developer, Josie, are working on a second (say, ``featureB''). -In this case, the company is using a type of integration-manager workflow where the work of the individual groups is integrated only by certain engineers, and the `master` branch of the main repo can be updated only by those engineers. -In this scenario, all work is done in team-based branches and pulled together by the integrators later. +Sagen wir, John und Jessica arbeiten gerade zusammen an einem Feature, während Jessica und Josie gerade an einem zweiten arbeiten. +Das Unternehmen benutzt in diesem Fall einen Typ des Arbeitsablaufs mit Integrationsmanager, bei dem die Arbeit der individuellen Gruppen nur durch bestimmte Mitarbeiter integriert wird und der `master`-Branch des Haupt-Repositorys auch nur durch eben diese Mitarbeiter aktualisiert werden kann. +Die ganze Arbeit wird in diesem Szenario auf team-basierten Branches ausgeführt und später von den Integrationsmanagern zusammengeführt. -Let's follow Jessica's workflow as she works on her two features, collaborating in parallel with two different developers in this environment. -Assuming she already has her repository cloned, she decides to work on `featureA` first. -She creates a new branch for the feature and does some work on it there: +Lassen Sie uns Jessicas Arbeitsablauf betrachten, wie sie in diesem Umfeld parallel mit zwei verschiedenen Entwicklern an ihren beiden Features arbeitet. +Vorausgesetzt, sie hat ihr Repository bereits geklont, entscheidet sie sich, zuerst an `featureA` zu arbeiten. +Sie erzeugt einen neuen Branch für das Feature und arbeitet etwas daran: [source,console] ---- @@ -349,8 +352,8 @@ $ git commit -am 'add limit to log function' 1 files changed, 1 insertions(+), 1 deletions(-) ---- -At this point, she needs to share her work with John, so she pushes her `featureA` branch commits up to the server. -Jessica doesn't have push access to the `master` branch -- only the integrators do -- so she has to push to another branch in order to collaborate with John: +An diesem Punkt muss sie den Stand ihrer Arbeiten John mitteilen, also lädt sie ihre Commits von `featureA`-Branch auf den Server hoch. +Jessica hat keine Schreibrechte auf dem `master`-Branch - den haben nur die Integrationsmanager - also muss sie auf einen anderen Branch hochladen, um mit John zusammenarbeiten zu können. [source,console] ---- @@ -360,9 +363,9 @@ To jessica@githost:simplegit.git * [new branch] featureA -> featureA ---- -Jessica emails John to tell him that she's pushed some work into a branch named `featureA` and he can look at it now. -While she waits for feedback from John, Jessica decides to start working on `featureB` with Josie. -To begin, she starts a new feature branch, basing it off the server's `master` branch: +Jessica sendet John eine E-Mail, um ihm mitzuteilen, dass einige Änderungen auf einen neuen Branch namens `featureA` hochgeladen hat und er nun einen Blick darauf werfen kann. +Während sie auf ein Feedback von John wartet, entscheidet sich Jessica, mit der Arbeit an `featureB` zu beginnen - diesmal gemeinsam mit Josie. +Am Anfang legt sie einen neuen Feature-Branch an, basierend auf dem `master`-Branch, welcher sich auf dem Server befindet (`origin/master`): [source,console] ---- @@ -372,7 +375,7 @@ $ git checkout -b featureB origin/master Switched to a new branch 'featureB' ---- -Now, Jessica makes a couple of commits on the `featureB` branch: +Jetzt führt Jessica eine Reihe von Commits auf dem `featureB`-Branch durch: [source,console] ---- @@ -386,14 +389,14 @@ $ git commit -am 'add ls-files' 1 files changed, 5 insertions(+), 0 deletions(-) ---- -Jessica's repository now looks like this: +Jessicas Repository sieht jetzt so aus: -.Jessica's initial commit history. +.Jessicas ursprünglicher Commit-Verlauf. image::images/managed-team-1.png[Jessica's initial commit history.] -She's ready to push her work, but gets an email from Josie that a branch with some initial ``featureB'' work on it was already pushed to the server as the `featureBee` branch. -Jessica needs to merge those changes with her own before she can push her work to the server. -Jessica first fetches Josie's changes with `git fetch`: +Jessica könnte ihre Arbeit jetzt hochladen, aber sie bekommt eine E-Mail von Josie, in der diese mitteilt, dass bereits ein Branch namens `featureBee` hochgeladen wurde, welcher einige erste Änderungen beinhaltet. +Jessica muss also erst diese Änderungen mit ihren eigenen Änderungen zusammenführen, bevor sie selbst etwas hochladen kann. +Sie kann Josies Änderungen mit `git fetch` herunterladen: [source,console] ---- @@ -403,7 +406,7 @@ From jessica@githost:simplegit * [new branch] featureBee -> origin/featureBee ---- -Assuming Jessica is still on her checked-out `featureB` branch, she can now merge Josie's work into that branch with `git merge`: +Angenommen, Jessica befindet sich noch in ihrem ausgecheckten `featureB` Branch und kann nun Josies Arbeit mit `git merge` in diesen Zweig einbinden: [source,console] ---- @@ -414,8 +417,8 @@ Merge made by the 'recursive' strategy. 1 files changed, 4 insertions(+), 0 deletions(-) ---- -At this point, Jessica wants to push all of this merged ``featureB'' work back to the server, but she doesn't want to simply push her own `featureB` branch. -Rather, since Josie has already started an upstream `featureBee` branch, Jessica wants to push to _that_ branch, which she does with: +Jetzt möchte Jessica alle zusammengeführten featureB-Arbeiten zurück auf den Server schieben, aber sie will nicht sie einfach ihren eigenen featureB-Zweig hochschieben. +Da Josie bereits einen Upstream-FeatureBee-Zweig gestartet hat, will Jessica zu diesem Branch hochladen, indem sie folgenden Befehl ausführt: [source,console] ---- @@ -425,12 +428,12 @@ To jessica@githost:simplegit.git fba9af8..cd685d1 featureB -> featureBee ---- -This is called a _refspec_. -See <> for a more detailed discussion of Git refspecs and different things you can do with them. -Also notice the `-u` flag; this is short for `--set-upstream`, which configures the branches for easier pushing and pulling later. +Das bezeichnet man als _refspec_. +Siehe <> für eine ausführlichere Beschreibung der Git „refspecs“ und den unterschiedlichen Möglichkeiten, die Sie damit haben. +Beachten Sie auch das `-u` Flag, eine Abkürzung für `--set-upstream`, das die Branches für später leichtere Pushs und Pulls konfiguriert. -Suddenly, Jessica gets email from John, who tells her he's pushed some changes to the `featureA` branch on which they are collaborating, and he asks Jessica to take a look at them. -Again, Jessica runs a simple `git fetch` to fetch _all_ new content from the server, including (of course) John's latest work: +Als Nächstes sendet John eine E-Mail an Jessica, um sie zu informieren, dass er einige Änderungen auf den `featureA`-Branch hochgeladen hat, und sie bittet, diese zu überprüfen. +Wieder Sie führt die Anweisung `git fetch` aus, um diese Änderungen herunter zu laden: [source,console] ---- @@ -440,7 +443,7 @@ From jessica@githost:simplegit 3300904..aad881d featureA -> origin/featureA ---- -Jessica can display the log of John's new work by comparing the content of the newly-fetched `featureA` branch with her local copy of the same branch: +Jessica kann sich das Protokoll von Johns neuer Arbeit anzeigen lassen indem sie den Inhalt des neu abgerufenen Branch `featureA` mit ihrer lokalen Kopie des gleichen Zweiges vergleicht: [source,console] ---- @@ -452,7 +455,7 @@ Date: Fri May 29 19:57:33 2009 -0700 changed log output to 30 from 25 ---- -If Jessica likes what she sees, she can merge John's new work into her local `featureA` branch with: +Wenn ihr Johns neue Arbeit gefällt, kann sie sie mit ihrem lokalen Branch `featureA` verschmelzen: [source,console] ---- @@ -465,7 +468,7 @@ Fast forward 1 files changed, 9 insertions(+), 1 deletions(-) ---- -Finally, Jessica might want to make a couple minor changes to all that merged content, so she is free to make those changes, commit them to her local `featureA` branch, and push the end result back to the server. +Schließlich möchte Jessica möglicherweise ein paar geringfügige Änderungen an dem gesamten zusammengeführten Inhalt vornehmen. Sie kann diese Änderungen vornehmen, sie in ihren lokalen Zweig 'featureA' übertragen und das Endergebnis zurück auf den Server übertragen: [source,console] ---- @@ -478,36 +481,36 @@ To jessica@githost:simplegit.git 3300904..774b3ed featureA -> featureA ---- -Jessica's commit history now looks something like this: +Jessicas Commit-Verlauf sieht jetzt ungefähr so aus: -.Jessica's history after committing on a feature branch. +.Jessicas Verlauf nach dem Commit auf den Feature-Branch. image::images/managed-team-2.png[Jessica's history after committing on a feature branch.] -At some point, Jessica, Josie, and John inform the integrators that the `featureA` and `featureBee` branches on the server are ready for integration into the mainline. -After the integrators merge these branches into the mainline, a fetch will bring down the new merge commit, making the history look like this: +Irgendwann informieren Jessica, Josie und John die Integratoren, dass die Zweige `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, wird beim Abrufen das neue Merge-Commit beendet, sodass der Verlauf wie folgt aussieht: -.Jessica's history after merging both her topic branches. +.Jessicas Verlauf nach dem Zusammenführen mit ihren beiden Themenbranches. image::images/managed-team-3.png[Jessica's history after merging both her topic branches.] -Many groups switch to Git because of this ability to have multiple teams working in parallel, merging the different lines of work late in the process. -The ability of smaller subgroups of a team to collaborate via remote branches without necessarily having to involve or impede the entire team is a huge benefit of Git. -The sequence for the workflow you saw here is something like this: +Viele Teams wechseln zu Git, weil es damit möglich ist, dass mehrere Teams parallel arbeiten können und die verschiedenen Entwicklungslinien erst später im Prozess zusammengeführt werden. +Ein riesiger 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 Reihenfolge bei dem Arbeitsablauf, den Sie gesehen haben, ist ungefähr folgende: -.Basic sequence of this managed-team workflow. +.Grundlegende Reihenfolge des Arbeitsablaufs bei einem geführten Team. image::images/managed-team-flow.png[Basic sequence of this managed-team workflow.] [[_public_project]] -==== Forked Public Project +==== Verteiltes öffentliches Projekt (((contributing, public small project))) -Contributing to public projects is a bit different. -Because you don't have the permissions to directly update branches on the project, you have to get the work to the maintainers some other way. -This first example describes contributing via forking on Git hosts that support easy forking. -Many hosting sites support this (including GitHub, BitBucket, repo.or.cz, and others), and many project maintainers expect this style of contribution. -The next section deals with projects that prefer to accept contributed patches via email. +An einem öffentlichen Projekt mitzuarbeiten, ist ein wenig anders. +Da Sie keine Berechtigungen haben, die Branches des Projektes direkt zu aktualisieren, müssen Sie die Änderungen auf andere Art und Weise zu den Projektbetreibern bekommen. +Dieses erste Beispiel beschreibt die Mitarbeit mittels "Forking" auf Git-Hosting-Servern, welche einfaches "Forking" unterstützen. +Viele Hosting-Websites unterstützen dies (einschließlich GitHub, BitBucket, Google Code repo.or.cz und andere), und viele Projektbetreiber erwarten diese Art der Mitarbeit. +Der nächste Abschnitt handelt von Projekten, welche die Abgabe von Patches via E-Mail bevorzugt akzeptieren. -First, you'll probably want to clone the main repository, create a topic branch for the patch or patch series you're planning to contribute, and do your work there. -The sequence looks basically like this: +Zunächst werden Sie vermutlich das Hauptrepository klonen wollen, einen Themenbranch anlegen für den Patch oder die Serie von Patches, die Sie beisteuern möchten, und dann darin arbeiten. +Die Reihenfolge sieht dann in etwa so aus: [source,console] ---- @@ -522,23 +525,23 @@ $ git commit [NOTE] ==== -You may want to use `rebase -i` to squash your work down to a single commit, or rearrange the work in the commits to make the patch easier for the maintainer to review -- see <> for more information about interactive rebasing. +Sie können `rebase -i` verwenden, um Ihre Arbeit auf einen einzelnen Commit zu reduzieren oder die Arbeit in den Commits neu anzuordnen damit der Patch für den Maintainer einfacher zu überprüfen ist – siehe <> für weitere Informationen über interaktives Rebasing. ==== -When your branch work is finished and you're ready to contribute it back to the maintainers, go to the original project page and click the ``Fork'' button, creating your own writable fork of the project. -You then need to add this repository URL as a new remote of your local repository; in this example, let's call it `myfork`: +Wenn Sie mit der Arbeit an ihrem Branch fertig sind und Sie ihren Beitrag den Projektbetreibern zur Verfügung stellen wollen, gehen Sie auf die Projektseite und klicken auf den „Fork“ Button, um Ihren eigenen Fork des Projektes anzulegen, in den Sie dann schreiben können. +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 ---- -You then need to push your new work to this repository. -It's easiest to push the topic branch you're working on to your forked repository, rather than merging that work into your master branch and pushing that. -The reason is that if your work isn't accepted or is cherry-picked, you don't have to rewind your master branch (the Git `cherry-pick` operation is covered in more detail in <>). -If the maintainers `merge`, `rebase`, or `cherry-pick` your work, you'll eventually get it back via pulling from their repository anyhow. +Dann müssen Sie Ihre Änderungen dorthin hochladen. +Es ist am einfachsten, den Themenbranch, an dem Sie arbeiten, in Ihr Forked-Repository hochzuladen, anstatt diese Arbeit in Ihrem Master-Zweig zusammenzuführen und dorthin zu verschieben. +Der Grund dafür ist, dass Sie Ihren `master` Branch nicht zurücksetzen müssen, wenn Ihre Arbeit nicht angenommen oder ausgewählt wurde (die Git-Operation `cherry-pick` zum Auswählen einzelner Commits wird in <> ausführlicher behandelt). +Wenn die Projektbetreiber Ihre Änderungen übernehmen, ob mit `merge`, `rebase` oder `cherry-pick`, werden Sie diese schließlich sowieso zurückbekommen mittels `git pull` von deren Repository. -In any event, you can push your work with: +Auf jeden Fall können Sie Ihre Arbeit voranbringen mit: [source,console] ---- @@ -546,11 +549,11 @@ $ git push -u myfork featureA ---- (((git commands, request-pull))) -Once your work has been pushed to your fork of the repository, you need to notify the maintainers of the original project that you have work you'd like them to merge. -This is often called a _pull request_, and you typically generate such a request either via the website -- GitHub has its own ``Pull Request'' mechanism that we'll go over in <> -- or you can run the `git request-pull` command and email the subsequent output to the project maintainer manually. +Sobald Ihre Arbeit auf Ihren Fork des Repository verschoben wurde, müssen Sie die Maintainer des ursprünglichen Projekts darüber informieren, dass Sie Arbeit haben, die Sie zusammenführen möchten. +Das wird oft als _pull request_ bezeichnet, und Sie generieren eine solche Anforderung typischerweise entweder über die Website – GitHub hat einen eigenen „Pull-Request“ Mechanismus, den wir im < durchgehen werden – oder Sie können den Befehl `git request-pull` ausführen und die nachfolgende Ausgabe manuell per E-Mail an den Projektbetreuer senden. -The `git request-pull` command takes the base branch into which you want your topic branch pulled and the Git repository URL you want them to pull from, and produces a summary of all the changes you're asking to be pulled. -For instance, if Jessica wants to send John a pull request, and she's done two commits on the topic branch she just pushed, she can run this: +Die Anweisung `git request-pull` verwendet den Ausgangsbranch, für den Ihre Änderungen bestimmt sind, und die URL des Git-Repositorys, von dem Ihre Änderungen heruntergeladen werden sollen, und gibt eine Zusammenfassung aller Änderungen aus, um deren Übernahme Sie bitten. +Wenn Jessica z.B. einen pull request an John schicken will, und sie zwei Commits auf dem gerade hochgeladenen Themenbranch durchgeführt hat, kann sie diese Anweisung ausführen: [source,console] ---- @@ -571,11 +574,11 @@ Jessica Smith (2): 1 files changed, 9 insertions(+), 1 deletions(-) ---- -This output can be sent to the maintainer -- it tells them where the work was branched from, summarizes the commits, and identifies from where the new work is to be pulled. +Diese Meldung kann an den Betreuer gesendet werden – sie teilt ihm mit, woher die Arbeit stammt, fasst die Commits zusammen und gibt an, von wo die neue Arbeit geholt werden soll. -On a project for which you're not the maintainer, it's generally easier to have a branch like `master` always track `origin/master` and to do your work in topic branches that you can easily discard if they're rejected. -Having work themes isolated into topic branches also makes it easier for you to rebase your work if the tip of the main repository has moved in the meantime and your commits no longer apply cleanly. -For example, if you want to submit a second topic of work to the project, don't continue working on the topic branch you just pushed up -- start over from the main repository's `master` branch: +Bei einem Projekt, für das Sie nicht der Betreuer sind, ist es im Allgemeinen einfacher, einen Branch wie `master` zu haben, welcher immer dem `origin/master` Branch folgt, und Ihre eigenen Änderungen in Themenbranches vorzunehmen, die Sie leicht verwerfen können, wenn diese nicht akzeptiert werden. +Wenn Sie Schwerpunkte Ihrer Arbeit in Themenbranches unterteilen, können Sie diese außerdem recht leicht auf den letzten Stand des Hauptrepositorys rebasen, falls das Hauptrepository in der Zwischenzeit weiter entwickelt wurde und Ihre Commits sich nicht mehr sauber anwenden lassen. +Wollen Sie beispielsweise Änderungen zu einem weiteren Thema dem Projekt beisteuern, dann arbeiten Sie nicht weiter auf dem Themenbranch, den Sie gerade hochgeladen haben - sondern beginnen Sie von vorn vom `master` Branch des Hauptrepositorys: [source,console] ---- @@ -588,13 +591,13 @@ $ git request-pull origin/master myfork $ git fetch origin ---- -Now, each of your topics is contained within a silo -- similar to a patch queue -- that you can rewrite, rebase, and modify without the topics interfering or interdepending on each other, like so: +Jedes Ihrer Themen befindet sich jetzt in einer Art Silo – ähnlich einer Patch Queue – sodass Sie diese neu schreiben, rebasen und ändern können, ohne dass die Branches sich gegemseitig stören oder voneinander abhängen: -.Initial commit history with `featureB` work. +.Ursprünglicher Commit-Verlauf bei der Arbeit an `featureB`. image::images/public-small-1.png[Initial commit history with `featureB` work.] -Let's say the project maintainer has pulled in a bunch of other patches and tried your first branch, but it no longer cleanly merges. -In this case, you can try to rebase that branch on top of `origin/master`, resolve the conflicts for the maintainer, and then resubmit your changes: +Nehmen wir an, der Projektbetreiber hat eine Menge von anderen Patches übernommen und versucht, Ihren ersten Branch einfließen zu lassen, aber dieser lässt sich nicht mehr sauber anwenden. +In diesem Fall können Sie Ihre Änderungen auf dem letzten Stand des `origin/master` Branch mittels Rebase hinzufügen, die Konflikte für den Projektbetreiber beheben und Ihre Arbeit erneut einreichen: [source,console] ---- @@ -603,18 +606,18 @@ $ git rebase origin/master $ git push -f myfork featureA ---- -This rewrites your history to now look like <>. +Das schreibt Ihren Commit-Verlauf neu, sodass dieser jetzt so aussieht <>. [[psp_b]] -.Commit history after `featureA` work. +.Commit-Verlauf nach dem Rebase von `featureA`. image::images/public-small-2.png[Commit history after `featureA` work.] -Because you rebased the branch, you have to specify the `-f` to your push command in order to be able to replace the `featureA` branch on the server with a commit that isn't a descendant of it. -An alternative would be to push this new work to a different branch on the server (perhaps called `featureAv2`). +Da Sie den Branch mittels Rebase hinzugefügt haben, müssen Sie die Anweisung `git push` mit der Option `-f` verwenden, um den `featureA`-Branch auf dem Server mit einem Commit ersetzen zu können, der nicht vom gegenwärtig letzten Commit des entfernten Branches abstammt. +Eine Alternative dazu wäre, diese neuen Änderungen in einen anderen Branch auf dem Server hochzuladen (vielleicht namens `featureAv2`). -Let's look at one more possible scenario: the maintainer has looked at work in your second branch and likes the concept but would like you to change an implementation detail. -You'll also take this opportunity to move the work to be based off the project's current `master` branch. -You start a new branch based off the current `origin/master` branch, squash the `featureB` changes there, resolve any conflicts, make the implementation change, and then push that as a new branch: +Schauen wir uns noch ein weiteres mögliches Szenario an: der Projektbetreiber hat sich Ihre Arbeit in Ihrem zweiten Branch angesehen und mag das Konzept, aber er bittet Sie, noch ein Detail an der Implementierung zu ändern. +Sie werden die Gelegenheit außerdem nutzen, um Ihre Änderungen zu verschieben, damit diese auf dem aktuellen `master` Branch des Projektes basieren. +Sie legen dazu ausgehend vom aktuellen `origin/master` Branch einen neuen Branch an, führen Ihre Änderungen aus `featureB` damit zusammen, lösen dabei jegliche Konflikte, erledigen die gewünschte Änderung an der Implementierung und laden das Ganze als neuen Branch hoch: (((git commands, merge, squash))) [source,console] @@ -626,25 +629,25 @@ $ git commit $ git push myfork featureBv2 ---- -The `--squash` option takes all the work on the merged branch and squashes it into one changeset producing the repository state as if a real merge happened, without actually making a merge commit. -This means your future commit will have one parent only and allows you to introduce all the changes from another branch and then make more changes before recording the new commit. -Also the `--no-commit` option can be useful to delay the merge commit in case of the default merge process. +Die Option `--squash` fasst alle Änderungen des einfließenden Branches (featureB) zusammen und komprimiert sie in ein Change-Set, das den Zustand des Repositorys erzeugt, als ob ein echter Merge stattgefunden hätte, ohne tatsächlich einen Merge Commit zu machen. +Das bedeutet, dass Ihr zukünftiger Commit nur einen Elternteil hat und Ihnen ermöglicht, sämtliche Änderungen aus einem anderen Branch zu übernehmen und dann weitere Änderungen vorzunehmen, bevor Sie einen neuen Commit aufzeichnen. +Die Option `--no-commit` weist Git außerdem an, nicht automatisch einen Commit anzulegen. -At this point, you can notify the maintainer that you've made the requested changes, and that they can find those changes in your `featureBv2` branch. +Jetzt können Sie dem Projektbetreiber eine Nachricht schicken, dass Sie die gewünschten Änderungen vorgenommen haben und dass er Ihre Änderungen in Ihrem `featureBv2`-Branch finden kann. -.Commit history after `featureBv2` work. +.Commit-Verlauf nach den Änderungen an `featureBv2`. image::images/public-small-3.png[Commit history after `featureBv2` work.] [[_project_over_email]] -==== Public Project over Email +==== Öffentliches Projekt via E-Mail (((contributing, public large project))) -Many projects have established procedures for accepting patches -- you'll need to check the specific rules for each project, because they will differ. -Since there are several older, larger projects which accept patches via a developer mailing list, we'll go over an example of that now. +Viele Projekte haben festgelegte Verfahren, um Patches entgegenzunehmen – Sie werden sich mit den jeweiligen Regeln vertraut machen müssen, da diese bei jedem Projekt unterschiedlich sein werden. +Da es etliche ältere, große Projekte gibt, welche Patches über eine Mailingliste der Entwickler entgegennehmen, werden wir auf dieses Beispiel als Nächstes eingehen. -The workflow is similar to the previous use case -- you create topic branches for each patch series you work on. -The difference is how you submit them to the project. -Instead of forking the project and pushing to your own writable version, you generate email versions of each commit series and email them to the developer mailing list: +Der Arbeitsablauf ist ähnlich dem im vorherigen Anwendungsfall – Sie erzeugen Themenbranches für jede Patchserie, an der Sie arbeiten. +Der Unterschied besteht dann darin, wie Sie die Änderungen an das Projekt übermitteln. +Anstatt das Projekt zu forken und Änderungen in Ihren Fork hochzuladen, erzeugen Sie E-Mail-Versionen von jeder Ihrer Commit-Folgen und senden diese an die Mailingliste der Entwickler. [source,console] ---- @@ -656,9 +659,9 @@ $ git commit ---- (((git commands, format-patch))) -Now you have two commits that you want to send to the mailing list. -You use `git format-patch` to generate the mbox-formatted files that you can email to the list -- it turns each commit into an email message with the first line of the commit message as the subject and the rest of the message plus the patch that the commit introduces as the body. -The nice thing about this is that applying a patch from an email generated with `format-patch` preserves all the commit information properly. +Jetzt haben Sie zwei Commits, die Sie an die Mailingliste schicken wollen. +Sie verwenden die Anweisung `git format-patch`, um die Dateien im mbox-Format zu erzeugen, die Sie per E-Mail an die Mailingliste schicken können - diese Anweisung macht aus jedem Commit eine E-Mail-Nachricht, wobei die erste Zeile der Commit-Nachricht zum Betreff der E-Mail wird und der Rest der Commit-Nachricht sowie der Patch des Commits selbst wird zum Text der E-Mail. +Das Schöne daran ist, dass bei der Anwendung eines Patches von einer mit `format-patch` erzeugten E-Mail alle Commit-Informationen ordnungsgemäß erhalten bleiben. [source,console] ---- @@ -667,9 +670,9 @@ $ git format-patch -M origin/master 0002-changed-log-output-to-30-from-25.patch ---- -The `format-patch` command prints out the names of the patch files it creates. -The `-M` switch tells Git to look for renames. -The files end up looking like this: +Die Anweisung `git format-patch` zeigt Ihnen die Namen der Patch-Dateien an, die er erzeugt hat. +Die Option `-M` weist Git an, nach umbenannten Dateien Ausschau zu halten. +Die Dateien sehen dann so aus: [source,console] ---- @@ -702,17 +705,17 @@ index 76f47bc..f9815f1 100644 2.1.0 ---- -You can also edit these patch files to add more information for the email list that you don't want to show up in the commit message. -If you add text between the `---` line and the beginning of the patch (the `diff --git` line), the developers can read it, but that content is ignored by the patching process. +Sie können diese Patch-Dateien auch bearbeiten, um weitere Informationen für die Mailingliste hinzuzufügen, die nicht in der Commit-Nachricht erscheinen sollen. +Wenn Sie Text zwischen der `---` Zeile und dem Anfang des Patches (der Zeile `diff --git`) hinzufügen, dann können die Entwickler diesen lesen, bei der Anwendung des Patches wird er aber ausgeschlossen. -To email this to a mailing list, you can either paste the file into your email program or send it via a command-line program. -Pasting the text often causes formatting issues, especially with ``smarter'' clients that don't preserve newlines and other whitespace appropriately. -Luckily, Git provides a tool to help you send properly formatted patches via IMAP, which may be easier for you. -We'll demonstrate how to send a patch via Gmail, which happens to be the email agent we know best; you can read detailed instructions for a number of mail programs at the end of the aforementioned `Documentation/SubmittingPatches` file in the Git source code. +Um das jetzt an eine Mailingliste zu schicken, können Sie die Datei entweder in Ihrem E-Mail Programm einfügen oder sie über ein Befehlszeilen-Programm direkt verschicken. +Das Einfügen des Textes verursacht oft Formatierungsprobleme – insbesondere mit „smarten“ E-Mail-Clients, welche Zeilenumbrüche und Leerzeichen nicht adäquat erhalten. +Glücklicherweise bietet Git ein Tool, das Ihnen hilft, ordnungsgemäß formatierte Patches über IMAP zu verschicken, was einfacher für Sie sein könnte. +Wir werden demonstrieren, wie man Patches über Gmail verschickt, welches der E-Mail-Client ist, mit dem wir uns am besten auskennen; Sie können detaillierte Anleitungen für eine Reihe von E-Mail-Programme am Ende der schon erwähnten Datei `Documentation/SubmittingPatches` im Git Quellcode nachlesen. (((git commands, config)))(((email))) -First, you need to set up the imap section in your `~/.gitconfig` file. -You can set each value separately with a series of `git config` commands, or you can add them manually, but in the end your config file should look something like this: +Zunächst müssen Sie den Abschnitt IMAP in Ihrer `~/.gitconfig` Datei einrichten. +Sie können jeden Wert separat mit einer Reihe von `git config` Anweisungen eingeben oder die Datei öffnen und die Werte manuell eingeben, am Ende sollte Ihre config-Datei in etwa so aussehen: [source,ini] ---- @@ -725,8 +728,8 @@ You can set each value separately with a series of `git config` commands, or you sslverify = false ---- -If your IMAP server doesn't use SSL, the last two lines probably aren't necessary, and the host value will be `imap://` instead of `imaps://`. -When that is set up, you can use `git imap-send` to place the patch series in the Drafts folder of the specified IMAP server: +Wenn Ihr IMAP-Server kein SSL verwendet, sind die letzten beiden Zeilen wahrscheinlich nicht nötig und der Host-Wert müsste `imap://` statt `imaps://` lauten. +Wenn Sie diese Einstellungen vorgenommen haben, können Sie `git send-email` verwenden, um die Patches im Entwurfsordner des angegebenen IMAP-Servers zu platzieren: [source,console] ---- @@ -765,7 +768,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 ---- -Then, Git spits out a bunch of log information looking something like this for each patch you're sending: +Git gibt dann für jeden Patch, den Sie versenden, ein paar Log-Informationen aus, die in etwa so aussehen: [source,text] ---- @@ -785,8 +788,8 @@ References: Result: OK ---- -==== Summary +==== Zusammenfassung -This section has covered a number of common workflows for dealing with several very different types of Git projects you're likely to encounter, and introduced a couple of new tools to help you manage this process. -Next, you'll see how to work the other side of the coin: maintaining a Git project. -You'll learn how to be a benevolent dictator or integration manager. +Dieser Abschnitt hat eine Reihe von gebräuchlichen Arbeitsabläufen behandelt, die für jeweils sehr verschiedene Arten von Projekten üblich sind und denen Du vermutlich begegnen wirst. Wir haben außerdem ein paar neue Tools vorgestellt, die dabei hilfreich sind, diese Workflows umzusetzen. +Als nächstes werden wir auf die andere Seite dieser Medaille eingehen: wie Sie selbst ein Git Projekt betreiben können. +Sie werden erfahren, wie Sie als „wohlwollender Diktator“ oder als Integrationsmanager arbeiten können. diff --git a/book/05-distributed-git/sections/distributed-workflows.asc b/book/05-distributed-git/sections/distributed-workflows.asc index 124fbad7..c0a96f4f 100644 --- a/book/05-distributed-git/sections/distributed-workflows.asc +++ b/book/05-distributed-git/sections/distributed-workflows.asc @@ -1,90 +1,90 @@ -=== Distributed Workflows +=== Verteilter Arbeitsablauf (((workflows))) -In contrast with Centralized Version Control Systems (CVCSs), the distributed nature of Git allows you to be far more flexible in how developers collaborate on projects. -In centralized systems, every developer is a node working more or less equally with a central hub. -In Git, however, every developer is potentially both a node and a hub; that is, every developer can both contribute code to other repositories and maintain a public repository on which others can base their work and which they can contribute to. -This presents a vast range of workflow possibilities for your project and/or your team, so we'll cover a few common paradigms that take advantage of this flexibility. -We'll go over the strengths and possible weaknesses of each design; you can choose a single one to use, or you can mix and match features from each. +Im Gegensatz zu CVCSs (Centralized Version Control Systems) können Sie dank der verteilten Struktur von Git die Zusammenarbeit von Entwicklern in Projekten wesentlich flexibler gestalten. +In zentralisierten Systemen fungieren alle Entwickler als gleichwertige Netzknoten, die mehr oder weniger in der gleichen Art und Weise an einem zentralen Hub arbeiten. +In Git dagegen ist jeder Entwickler potentiell beides – Netzknoten und zentraler Hub, d.h. jeder Entwickler kann sowohl Code zu anderen Repositories beitragen als auch selbst ein öffentliches Repository unterhalten, auf welchem wiederum andere Ihre Arbeit aufbauen und an dem sie mitarbeiten können. +Das eröffnet eine Fülle von möglichen Arbeitsabläufen (engl. Workflows) für Ihr Projekt, weshalb wir einige gängige Verfahren behandeln werden, die diese Flexibilität nutzen. +Wir werden auf 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. -==== Centralized Workflow +==== Zentralisierter Arbeitsablauf (((workflows, centralized))) -In centralized systems, there is generally a single collaboration model -- the centralized workflow. -One central hub, or _repository_, can accept code, and everyone synchronizes their work with it. -A number of developers are nodes -- consumers of that hub -- and synchronize with that centralized location. +In einem zentralisierten System gibt es im Allgemeinen ein einziges Modell für die Zusammenarbeit – der zentralisierte Workflow. +Ein zentraler Hub (oder _Repository_) kann Code von anderen akzeptieren und übernehmen, und alle Beteiligten synchronisieren ihre Arbeit damit. +Eine Reihe von Entwicklern sind Netzknoten – Abnehmer von diesem Hub – und synchronisieren ihre Arbeit mit diesem einen, zentralen Punkt. -.Centralized workflow. -image::images/centralized_workflow.png[Centralized workflow.] +.Zentralisierter Workflow. +image::images/centralized_workflow.png[Zentralisierter Arbeitsablauf.] -This means that if two developers clone from the hub and both make changes, the first developer to push their changes back up can do so with no problems. -The second developer must merge in the first one's work before pushing changes up, so as not to overwrite the first developer's changes. -This concept is as true in Git as it is in Subversion(((Subversion))) (or any CVCS), and this model works perfectly well in Git. +Das bedeutet, wenn zwei Entwickler ein Repository vom zentralen Knotenpunkt klonen und beide lokal Änderungen vornehmen, dann kann der Entwickler, welcher als erster seine Änderungen ins zentrale Repository hochladen möchte, dies ohne Probleme tun. +Der zweite Entwickler muss jedoch zunächst die Änderungen des ersten Entwicklers bei sich einfließen lassen, bevor er seine eigenen Änderungen hochladen kann, damit er die Änderungen des ersten Entwicklers nicht überschreibt. +Dieses Prinzip gilt sowohl für Git als auch für Subversion(((Subversion))) (oder irgendein anderes CVCS). Das Konzept funktioniert bei Git perfekt. -If you are already comfortable with a centralized workflow in your company or team, you can easily continue using that workflow with Git. -Simply set up a single repository, and give everyone on your team push access; Git won't let users overwrite each other. +Wenn Sie in Ihrer Firma oder in Ihrem Team bereits mit einem zentralisierten Arbeitsablauf vertraut sind, können Sie einfach so weitermachen und diesen Arbeitsablauf mit Git realisieren. +Richten Sie einfach ein einziges Repository ein und geben Sie jedem in Ihrem Team Schreibzugriff („push access“). Git sorgt dann dafür, dass niemand die Arbeit von anderen überschreiben kann. -Say John and Jessica both start working at the same time. -John finishes his change and pushes it to the server. -Then Jessica tries to push her changes, but the server rejects them. -She is told that she's trying to push non-fast-forward changes and that she won't be able to do so until she fetches and merges. -This workflow is attractive to a lot of people because it's a paradigm that many are familiar and comfortable with. +Angenommen, John und Jessica beginnen gleichzeitig mit der Arbeit. +John beendet seine Änderungen und lädt diese auf den Server hoch. +Dann versucht Jessica, ihre Änderungen hochzuladen, aber der Server weist diese zurück. +Ihr wird mitgeteilt, dass sie versucht hat „non-fast-forward“ Änderungen hochzuladen und dass sie das erst dann durchführen kann, wenn sie zuvor vorhandene andere Änderungen geholt und zusammengeführt hat. +Viele Anwender mögen diesen Arbeitsablauf, weil sie mit dem bewährten Modell bereits vertraut sind und es bequem ist. -This is also not limited to small teams. -With Git's branching model, it's possible for hundreds of developers to successfully work on a single project through dozens of branches simultaneously. +Das gilt nicht nur für kleine Teams. +Mit dem Branching-Modell von Git ist es Hunderten von Entwicklern möglich, an einem einzelnen Projekt, über Dutzende von Branches, gleichzeitig erfolgreich zu arbeiten. [[_integration_manager]] -==== Integration-Manager Workflow +==== Arbeitsablauf mit Integrationsmanager (((workflows, integration manager))) -Because Git allows you to have multiple remote repositories, it's possible to have a workflow where each developer has write access to their own public repository and read access to everyone else's. -This scenario often includes a canonical repository that represents the ``official'' project. -To contribute to that project, you create your own public clone of the project and push your changes to it. -Then, you can send a request to the maintainer of the main project to pull in your changes. -The maintainer can then add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository. -The process works as follows (see <>): - -1. The project maintainer pushes to their public repository. -2. A contributor clones that repository and makes changes. -3. The contributor pushes to their own public copy. -4. The contributor sends the maintainer an email asking them to pull changes. -5. The maintainer adds the contributor's repository as a remote and merges locally. -6. The maintainer pushes merged changes to the main repository. +Da Git es Ihnen ermöglicht, mehrere Remote-Repositorys zu betreiben, ist ein Workflow möglich, bei dem jeder Entwickler Schreibzugriff auf sein eigenes öffentliches Repository und Lesezugriff auf alle anderen hat. +Dieses Szenario beinhaltet häufig ein eigens dafür eingerichtetes Repository, welches das „offizielle“ Projekt darstellt. +Um Änderungen zu einem solchen Projekt beizusteuern, können Sie Ihren eigenen öffentlichen Klon des Projektes anlegen und Ihre Änderungen dorthin hochladen. +Anschließend können Sie den Betreiber des Haupt-Repositories bitten, Ihre Änderungen in sein Repository zu übernehmen. +Der Betreiber kann dann Ihr Repository als ein entferntes Repository auf seinem Rechner hinzufügen, Ihre Änderungen lokal testen, diese in einen seiner Branches einfließen lassen und dann in sein öffentliches Repository hochladen. +Dieser Prozess läuft wie folgt ab (siehe <>): + +1. Der Projektbetreiber lädt in sein öffentliches Repository hoch. +2. Ein Mitwirkender klont dieses Repository und nimmt Änderungen vor. +3. Der Beitragende lädt diese in sein eigenes öffentliches Repository hoch. +4. Der Beitragende schickt dem Betreiber eine E-Mail und bittet darum, die Änderungen zu übernehmen. +5. Der Betreuer fügt das Repository des Beitragenden als ein Remote-Repository 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))) -This is a very common workflow with hub-based tools like GitHub or GitLab, where it's easy to fork a project and push your changes into your fork for everyone to see. -One of the main advantages of this approach is that you can continue to work, and the maintainer of the main repository can pull in your changes at any time. -Contributors don't have to wait for the project to incorporate their changes -- each party can work at their own pace. +Das ist ein sehr verbreiteter Workflow bei hub-basierten Werkzeugen wie GitHub oder GitLab, wo es sehr einfach ist, ein Projekt zu „forken“ und Ihre Änderungen in Ihren eigenen Fork hochzuladen, wo jeder sie sehen kann. +Einer der Hauptvorteile dieser Vorgehensweise ist, dass Sie an Ihrem Fork weiterarbeiten können und der Betreiber des Haupt-Repositorys Ihre Änderungen jederzeit übernehmen kann. +Mitarbieter müssen nicht darauf warten, dass der Betreiber ihre Änderungen einarbeitet – jeder Beteiligte kann in seinem eigenen Tempo arbeiten. -==== Dictator and Lieutenants Workflow +==== Arbeitsablauf mit Diktator und Leutnants (((workflows, dictator and lieutenants))) -This is a variant of a multiple-repository workflow. -It's generally used by huge projects with hundreds of collaborators; one famous example is the Linux kernel. -Various integration managers are in charge of certain parts of the repository; they're called _lieutenants_. -All the lieutenants have one integration manager known as the benevolent dictator. -The benevolent dictator pushes from his directory to a reference repository from which all the collaborators need to pull. -The process works like this (see <>): - -1. Regular developers work on their topic branch and rebase their work on top of `master`. - The `master` branch is that of the reference repository to which the dictator pushes. -2. Lieutenants merge the developers' topic branches into their `master` branch. -3. The dictator merges the lieutenants' `master` branches into the dictator's `master` branch. -4. Finally, the dictator pushes that `master` branch to the reference repository so the other developers can rebase on it. +Dies ist eine Variante eines Arbeitsablaufs mit vielen Repositories. +Sie wird normalerweise bei sehr großen Projekten mit hunderten von Mitarbeitern verwendet; ein bekanntes Beispiel ist der Linux Kernel. +Verschiedene Integrationsmanager sind zuständig für bestimmte Teile des Repositorys; sie werden _Leutnants_ genannt. +Alle Leutnants haben wiederum einen Integrationsmanager, der als der wohlwollende Diktator (benevolent dictator) bezeichnet wird. +Der wohlwollende Diktator pusht von seinem Verzeichnis zu einem Referenz-Repository, aus dem alle Beteiligten ihre eigenen Repositories aktualisieren müssen. +Dieser Prozess funktioniert wie folgt (siehe <>): + +1. Normale Entwickler arbeiten an ihren Themenbranches und fügen Ihre Arbeit an der Spitze des `master` Branch mittels Rebase ein. + Der `master` Branch ist der des Referenz-Repositorys, in das der Diktator pusht. +2. Die Leutnants führen die Themenbranches der Entwickler mit ihren `master` Branches zusammen. +3. Der Diktator führt die `master`-Branches der Leutnants mit seinem eigenen `master`-Branch zusammen. +4. Der Diktator lädt seinen `master`-Branch ins Referenz-Repository hoch, damit die anderen Entwickler darauf einen Rebase durchführen können. [[wfdiag_c]] -.Benevolent dictator workflow. -image::images/benevolent-dictator.png[Benevolent dictator workflow.] +.Arbeitsablauf mit wohlwollendem Diktator. +image::images/benevolent-dictator.png[Arbeitsablauf mit wohlwollendem Diktator.] -This kind of workflow isn't common, but can be useful in very big projects, or in highly hierarchical environments. -It allows the project leader (the dictator) to delegate much of the work and collect large subsets of code at multiple points before integrating them. +Diese Art Arbeitsablauf ist nicht weit verbreitet, kann aber bei sehr großen Projekten oder in stark hierarchischen Umgebungen sehr nützlich sein. +Er ermöglicht es dem Projektleiter (dem Diktator), Arbeit in großem Umfang zu delegieren und große Teilbereiche von Code an verschiedenen Punkten einzusammeln, bevor diese integriert werden. -==== Workflows Summary +==== Zusammenfassung Arbeitsabläufe -These are some commonly used workflows that are possible with a distributed system like Git, but you can see that many variations are possible to suit your particular real-world workflow. -Now that you can (hopefully) determine which workflow combination may work for you, we'll cover some more specific examples of how to accomplish the main roles that make up the different flows. -In the next section, you'll learn about a few common patterns for contributing to a project. +Dies sind einige häufig verwendete Arbeitsabläufe, die mit verteilten Systemen wie Git möglich sind, aber Sie können sehen, dass viele Variationen möglich sind, um genau zu Ihrem speziellen Arbeitsablauf in der realen Welt zu passen. +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 unterschliedliche Abläufe ausmachen. +Im nächsten Abschnitt erfahren Sie etwas über gängige Formen der Mitarbeit an einem Projekt. diff --git a/book/preface_schacon.asc b/book/preface_schacon.asc index 29d78e5e..846bebaa 100644 --- a/book/preface_schacon.asc +++ b/book/preface_schacon.asc @@ -1,36 +1,35 @@ [preface] -== Preface by Scott Chacon - -Welcome to the second edition of Pro Git. -The first edition was published over four years ago now. -Since then a lot has changed and yet many important things have not. -While most of the core commands and concepts are still valid today as the Git core team is pretty fantastic at keeping things backward compatible, there have been some significant additions and changes in the community surrounding Git. -The second edition of this book is meant to address those changes and update the book so it can be more helpful to the new user. - -When I wrote the first edition, Git was still a relatively difficult to use and barely adopted tool for the harder core hacker. -It was starting to gain steam in certain communities, but had not reached anywhere near the ubiquity it has today. -Since then, nearly every open source community has adopted it. -Git has made incredible progress on Windows, in the explosion of graphical user interfaces to it for all platforms, in IDE support and in business use. -The Pro Git of four years ago knows about none of that. -One of the main aims of this new edition is to touch on all of those new frontiers in the Git community. - -The Open Source community using Git has also exploded. -When I originally sat down to write the book nearly five years ago (it took me a while to get the first version out), I had just started working at a very little known company developing a Git hosting website called GitHub. -At the time of publishing there were maybe a few thousand people using the site and just four of us working on it. -As I write this introduction, GitHub is announcing our 10 millionth hosted project, with nearly 5 million registered developer accounts and over 230 employees. -Love it or hate it, GitHub has heavily changed large swaths of the Open Source community in a way that was barely conceivable when I sat down to write the first edition. - -I wrote a small section in the original version of Pro Git about GitHub as an example of hosted Git which I was never very comfortable with. -I didn't much like that I was writing what I felt was essentially a community resource and also talking about my company in it. -While I still don't love that conflict of interests, the importance of GitHub in the Git community is unavoidable. -Instead of an example of Git hosting, I have decided to turn that part of the book into more deeply describing what GitHub is and how to effectively use it. -If you are going to learn how to use Git then knowing how to use GitHub will help you take part in a huge community, which is valuable no matter which Git host you decide to use for your own code. - -The other large change in the time since the last publishing has been the development and rise of the HTTP protocol for Git network transactions. -Most of the examples in the book have been changed to HTTP from SSH because it's so much simpler. - -It's been amazing to watch Git grow over the past few years from a relatively obscure version control system to basically dominating commercial and open source version control. -I'm happy that Pro Git has done so well and has also been able to be one of the few technical books on the market that is both quite successful and fully open source. - -I hope you enjoy this updated edition of Pro Git. - +== Vorwort von Scott Chacon + +Herzlich willkommen bei der zweiten Auflage von Pro Git. +Seit die erste Auflage vor fast vier Jahren veröffentlicht wurde, hat sich eine Menge in der Welt von Git verändert und doch sind viele wichtige Dinge gleich geblieben. +Das Kernteam von Git stellt sicher, und das machen sie ziemlich gut, dass die grundlegenden Befehle und Struktur abwärtskompatibel bleiben. Und doch gab es ein paar bedeutende Ergänzungen in Git und Weiterentwicklungen rund um die Git-Community. +In der zweiten Auflage des Buches sollen diese Änderungen behandelt werden. Außerdem wurden viele Passagen aktualisiert, so dass vor allem neue Git Benutzer leichter einsteigen können. + +Zu der Zeit, als ich die erste Edition geschrieben habe, war Git relativ schwierig zu bedienen und kaum benutzerfreundlich. +Es richtete sich eher an die fortgeschrittenen Anwender. +In einigen Communitys wurde es immer beliebter, aber es war lange nicht so allgegenwärtig, wie es heute ist. +Inzwischen verwendet nahezu jede im Open Source Bereich tätige Community das Werkzeug. +Es gab unglaubliche Fortschritte auf Windows-Betriebssystemen, zahlreiche grafische Oberflächen für alle Plattformen wurden veröffentlicht und die Integration in Entwicklungsumgebungen und im Geschäftsbereich wurde verbessert. +Das hätte ich mir vor vier Jahren nicht vorstellen können. +In dieser neuen Auflage möchte ich besonders die zahlreichen, neu erschlossenen Bereiche der Git Community thematisieren. + +Die Open Source Community, die Git verwendet, ist sprichwörtlich explodiert. +Als ich mich vor fast fünf Jahren hingesetzt habe, um dieses Buch zu schreiben (ja, es hat eine ganze Weile gedauert um das erste Buch zu veröffentlichen), habe ich gerade bei einer eher unbekannten kleinen Firma angefangen zu arbeiten. Diese Firma beschäftigte sich mit der Entwicklung einer Git Hosting Website, genannt GitHub. +Zu der Zeit, als das Buch veröffentlicht wurde, gab es vielleicht ein paar tausend Leute, die die Website benutzt haben und wir waren nur zu viert, die an ihr gearbeitet haben. +Während ich dieses Vorwort schreibe, kündigt GitHub unser 10-millionstes, gehostetes Projekt an. GitHub hat zu diesem Zeitpunkt über 5 Millionen registrierte Benutzer und unterhält mehr als 230 Mitarbeiter. +Man kann es gut oder schlecht finden, aber GitHub hat große Teile der Open Source Community verändert, wie ich es mir in der Zeit, als ich das erste Buch geschrieben habe, in meinen kühnsten Träumen nicht hätte vorstellen können. + +In der ersten Auflage von Pro Git habe ich ein kurzes Kapitel über GitHub verfasst. Ich wollte damit zeigen, wie Git Hosting aussehen kann. Ich habe mich beim Schreiben des Kapitels aber nie richtig wohl gefühlt. +Ich mochte es nicht, dass ich über etwas schreibe, was aus einer Community heraus entstanden ist und in das meine Firma involviert ist. +Ich mag diesen Interessenkonflikt immer noch nicht, aber die Bedeutung von GitHub in der Git Community ist unverkennbar. +Ich habe mich deshalb dazu entschlossen, dass angesprochene Kapitel umzuschreiben und statt einem Beispiel für Git Hosting möchte ich genauer erklären, was GitHub ist und wie man es effektiv nutzen kann. +Wenn man vor hat, sich mit Git zu beschäftigen und man weiß, wie GitHub funktioniert, hilft es einem sehr gut, ein Teil einer riesigen Gemeinschaft zu werden. Das kann sehr wertvoll sein und schlussendlich ist es dann auch egal, für welchen Git Hosting Partner man sich für seinen eigenen Code entscheidet. + +Ein weitere, große Änderung im Bereich Git seit dem letzten Erscheinen des Buches, war die Weiterentwicklung und -verbreitung des HTTP Protokolls für die Übertragung von Git Daten. +Deshalb habe ich die meisten Beispiele angepasst und statt SSH wird jetzt HTTP verwendet, was vieles auch viel einfacher macht. + +Es war großartig dabei zuzuschauen, wie sich Git die letzten paar Jahre weiterentwickelt hat, von einem doch eher obskuren Versionskontrollsystem zu einem dominierenden Versionskontrollsystem im Open Source und Geschäftsbereich. +Ich bin glücklich, wie es bisher mit Pro Git gelaufen ist und dass es einer der wenigen technischen Bücher auf dem Markt ist, welches sowohl ziemlich erfolgreich, als auch uneingeschränkt Open Source ist. + +Ich hoffe, Sie haben viel Spaß mit der neuen Auflage von Pro Git. diff --git a/ch01-getting-started.asc b/ch01-getting-started.asc index b5f0d22c..9e448468 100644 --- a/ch01-getting-started.asc +++ b/ch01-getting-started.asc @@ -1,9 +1,9 @@ [[ch01-getting-started]] -== Getting Started +== Erste Schritte -This chapter will be about getting started with Git. -We will begin by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it set up to start working with. -At the end of this chapter you should understand why Git is around, why you should use it and you should be all set up to do so. +In diesem Kapitel wird es darum gehen, wie Sie mit Git zu beginnen können. +Wir starten mit einer Erläuterung des Hintergrunds zu Versionskontroll-Systemen, gehen dann weiter zu dem Thema, wie Sie Git auf Ihrem System zum Laufen bringen und schließlich wie Sie es einrichten können, sodass Sie in der Lage sind, die ersten Schritte mit Git zu tun. +Am Ende dieses Kapitels sollten Sie verstehen, wozu Git gut ist und weshalb man es verwenden sollte und Sie sollten in der Lage sein, mit Git loslegen zu können. include::book/01-introduction/sections/about-version-control.asc[] @@ -19,8 +19,8 @@ include::book/01-introduction/sections/first-time-setup.asc[] include::book/01-introduction/sections/help.asc[] -=== Summary +=== Zusammenfassung -You should have a basic understanding of what Git is and how it's different from any centralized version control systems you may have been using previously. -You should also now have a working version of Git on your system that's set up with your personal identity. -It's now time to learn some Git basics. +Sie sollten jetzt ein grundlegendes Verständnis dafür haben, was Git ist und wie es sich von anderen zentralisierten Versionsverwaltungs-Systemen unterscheidet, die Sie ev. bisher eingesetzt haben. +Sie sollten nun auch eine funktionierende Version von Git auf Ihrem System haben, die mit Ihrer persönlichen Identität eingerichtet ist. +Es ist jetzt an der Zeit, einige Grundlagen von Git zu lernen. diff --git a/ch02-git-basics-chapter.asc b/ch02-git-basics-chapter.asc index 08db2548..0cfff976 100644 --- a/ch02-git-basics-chapter.asc +++ b/ch02-git-basics-chapter.asc @@ -1,10 +1,10 @@ [[ch02-git-basics-chapter]] -== Git Basics +== Git Grundlagen -If you can read only one chapter to get going with Git, this is it. -This chapter covers every basic command you need to do the vast majority of the things you'll eventually spend your time doing with Git. -By the end of the chapter, you should be able to configure and initialize a repository, begin and stop tracking files, and stage and commit changes. -We'll also show you how to set up Git to ignore certain files and file patterns, how to undo mistakes quickly and easily, how to browse the history of your project and view changes between commits, and how to push and pull from remote repositories. +Wenn Sie nur ein Kapitel durcharbeiten können/wollen, um mit Git zu beginnen, dann ist dieses hier das richtige. +Dieses Kapitel behandelt alle grundlegenden Befehle, die Sie benötigen, um die überwiegende Anzahl der Aufgaben zu erledigen, die Sie irgendwann einmal mit Git erledigen werden. +Am Ende des Kapitels sollten Sie in der Lage sein, ein neues Repository anzulegen und zu konfigurieren, Dateien zu versionieren bzw. aus der Versionsverwaltung zu entfernen, Dateien in die Staging-Area hinzuzufügen und schließlich einen Commit durchzuführen. +Außerdem wird gezeigt, wie Sie Git so konfigurieren können, dass es bestimmte Dateien und Dateimuster ignoriert, wie Sie Fehler schnell und einfach rückgängig machen, wie Sie die Historie eines Projekts durchsuchen und Änderungen zwischen Commits nachschlagen, und wie Sie von einem Remote-Repository Daten herunter- bzw. dort hochladen können. include::book/02-git-basics/sections/getting-a-repository.asc[] @@ -20,7 +20,7 @@ include::book/02-git-basics/sections/tagging.asc[] include::book/02-git-basics/sections/aliases.asc[] -=== Summary +=== Zusammenfassung -At this point, you can do all the basic local Git operations -- creating or cloning a repository, making changes, staging and committing those changes, and viewing the history of all the changes the repository has been through. -Next, we'll cover Git's killer feature: its branching model. +Sie sollten jetzt in der Lage sein, die wichtigsten Git Befehle einsetzen zu können – Folgendes sollte Ihnen jetzt gelingen: Erzeugen oder Klonen eines Repositorys, Änderungen vorzunehmen und zur Staging-Area hinzuzufügen, Commits anzulegen und die Historie aller Commits in einem Repository zu durchsuchen. +Als nächstes werden wir uns mit der „Killer-Funktion“ von Git befassen: dem Branching-Modell. diff --git a/ch04-git-on-the-server.asc b/ch04-git-on-the-server.asc index a867a63c..f63ffc1d 100644 --- a/ch04-git-on-the-server.asc +++ b/ch04-git-on-the-server.asc @@ -1,24 +1,24 @@ [[ch04-git-on-the-server]] -== Git on the Server +== Git auf dem Server (((serving repositories))) -At this point, you should be able to do most of the day-to-day tasks for which you'll be using Git. -However, in order to do any collaboration in Git, you'll need to have a remote Git repository. -Although you can technically push changes to and pull changes from individuals' repositories, doing so is discouraged because you can fairly easily confuse what they're working on if you're not careful. -Furthermore, you want your collaborators to be able to access the repository even if your computer is offline -- having a more reliable common repository is often useful. -Therefore, the preferred method for collaborating with someone is to set up an intermediate repository that you both have access to, and push to and pull from that. +An dieser Stelle sollten Sie in der Lage sein, die meisten der täglichen Aufgaben zu erledigen, für die Sie Git verwenden werden. +Um jedoch in Git zusammenarbeiten zu können, benötigen Sie ein externes Git-Repository. +Obwohl Sie, technisch gesehen, Änderungen an und aus den individuellen Repositories verschieben können, ist das nicht empfehlenswert, da Sie sich ziemlich leicht irren könnten, woran sie arbeiten, wenn Sie nicht vorsichtig sind. +Darüber hinaus ist es vorteilhaft, dass Ihre Mitarbeiter auch dann auf das Repository zugreifen können, wenn Ihr Computer offline ist – ein zuverlässigeres gemeinsames Repository ist oft sinnvoll. +Daher ist die bevorzugte Methode für die Zusammenarbeit, einen Zwischenspeicher einzurichten, auf den beide Seiten Zugriff haben, und von dem aus sie Push-to and Pull ausführen können. -Running a Git server is fairly straightforward. -First, you choose which protocols you want your server to support. -The first section of this chapter will cover the available protocols and the pros and cons of each. -The next sections will explain some typical setups using those protocols and how to get your server running with them. -Last, we'll go over a few hosted options, if you don't mind hosting your code on someone else's server and don't want to go through the hassle of setting up and maintaining your own server. +Das Betreiben eines Git-Servers ist recht unkompliziert. +Zuerst bestimmen Sie, welche Protokolle Ihr Server unterstützen soll. +Der erste Abschnitt dieses Kapitels behandelt die verfügbaren Protokolle und deren Vor- und Nachteile. +In den nächsten Abschnitten werden einige typische Setups mit diesen Protokollen erläutert und erklärt, wie Sie Ihren Server mit diesen Protokollen zum Laufen bringen. +Zuletzt werden wir ein paar gehostete Optionen durchgehen, wenn es Ihnen nichts ausmacht, Ihren Code auf dem Server eines anderen zu hosten und Sie nicht den Aufwand der Einrichtung und Wartung Ihres eigenen Servers auf sich nehmen wollen. -If you have no interest in running your own server, you can skip to the last section of the chapter to see some options for setting up a hosted account and then move on to the next chapter, where we discuss the various ins and outs of working in a distributed source control environment. +Wenn Sie keinen eigenen Server betreiben möchten, können Sie zum letzten Abschnitt dieses Kapitels springen, um einige Optionen zum Einrichten eines gehosteten Kontos zu finden und dann mit dem nächsten Kapitel fortfahren, in dem die verschiedenen Vor- und Nachteile der Arbeit in einer verteilten Versionskontrollumgebung erläutert werden. -A remote repository is generally a _bare repository_ -- a Git repository that has no working directory. -Because the repository is only used as a collaboration point, there is no reason to have a snapshot checked out on disk; it's just the Git data. -In the simplest terms, a bare repository is the contents of your project's `.git` directory and nothing else. +Ein entferntes Repository ist in der Regel ein _„nacktes Repository“_ – ein Git-Repository, das kein Arbeitsverzeichnis hat. +Da das Repository nur als Kollaborationspunkt verwendet wird, gibt es keinen Grund, einen Snapshot auf die Festplatte speichern zu lassen; es enthält nur die Git-(Kontroll-)Daten. +Im einfachsten Fall besteht ein nacktes (eng. bare) Repository aus dem Inhalt des `.git` Verzeichnisses Ihres Projekts und nichts anderem. include::book/04-git-server/sections/protocols.asc[] @@ -40,9 +40,9 @@ include::book/04-git-server/sections/hosted.asc[] === Summary -You have several options to get a remote Git repository up and running so that you can collaborate with others or share your work. +Sie haben mehrere Möglichkeiten, ein entferntes Git-Repository in Betrieb zu nehmen, damit Sie mit anderen zusammenarbeiten oder Ihre Arbeit teilen können. -Running your own server gives you a lot of control and allows you to run the server within your own firewall, but such a server generally requires a fair amount of your time to set up and maintain. -If you place your data on a hosted server, it's easy to set up and maintain; however, you have to be able to keep your code on someone else's servers, and some organizations don't allow that. +Der Betrieb eines eigenen Servers gibt Ihnen viel Kontrolle und ermöglicht es Ihnen, den Server innerhalb Ihrer eigenen Firewall zu betreiben, aber ein solcher Server benötigt in der Regel einen angemessenen Teil Ihrer Zeit für die Einrichtung und Wartung. +Wenn Sie Ihre Daten auf einem gehosteten Server ablegen, ist es einfach, sie einzurichten und zu warten; Sie müssen aber die Möglichkeit haben, Ihren Code auf fremden Servern zu speichern, und einige Unternehmen erlauben das nicht. -It should be fairly straightforward to determine which solution or combination of solutions is appropriate for you and your organization. +Es sollte ziemlich einfach sein, festzustellen, welche Lösung oder Kombination von Lösungen für Sie und Ihr Unternehmen am besten geeignet ist. diff --git a/ch10-git-internals.asc b/ch10-git-internals.asc index a82f2fbc..ecbc7546 100644 --- a/ch10-git-internals.asc +++ b/ch10-git-internals.asc @@ -1,5 +1,5 @@ [[ch10-git-internals]] -== Git Internals +== Git Interna You may have skipped to this chapter from a much earlier chapter, or you may have gotten here after sequentially reading the entire book up to this point -- in either case, this is where we'll go over the inner workings and implementation of Git. We found that understanding this information was fundamentally important to appreciating how useful and powerful Git is, but others have argued to us that it can be confusing and unnecessarily complex for beginners. diff --git a/script/tag_on_master b/script/tag_on_master old mode 100755 new mode 100644 diff --git a/status.json b/status.json index fc15757a..a9211d98 100644 --- a/status.json +++ b/status.json @@ -1,23 +1,23 @@ { - "code": "en", - "language": "English", - "maintainers": ["schacon"], + "code": "de", + "language": "German", + "maintainers": ["max123kl" "pastatopf"], "files": { "01-introduction": { - "1-introduction.asc": 0, - "sections/about-version-control.asc": 0, - "sections/basics.asc": 0, - "sections/command-line.asc": 0, - "sections/first-time-setup.asc": 0, - "sections/help.asc": 0, - "sections/history.asc": 0, - "sections/installing.asc": 0 + "1-introduction.asc": 100, + "sections/about-version-control.asc": 100, + "sections/basics.asc": 100, + "sections/command-line.asc": 100, + "sections/first-time-setup.asc": 100, + "sections/help.asc": 100, + "sections/history.asc": 100, + "sections/installing.asc": 100 }, "02-git-basics": { - "1-git-basics.asc": 0, + "1-git-basics.asc": 100, "sections/aliases.asc": 0, - "sections/getting-a-repository.asc": 0, - "sections/recording-changes.asc": 0, + "sections/getting-a-repository.asc": 100, + "sections/recording-changes.asc": 100, "sections/remotes.asc": 0, "sections/tagging.asc": 0, "sections/undoing.asc": 0, @@ -33,14 +33,14 @@ "sections/workflows.asc": 0 }, "04-git-server": { - "1-git-server.asc": 0, + "1-git-server.asc": 100, "sections/generating-ssh-key.asc": 0, "sections/git-daemon.asc": 0, "sections/git-on-a-server.asc": 0, "sections/gitlab.asc": 0, "sections/gitweb.asc": 0, "sections/hosted.asc": 0, - "sections/protocols.asc": 0, + "sections/protocols.asc": 100, "sections/setting-up-server.asc": 0, "sections/smart-http.asc": 0 },