Permalink
Browse files

proofread finished

  • Loading branch information...
Mechtilde committed Jan 4, 2015
1 parent dd466c9 commit d0afd83f80675872332c3fdad59384a720e9672c
Showing with 50 additions and 48 deletions.
  1. +13 −13 de/drawbacks.txt
  2. +5 −5 de/grandmaster.txt
  3. +1 −1 de/history.txt
  4. +6 −6 de/multiplayer.txt
  5. +19 −17 de/secrets.txt
  6. +6 −6 de/translate.txt
View
@@ -9,9 +9,9 @@ noch besser, anpacken und mithelfen.
=== SHA1 Schwäche ===
Mit der Zeit entdecken Kryptographen immer mehr Schwächen an SHA1. Schon
heute wäre es technisch machbar für finanzkräftige Unternehmen
heute wäre für finanzkräftige Unternehmen es technisch machbar,
Hash-Kollisionen zu finden. In ein paar Jahren hat vielleicht schon ein ganz
normaler Heim-PC ausreichend Rechenleistung um ein Git 'Reopsitory'
normaler Heim-PC ausreichend Rechenleistung, um ein Git 'Reopsitory'
unbemerkt zu korrumpieren.
Hoffentlich stellt Git auf eine bessere Hash Funktion um, bevor die
@@ -43,7 +43,7 @@ willst.
=== Wer macht was? ===
Einige Versionsverwaltungssysteme zwingen Dich explizit eine Datei auf
Einige Versionsverwaltungssysteme zwingen Dich explizit, eine Datei auf
irgendeine Weise für die Bearbeitung zu kennzeichnen. Obwohl es extrem
lästig ist, wenn es die Kommunikation mit einem zentralen Server erfordert,
so hat es doch zwei Vorteile:
@@ -63,11 +63,11 @@ aufrufen, wenn sie eine Datei bearbeiten.
Da Git die Änderungen über das gesamte Projekt aufzeichnet, erfordert die
Rekonstruktion des Verlaufs einer einzelnen Datei mehr Aufwand als in
Versionsverwaltungssystemen die einzelne Dateien überwachen.
Versionsverwaltungssystemen, die einzelne Dateien überwachen.
Die Nachteile sind üblicherweise gering und werden gern in Kauf genommen, da
andere Operationen dafür unglaublich effizient sind. Zum Beispiel ist `git
checkout` schneller als `cp -a` und projektweite Unterschiede sind besser zu
checkout` schneller als `cp -a`, und projektweite Unterschiede sind besser zu
komprimieren als eine Sammlung von Änderungen auf Dateibasis.
=== Der erster Klon ===
@@ -77,7 +77,7 @@ Versionsverwaltungssystemen, wenn ein längerer Verlauf existiert.
Der initiale Aufwand lohnt sich aber auf längere Sicht, da die meisten
zukünftigen Operationen dann schnell und offline erfolgen. Trotzdem gibt es
Situationen, in denen es besser ist einen oberflächlichen Klon mit der
Situationen, in denen es besser ist, einen oberflächlichen Klon mit der
`--depth` Option zu erstellen. Das geht wesentlich schneller, aber der
resultierende Klon hat nur eingeschränkte Funktionalität.
@@ -104,11 +104,11 @@ gesucht, nicht ein Versionsverwaltungssystem. Ein Versionsverwaltungssystem
zum Beispiel ist eine ungeeignete Lösung um Fotos zu verwalten, die
periodisch von einer Webcam gemacht werden.
Wenn die Dateien sich tatsächlich konstant verändern und sie wirklich
versioniert werden müssen, ist es eine Möglichkeit Git in zentralisierter
Wenn die Dateien sich tatsächlich konstant verändern, und sie wirklich
versioniert werden müssen, ist es eine Möglichkeit, Git in zentralisierter
Form zu verwenden. Jeder kann oberflächliche Klone erstellen, die nur wenig
oder gar nichts vom Verlauf des Projekts enthalten. Natürlich sind dann
viele Git Funktionen nicht verfügbar und Änderungen müssen als 'Patches'
viele Git Funktionen nicht verfügbar, und Änderungen müssen als 'Patches'
übermittelt werden. Das funktioniert wahrscheinlich ganz gut, wenn auch
unklar ist, warum jemand die Versionsgeschichte von wahnsinnig instabilen
Dateien braucht.
@@ -121,7 +121,7 @@ unnötig auf.
In diesem Fall sollte der Quellcode der Firmware in einem Git 'Repository'
gehalten werden und die Binärdatei außerhalb des Projekts. Um das Leben zu
vereinfachen, könnte jemand ein Skript erstellen, das Git benutzt um den
vereinfachen, könnte jemand ein Skript erstellen, das Git benutzt, um den
Quellcode zu klonen und 'rsync' oder einen oberflächlichen Klon für die
Firmware.
@@ -143,7 +143,7 @@ alle relevant.
=== Leere Unterverzeichnisse ===
Leere Unterverzeichnisse können nicht überwacht werden. Erstelle eine
Dummy-Datei um dieses Problem zu umgehen.
Dummy-Datei, um dieses Problem zu umgehen.
Die aktuelle Implementierung von Git, weniger sein Design, ist
verantwortlich für diesen Pferdefuß. Mit etwas Glück, wenn Git's Verbreitung
@@ -165,8 +165,8 @@ dem Erstellen eines 'Repository' wird der 'HEAD' auf eine Zeichenfolge von
'Repositories'.
Würde dann zum Beispiel *git log* ausgeführt, würde der Anwender darüber
informiert, daß noch keine 'Commits' gemacht wurden, anstelle mit einem
fatalen Fehler zu beenden. Das gilt stellvertretenden für andere
informiert, dass noch keine 'Commits' gemacht wurden, anstelle mit einem
fatalen Fehler zu beenden. Das gilt stellvertretend für andere
Anweisungen.
Jeder initiale 'Commit' ist dann stillschweigend ein Abkömmling dieses
View
@@ -123,11 +123,11 @@ ORIG_HEAD und Du kannst gesund und munter zurückkehren mit:
=== KOPF-Jagd ===
Möglicherweise reicht ORIG_HEAD nicht aus. Vielleicht hast Du gerade
bemerkt, dass Du einen kapitalen Fehler gemacht hast und nun musst Du zu
bemerkt, dass Du einen kapitalen Fehler gemacht hast, und nun musst Du zu
einem uralten 'Commit' in einem länst vergessenen 'Branch' zurück.
Standardmäßig behält Git einen 'Commit' für mindesten zwei Wochen, sogar
wenn Du Git anweist den 'Branch' zu zerstören, in dem er enthalten ist. Das
wenn Du Git anweist, den 'Branch' zu zerstören, in dem er enthalten ist. Das
Problem ist, den entsprechenden SHA1-Wert zu finden. Du kannst Dir alle
SHA1-Werte in `.git/objects` vornehmen und ausprobieren ob Du den gesuchten
'Commit' findest. Aber es gibt einen viel einfacheren Weg.
@@ -181,7 +181,7 @@ sind nur winzige Skripte, wie Zwerge auf den Schultern von Riesen. Mit ein
bisschen Handarbeit kannst Du Git anpassen, damit es Deinen Anforderungen
entspricht.
Ein einfacher Trick ist es, die in Git integrierte Aliasfunktion zu verwenden
Ein einfacher Trick ist es, die in Git integrierte Aliasfunktion zu verwenden,
um die am häufigsten benutzten Anweisungen zu verkürzen:
$ git config --global alias.co checkout
@@ -211,7 +211,7 @@ Versionsgeschichte mit dem original 'Repository' teilt:
$ git-new-workdir ein/existierendes/repo neues/verzeichnis
Das neue Verzeichnis und die Dateien darin kann man sich als 'Clone'
vorstellen, mit dem Unterschied, dass durch die gemeinschaftliche
vorstellen mit dem Unterschied, dass durch die gemeinschaftliche
Versionsgeschichte die beiden Versionen automatisch synchron bleiben. Eine
Synchronisierung mittels 'merge', 'push' oder 'pull' ist nicht notwendig.
@@ -226,7 +226,7 @@ häufigsten Anweisungen umgehen.
$ git checkout -f HEAD^
Auf der anderen Seite, wenn Du einen speziellen Pfad für 'checkout' angibst,
gibt es keinen Sicherheitsüberprüfungen mehr. Der angegebene Pfad wird
gibt es keine Sicherheitsüberprüfungen mehr. Der angegebene Pfad wird
stillschweigend überschrieben. Sei vorsichtig, wenn Du 'checkout' auf diese
Weise benutzt.
View
@@ -254,7 +254,7 @@ zu benutzen. Eine unzuverlässige Internetverbindung stört mit Git nicht
sehr, aber sie macht die Entwicklung unerträglich, wenn sie so zuverlässig
wie ein lokale Festplatte sein sollte. Zusätzlich habe ich mich dabei
ertappt, bestimmte Anweisungen zu vermeiden, um die damit verbundenen
Wartezeiten zu vermeiden und das hat mich letztendlich davon abgehalten,
Wartezeiten zu vermeiden, und das hat mich letztendlich davon abgehalten,
meinem gewohnten Arbeitsablauf zu folgen.
Wenn ich eine langsame Anweisung auszuführen hatte, wurde durch die
View
@@ -56,7 +56,7 @@ Willst Du 'Repositories' ohne Server synchronisieren oder gar ohne
Netzwerkverbindung? Musst Du während eines Notfalls improvisieren? Wir haben
gesehen, dass man mit <<makinghistory, *git fast-export* und *git
fast-import* 'Repositories' in eine einzige Datei konvertieren kann und
zurück>>. Wir können solche Dateien hin und her schicken um Git
zurück>>. Wir können solche Dateien hin und her schicken, um Git
'Repositories' über jedes beliebige Medium zu transportieren, aber ein
effizienteres Werkzeug ist *git bundle*.
@@ -82,7 +82,7 @@ haben:
$ git bundle create einedatei HEAD ^1b6d
Macht man das regelmäßig, kann man leicht vergessen, welcher 'Commit'
zuletzt gesendet wurde. Die Hilfeseiten schlagen vor 'Tags' zu benutzen, um
zuletzt gesendet wurde. Die Hilfeseiten schlagen vor, 'Tags' zu benutzen, um
dieses Problem zu lösen. Das heißt, nachdem Du ein 'Bundle' gesendet hast,
gib ein:
@@ -153,18 +153,18 @@ Blick riskieren:
Die +remote.origin.url+ Option kontrolliert die Quell-URL; ``origin'' ist
der Spitzname, der dem Quell-'Repository' gegeben wurde. Wie mit der
``master'' 'Branch' Konvention können wir diesen Spitznamen ändern oder
löschen, aber es gibt für gewöhnlich keinen Grund dies, zu tun.
löschen, aber es gibt für gewöhnlich keinen Grund, dies zu tun.
Wenn das original 'Repository' verschoben wird, können wir die URL
aktualisieren mit:
$ git config remote.origin.url git://neue.url/proj.git
Die +branch.master.merge+ Option definiert den Standard-Remote-'Branch' bei
einem *git pull*. Während dem ursprünglichen 'clonen' wird sie auf den
einem *git pull*. Während des ursprünglichen 'Clonen' wird sie auf den
aktuellen 'Branch' des Quell-'Repository' gesetzt, so dass selbst dann, wenn
der 'HEAD' des Quell-'Repository' inzwischen auf einen anderen 'Branch'
gewechselt hat, ein späterer 'pull' wird treu dem original 'Branch' folgen.
gewechselt hat, ein späterer 'pull' treu dem original 'Branch' folgen wird.
Diese Option gilt nur für das 'Repository', von dem als erstes 'gecloned'
wurde, was in der Option +branch.master.remote+ hinterlegt ist. Bei einem
@@ -181,7 +181,7 @@ Beispielen keine Argumente hatten.
Wenn Du ein 'Repository' 'clonst', 'clonst' Du auch alle seine
'Branches'. Das hast Du vielleicht noch nicht bemerkt, denn Git versteckt
diese: Du musst speziell danach fragen. Das verhindert, dass 'Branches' vom
entfernten 'Repository' Deine lokalen 'Branches' stören und es macht Git
entfernten 'Repository' Deine lokalen 'Branches' stören, und es macht Git
einfacher für Anfänger.
Zeige die entfernten 'Branches' an mit:
View
@@ -13,8 +13,8 @@ Wie kann Git so unauffällig sein? Abgesehen von gelegentlichen 'Commits' und
existieren. Das heißt, bis Du sie brauchst. Und das ist, wenn Du froh bist,
dass Git die ganze Zeit über Dich gewacht hat.
Andere Versionsverwaltungssysteme zwingen Dich ständig Dich mit
Verwaltungskram und Bürokratie herumzuschlagen. Dateien sind können
Andere Versionsverwaltungssysteme zwingen Dich ständig, Dich mit
Verwaltungskram und Bürokratie herumzuschlagen. Dateien können
schreibgeschützt sein, bis Du einem zentralen Server mitteilst, welche
Dateien Du gerne bearbeiten möchtest. Die einfachsten Befehle werden bis zum
Schneckentempo verlangsamt, wenn die Anzahl der Anwender steigt. Deine
@@ -31,7 +31,7 @@ Stand aus `.git` wiederherstellen.
=== Integrität ===
Die meisten Leute verbinden mit Kryptographie die Geheimhaltung von
Informationen, aber ein genau so wichtiges Ziel ist es Informationen zu
Informationen, aber ein genau so wichtiges Ziel ist es, Informationen zu
sichern. Die richtige Anwendung von kryptographischen Hash-Funktionen kann
einen versehentlichen oder bösartigen Datenverlust verhindern.
@@ -94,19 +94,19 @@ Historiker.
=== Die Objektdatenbank ===
Jegliche Version Deiner Daten wird in der Objektdatenbank gehalten, welche
Jegliche Versionen Deiner Daten wird in der Objektdatenbank gehalten, welche
im Unterverzeichnis `.git/objects` liegt; Die anderen Orte in `.git/`
enthalten weniger wichtige Daten: den Index, 'Branch' Namen, Bezeichner
('tags'), Konfigurationsoptionen, Logdateien, die Position des aktuellen
'HEAD Commit' und so weiter. Die Objektdatenbank ist einfach aber trotzdem
elegant und sie ist die Quelle von Git's Macht.
elegant, und sie ist die Quelle von Git's Macht.
Jede Datei in `.git/objects` ist ein 'Objekt'. Es gibt drei Arten von
Objekten die uns betreffen: 'Blob'-, 'Tree'-, und 'Commit'-Objekte.
Objekten, die uns betreffen: 'Blob'-, 'Tree'- und 'Commit'-Objekte.
=== Blobs ===
Zuerst ein Zaubertrick. Suche Dir einen Dateinamen aus, irgendeinen. In
Zuerst ein Zaubertrick. Suche Dir irgendeinen Dateinamen aus. In
einem leeren Verzeichnis:
$ echo sweet > DEIN_DATEINAME
@@ -123,11 +123,13 @@ SHA1-Hash-Wert von:
"blob" SP "6" NUL "sweet" LF
aa823728ea7d592acc69b36875a482cdf3fd5c8d ist. Wobei SP ein Leerzeichen ist,
NUL ist ein Nullbyte und LF ist ein Zeilenumbruch. Das kannst Du
kontrollieren, durch die Eingabe von:
NUL ist ein Nullbyte und LF ist ein Zeilenumbruch. Das kannst Du durch die
Eingabe von
$ printf "blob 6\000sweet\n" | sha1sum
kontrollieren.
Git ist 'assoziativ': Dateien werden nicht nach Ihren Namen gespeichert,
sondern eher nach dem SHA1-Hash-Wert der Daten, welche sie enthalten, in
einer Datei, die wir als 'Blob'-Objekt bezeichnen. Wir können uns den
@@ -157,7 +159,7 @@ was Dir das Objekt im Klartext anzeigt.
=== 'Trees' ===
Aber wo sind die Dateinamen? Sie müssen irgendwo gespeichert sein. Git kommt
beim 'Commit' dazu sich um die Dateinamen zu kümmern:
beim 'Commit' dazu, sich um die Dateinamen zu kümmern:
$ git commit # Schreibe eine Bemerkung.
$ find .git/objects -type f
@@ -166,7 +168,7 @@ Du solltest nun drei Objekte sehen. Dieses mal kann ich Dir nicht sagen, wie
die zwei neuen Dateien heißen, weil es zum Teil vom gewählten Dateiname
abhängt, den Du ausgesucht hast. Fahren wir fort mit der Annahme, Du hast
eine Datei ``rose'' genannt. Wenn nicht, kannst Du den Verlauf so
umschreiben, dass es so aussieht als hättest Du es:
umschreiben, dass es so aussieht, als hättest Du es:
$ git filter-branch --tree-filter 'mv DEIN_DATEINAME rose'
$ find .git/objects -type f
@@ -182,7 +184,7 @@ Eingabe von:
$ echo 05b217bb859794d08bb9e4f7f04cbda4b207fbe9 | git cat-file --batch
Mit zpipe, ist es einfach den SHA1-Hash-Wert zu prüfen:
Mit zpipe ist es einfach, den SHA1-Hash-Wert zu prüfen:
$ zpipe -d < .git/objects/05/b217bb859794d08bb9e4f7f04cbda4b207fbe9 | sha1sum
@@ -191,7 +193,7 @@ Ausgabe mehr als die rohe unkomprimierte Objektdatei enthält.
Diese Datei ist ein 'Tree'-Objekt: eine Liste von Datensätzen, bestehend aus
dem Dateityp, dem Dateinamen und einem SHA1-Hash-Wert. In unserem Beispiel
ist der Dateityp 100644, was bedeutet, dass `rose` eine normale Datei ist
ist der Dateityp 100644, was bedeutet, dass `rose` eine normale Datei ist,
und der SHA1-Hash-Wert entspricht dem 'Blob'-Objekt, welches den Inhalt von
`rose` enthält. Andere mögliche Dateitypen sind ausführbare Programmdateien,
symbolische Links oder Verzeichnisse. Im letzten Fall zeigt der
@@ -241,7 +243,7 @@ finden, was dem SHA1-Hash-Wert seines Inhalts entspricht:
LF
"Shakespeare" LF
Wie vorhin, kannst Du 'zpipe' oder 'cat-file' benutzen um es für Dich zu
Wie vorhin kannst Du 'zpipe' oder 'cat-file' benutzen, um es für Dich zu
überprüfen.
Das ist der erste 'Commit' gewesen, deshalb gibt es keine
@@ -250,14 +252,14 @@ enthalten, die den Eltern-'Commit' identifiziert.
=== Von Magie nicht zu unterscheiden ===
Git's Geheimnisse scheinen zu einfach. Es sieht so aus als müsste man nur
Git's Geheimnisse scheinen zu einfach. Es sieht so aus, als müsste man nur
ein paar Kommandozeilenskripte zusammenmixen, einen Schuß C-Code hinzufügen
und innerhalb ein paar Stunden ist man fertig: eine Mischung von
grundlegenden Dateisystemoperationen und SHA1-Hash-Berechnungen, garniert
mit Sperrdateien und Synchronisation für Stabilität. Tatsächlich beschreibt
dies die früheste Version von Git. Nichtsdestotrotz, abgesehen von
geschickten Verpackungstricks um Speicherplatz zu sparen und geschickten
Indizierungstricks um Zeit zu sparen, wissen wir nun, wie Git gewandt ein
geschickten Verpackungstricks, um Speicherplatz zu sparen, und geschickten
Indizierungstricks, um Zeit zu sparen, wissen wir nun, wie Git gewandt ein
Dateisystem in eine Datenbank verwandelt, das perfekt für eine
Versionsverwaltung geeignet ist.
View
@@ -1,6 +1,6 @@
== Anhang B: Diese Anleitung übersetzen ==
Ich empfehle folgende Schritte um diese Anleitung zu übersetzen, damit meine
Ich empfehle folgende Schritte, um diese Anleitung zu übersetzen, damit meine
Skripte einfach eine HTML- und PDF-Version erstellen können. Außerdem können
so alle Übersetzungen in einem 'Repository' existieren.
@@ -13,7 +13,7 @@ das neue Verzeichnis und übersetze diese.
Um zum Beispiel die Anleitung auf
http://de.wikipedia.org/wiki/Klingonische_Sprache[Klingonisch] zu
übersetzen, mußt du folgendes machen:
übersetzen, musst du folgendes machen:
$ git clone git://repo.or.cz/gitmagic.git
$ cd gitmagic
@@ -30,7 +30,7 @@ hinzu. Nun kannst Du Deine Arbeit jederzeit wie folgt überprüfen:
$ make tlh
$ firefox book-tlh/index.html
'Committe' deine Änderungen oft und wenn du fertig bist, gib bitte
Bescheid. GitHub hat eine Schnittstelle, die das erleichtert: Erzeuge deine
eigene 'Fork' vom "gitmagic" Projekt, 'pushe' deine Änderungen, dann gib mir
Bescheid, deine Änderungen zu 'mergen'.
'Committe' Deine Änderungen oft, und wenn Du fertig bist, gib bitte
Bescheid. GitHub hat eine Schnittstelle, die das erleichtert: Erzeuge Deinen
eigene 'Fork' vom "gitmagic" Projekt, 'pushe' Deine Änderungen, dann gib mir
Bescheid, Deine Änderungen zu 'mergen'.

0 comments on commit d0afd83

Please sign in to comment.