Merge remote-tracking branch 'origin/master' into chapter-8-3

Author: max123kl

TRANSLATION_NOTES_DE.asc

@@ -122,6 +122,8 @@ Projektbetreuer
 betreuen
 |to merge|
 mergen; er/sie mergt; wir mergen; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung "zusammenführen oder verschmelzen" verwendet werden.
+|namespace|
+namespace; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung "Namensraum" verwendet werden.
 |packfile|
 packfile; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung "Paketdatei" verwendet werden.
 |Patch|
@@ -146,6 +148,8 @@ pushen; er/sie pusht; wir pushen; Deutsch: hochladen
 |Englisch|Deutsch
 |to rebase|
 rebasen; er/sie rebaset, wir rebasen; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung "reorganisieren oder restrukturieren" verwendet werden.
+|refspec|
+refspec; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung "Referenzspezifikation" verwendet werden.
 |Repository|
 Repository; Singular: das Repository; Plural: die Repositorys; **Nicht** Repositor**ie**s,
 siehe hierzu auch link:http://www.duden.de/sprachwissen/sprachratgeber/crashkurs--in-25-schritten-zur-neuen-rechtschreibung[folgender Link]

book/09-git-and-other-scms/sections/import-custom.asc

@@ -30,7 +30,7 @@ Wie Sie sich vielleicht erinnern, ist Git im Grunde genommen eine verknüpfte Li
 Alles, was Sie tun müssen, ist `fast-import` mitzuteilen, worum es sich bei den Content-Snapshots handelt, welche Commit-Datenpunkte zu ihnen gehören und in welcher Reihenfolge sie in den jeweiligen Ordner gehören.
 Ihre Strategie besteht darin, die Snapshots einzeln durchzugehen und Commits mit dem Inhalt jedes Verzeichnisses zu erstellen. Dabei wird jeder Commit mit dem vorherigen verknüpft.
 
-Wie wir es in Kapitel 8, <<ch08-customizing-git#,Beispiel für Git-forcierte Regeln>> getan haben, werden wir das in Ruby schreiben, denn damit arbeiten wir normalerweise und es ist eher leicht zu lesen.
+Wie wir es in Kapitel 8, <<ch08-customizing-git#_an_example_git_enforced_policy,Beispiel für Git-forcierte Regeln>> getan haben, werden wir das in Ruby schreiben, denn damit arbeiten wir normalerweise und es ist eher leicht zu lesen.
 Sie können dieses Beispiel sehr leicht in jedem Editor schreiben, den Sie kennen – er muss nur die entsprechenden Informationen nach `stdout` ausgeben können.
 Unter Windows müssen Sie besonders darauf achten, dass Sie am Ende Ihrer Zeilen keine Zeilenumbrüche einfügen – `git fast-import` ist da sehr empfindlich, wenn es darum geht, nur Zeilenvorschübe (LF) und nicht die von Windows verwendeten Zeilenvorschübe (CRLF) zu verwenden.
 

book/10-git-internals/sections/plumbing-porcelain.asc

@@ -1,12 +1,12 @@
 [[_plumbing_porcelain]]
-=== Basiskommandos und Hauptbefehle (Plumbing and Porcelain)
+=== Basisbefehle und Standardbefehle (Plumbing and Porcelain)
 
-In diesem Buch wird in erster Linie beschrieben, wie Git mit etwa 30 Unterbefehlen wie `checkout`, `branch`, `remote` usw. verwendet wird.
-Git war ursprünglich ein Werkzeug für ein Versionskontrollsystem und kein benutzerfreundliches VCS. Somit verfügt es über eine Reihe von Unterbefehlen, die auf niedriger Ebene ausgeführt werden und so konzipiert sind, dass sie im UNIX-Stil verkettet oder über Skripte aufgerufen werden können.
-Diese Befehle werden im Allgemeinen als Basiskommandos von Git bezeichnet, während die benutzerfreundlicheren Befehle als Hauptbefehle bezeichnet werden.
+In diesem Buch wird in erster Linie beschrieben, wie Git mit etwa 30 Standardbefehlen wie `checkout`, `branch`, `remote` usw. verwendet wird.
+Git war ursprünglich ein Werkzeug für ein Versionskontrollsystem und kein benutzerfreundliches VCS. Somit verfügt es über eine Reihe von Basisbefehlen, die auf niedriger Ebene ausgeführt werden und so konzipiert sind, dass sie im UNIX-Stil verkettet oder über Skripte aufgerufen werden können.
+Diese Befehle werden im Allgemeinen als Basisbefehle von Git bezeichnet, während die benutzerfreundlicheren Befehle als Standardbefehle bezeichnet werden.
 
-Wie Sie bereits bemerkt haben, befassen sich die ersten neun Kapitel dieses Buches fast ausschließlich mit Hauptbefehlen.
-In diesem Kapitel werden Sie sich jedoch hauptsächlich mit den Basiskommandos der niedrigeren Ebene befassen. Diese ermöglichen Ihnen den Zugriff auf das Innenleben von Git und helfen Ihnen dabei zu demonstrieren, wie und warum Git das tut, was es tut.
+Wie Sie bereits bemerkt haben, befassen sich die ersten neun Kapitel dieses Buches fast ausschließlich mit Standardbefehlen.
+In diesem Kapitel werden Sie sich jedoch hauptsächlich mit den Basisbefehle der niedrigeren Ebene befassen. Diese ermöglichen Ihnen den Zugriff auf das Innenleben von Git und helfen Ihnen dabei zu demonstrieren, wie und warum Git das tut, was es tut.
 Viele dieser Befehle sollten nicht manuell in der Befehlszeile verwendet werden, sondern als Bausteine für neue Tools und benutzerdefinierte Skripts genutzt werden.
 
 Wenn Sie `git init` in einem neuen oder vorhandenen Verzeichnis ausführen, erstellt Git das `.git`-Verzeichnis, in dem sich fast alles befindet, was Git speichert und bearbeitet.
@@ -34,4 +34,4 @@ Das `hooks`-Verzeichnis enthält Ihre client- oder serverseitigen Hook-Skripte,
 Dies hinterlässt vier wichtige Einträge: die `HEAD` - und (noch zu erstellenden) 'index`-Dateien sowie die `objects` - und `refs`-Verzeichnisse.
 Dies sind die Kernelemente von Git.
 Das `objects` -Verzeichnis speichert den gesamten Inhalt für Ihre Datenbank, das `refs`-Verzeichnis speichert Zeiger auf Commit-Objekte in diesen Daten (Zweige, Tags, Remotes, usw.) und die `HEAD`-Datei zeigt auf den Zweig, den Sie gerade ausgecheckt haben. In der `index`-Datei speichert Git Ihre Staging-Bereichsinformationen.
-Sie werden sich nun jeden dieser Abschnitte genauer ansehen, um zu sehen, wie Git funktioniert.
+Sie werden sich nun jeden dieser Abschnitte genauer ansehen, um zu sehen, wie Git funktioniert.

book/10-git-internals/sections/refspec.asc

@@ -1,15 +1,15 @@
 [[_refspec]]
-=== The Refspec
+=== Die Referenzspezifikation (engl. Refspec)
 
-Throughout this book, we've used simple mappings from remote branches to local references, but they can be more complex.
-Suppose you were following along with the last couple sections and had created a small local Git repository, and now wanted to add a _remote_ to it:
+In diesem Buch haben wir simple Zuordnungen von remote Branches zu lokalen Referenzen verwendet, diese können jedoch komplexer sein.
+Angenommen, Sie haben die letzten Abschnitte mitverfolgt und ein kleines lokales Git-Repository erstellt, und möchten nun eine _remote_ hinzufügen:
 
 [source,console]
 ----
 $ git remote add origin https://github.com/schacon/simplegit-progit
 ----
 
-Running the command above adds a section to your repository's `.git/config` file, specifying the name of the remote (`origin`), the URL of the remote repository, and the _refspec_ to be used for fetching:
+Durch Ausführen des obigen Befehls wird ein Abschnitt zur `.git/config`-Datei Ihres Repositorys hinzugefügt. Es wird der Name des Remote-Repositorys (`origin`), die URL des Remote-Repositorys und die _refspec_ angegeben sind, die zum Abrufen verwendet werden soll:
 
 [source,ini]
 ----
@@ -18,11 +18,11 @@ Running the command above adds a section to your repository's `.git/config` file
 	fetch = +refs/heads/*:refs/remotes/origin/*
 ----
 
-The format of the refspec is, first, an optional `+`, followed by `<src>:<dst>`, where `<src>` is the pattern for references on the remote side and `<dst>` is where those references will be tracked locally.
-The `+` tells Git to update the reference even if it isn't a fast-forward.
+Das Format der Refspec ist zunächst ein optionales `+`, gefolgt von `<src>:<dst>`, wobei `<src>` das Muster für Referenzen auf der Remote-Seite ist. `<dst>` gibt an wo diese Referenzen lokal nachverfolgt werden.
+Das `+` weist Git an, die Referenz zu aktualisieren, auch wenn es sich nicht um einen fast-forward handelt.
 
-In the default case that is automatically written by a `git remote add origin` command, Git fetches all the references under `refs/heads/` on the server and writes them to `refs/remotes/origin/` locally.
-So, if there is a `master` branch on the server, you can access the log of that branch locally via any of the following:
+In der Standardeinstellung, die automatisch von einem `git remote add origin`-Befehl geschrieben wird, ruft Git alle Referenzen unter `refs/heads/` auf dem Server ab und schreibt sie lokal in `refs/remotes/origin/`.
+Wenn sich auf dem Server also ein `master`-Branch befindet, können Sie auf das Log dieses Branches lokal zugreifen, indem Sie eine der folgenden Aktionen ausführen:
 
 [source,console]
 ----
@@ -31,26 +31,26 @@ $ git log remotes/origin/master
 $ git log refs/remotes/origin/master
 ----
 
-They're all equivalent, because Git expands each of them to `refs/remotes/origin/master`.
+Sie sind alle gleichwertig, da Git sie zu `refs/remotes/origin/master` erweitert.
 
-If you want Git instead to pull down only the `master` branch each time, and not every other branch on the remote server, you can change the fetch line to refer to that branch only:
+Wenn Git stattdessen jedes Mal nur den `master`-Branch und nicht jeden anderen Branch auf dem Remote-Server pullen soll, können Sie die Abrufzeile so ändern, dass sie nur auf diesen Branch verweist:
 
 [source]
 ----
 fetch = +refs/heads/master:refs/remotes/origin/master
 ----
 
-This is just the default refspec for `git fetch` for that remote.
-If you want to do a one-time only fetch, you can specify the specific refspec on the command line, too.
-To pull the `master` branch on the remote down to `origin/mymaster` locally, you can run:
+Dies ist nur die Standard Refspec für `git fetch` für diesen Remote.
+Wenn Sie einen einmaligen Abruf durchführen möchten, können Sie die spezifische Refspec auch in der Befehlszeile angeben.
+Um den `master`-Branch auf dem Remote lokal nach `origin/mymaster` zu pullen, können Sie Folgendes ausführen:
 
 [source,console]
 ----
 $ git fetch origin master:refs/remotes/origin/mymaster
 ----
 
-You can also specify multiple refspecs.
-On the command line, you can pull down several branches like so:
+Sie können auch mehrere Refspecs angeben.
+In der Befehlszeile können Sie mehrere Branches wie folgt pullen:
 
 [source,console]
 ----
@@ -61,11 +61,11 @@ From [email protected]:schacon/simplegit
  * [new branch]      topic      -> origin/topic
 ----
 
-In this case, the `master` branch pull was rejected because it wasn't listed as a fast-forward reference.
-You can override that by specifying the `+` in front of the refspec.
+In diesem Fall wurde der `master`-Branch pull abgelehnt, da er nicht als Fast-Forward aufgeführt war.
+Sie können dies überschreiben, indem Sie das `+` vor der Refspec angeben.
 
-You can also specify multiple refspecs for fetching in your configuration file.
-If you want to always fetch the `master` and `experiment` branches from the `origin` remote, add two lines:
+Sie können auch mehrere Refspecs zum Abrufen in Ihrer Konfigurationsdatei angeben.
+Wenn Sie immer die Branches `master` und `experiment` vom `origin`-Remote abrufen möchten, fügen Sie zwei Zeilen hinzu:
 
 [source,ini]
 ----
@@ -75,15 +75,15 @@ If you want to always fetch the `master` and `experiment` branches from the `ori
 	fetch = +refs/heads/experiment:refs/remotes/origin/experiment
 ----
 
-You can't use partial globs in the pattern, so this would be invalid:
+Sie können keine partiellen Globs im Pattern verwenden, folgendes wäre also ungültig:
 
 [source,ini]
 ----
 fetch = +refs/heads/qa*:refs/remotes/origin/qa*
 ----
 
-However, you can use namespaces (or directories) to accomplish something like that.
-If you have a QA team that pushes a series of branches, and you want to get the `master` branch and any of the QA team's branches but nothing else, you can use a config section like this:
+Sie können jedoch Namespaces (oder Verzeichnisse) verwenden, um dies zu erreichen.
+Wenn Sie ein QS-Team haben, das eine Reihe von Branches pusht, und Sie möchten nur den `master`-Branch und einen der Branches des QS-Teams erhalten, dann können Sie einen Konfigurationsabschnitt wie diesen verwenden:
 
 [source,ini]
 ----
@@ -93,22 +93,22 @@ If you have a QA team that pushes a series of branches, and you want to get the
 	fetch = +refs/heads/qa/*:refs/remotes/origin/qa/*
 ----
 
-If you have a complex workflow process that has a QA team pushing branches, developers pushing branches, and integration teams pushing and collaborating on remote branches, you can namespace them easily this way.
+Wenn Sie über einen komplexen Workflow-Prozess verfügen, bei dem QS-Team und Entwickler Branches pushen und Integrationsteams auf Remotebranches pushen bzw. daran zusammenarbeiten, können Sie sie auf diese Weise problemlos mit Namespaces versehen.
 
 [[_pushing_refspecs]]
-==== Pushing Refspecs
+==== Pushende Refspecs
 
-It's nice that you can fetch namespaced references that way, but how does the QA team get their branches into a `qa/` namespace in the first place?
-You accomplish that by using refspecs to push.
+Es ist schön, dass Sie auf diese Weise Referenzen mit Namespaces abrufen können, aber wie bringt das QS-Team seine Branches überhaupt an die erste Stelle eines `qa/`-Namespace?
+Sie erreichen dies, indem Sie Refspecs zum Pushen verwenden.
 
-If the QA team wants to push their `master` branch to `qa/master` on the remote server, they can run
+Wenn das QS-Team seinen `master`-Branch auf `qa/master` auf dem Remote-Server verschieben möchte, kann folgendes ausgeführt werden:
 
 [source,console]
 ----
 $ git push origin master:refs/heads/qa/master
 ----
 
-If they want Git to do that automatically each time they run `git push origin`, they can add a `push` value to their config file:
+Wenn Git dies bei jedem Start von `git push origin` automatisch ausführen soll, können sie ihrer Konfigurationsdatei einen `push`-Wert hinzufügen:
 
 [source,ini]
 ----
@@ -118,26 +118,26 @@ If they want Git to do that automatically each time they run `git push origin`,
 	push = refs/heads/master:refs/heads/qa/master
 ----
 
-Again, this will cause a `git push origin` to push the local `master` branch to the remote `qa/master` branch by default.
+Dies wird wiederum dazu führen, dass ein `git push origin` den lokalen `master`-Branch standardmäßig zum remote `qa/master`-Branch pusht.
 
 [NOTE]
 ====
-You cannot use the refspec to fetch from one repository and push to another one.
-For an example to do so, refer to <<ch06-github#_fetch_and_push_on_different_repositories>>.
+Sie können die Refspec nicht zum Abrufen von einem Repository und zum Verschieben auf ein anderes Repository verwenden.
+Ein Beispiel wie das geht finden Sie unter <<ch06-github#_fetch_and_push_on_different_repositories>>.
 ====
 
-==== Deleting References
+==== Löschende Referenzen
 
-You can also use the refspec to delete references from the remote server by running something like this:
+Sie können mit Refspec auch Verweise vom Remote-Server löschen, indem Sie Folgendes ausführen:
 
 [source,console]
 ----
 $ git push origin :topic
 ----
 
-Because the refspec is `<src>:<dst>`, by leaving off the `<src>` part, this basically says to make the `topic` branch on the remote nothing, which deletes it.
+Die Syntax der Refspezifikation lautet `<src>:<dst>`. Das Weglassen des `<src>`  Teils bedeutet, im Grunde genommen, dass der `topic` Branch auf dem Remote leer bleibt, wodurch er gelöscht wird.
 
-Or you can use the newer syntax (available since Git v1.7.0):
+Oder Sie können die neuere Syntax verwenden (verfügbar seit Git v1.7.0):
 
 [source,console]
 ----

status.json

@@ -104,7 +104,7 @@
       "sections/packfiles.asc": 100,
       "sections/plumbing-porcelain.asc": 100,
       "sections/refs.asc": 100,
-      "sections/refspec.asc": 0,
+      "sections/refspec.asc": 100,
       "sections/transfer-protocols.asc": 0
     },
     "A-git-in-other-environments": {