completed german translation

de/branch.txt

@@ -107,22 +107,13 @@ einen neu entdeckten Fehler in 'Commit' `1b6d...` zu beheben:
 Dann, wenn du den Fehler behoben hast:
 
  $ git commit -a -m "Fehler behoben"
- $ git push  # ins zentrale 'Repository'
  $ git checkout master
 
-und fahre mit deiner ursprünglichen Arbeit fort.
-
-Du kannst die Fehlerbehebung, die du gerade gemacht hast, auch
-'mergen'. Entweder durch:
+und fahre mit deiner ursprünglichen Arbeit fort. Du kannst sogar die frisch
+gebackene Fehlerkorrektur auf Deinen aktuellen Stand übernehmen:
 
  $ git merge fixes
 
-oder:
-
- $ git pull
-
-da du die Fehlerbehebung schon ins zentrale 'Repository' ge'pushed' hast.
-
 === 'Mergen' ===
 
 Mit einigen Versionsverwaltungssystemen ist das Erstellen eines 'Branch'
@@ -205,7 +196,7 @@ Schließlich, Teil I ist zugelassen:
  $ git checkout master  # Gehe zurück zu Teil I.
  $ submit files         # Veröffentliche deine Dateien!
  $ git merge teil2      # 'Merge' in Teil II.
- $ git branch -d teil2
+ $ git branch -d teil2  # Lösche den Branch "teil2"
 
 Nun bist du wieder im `master` 'Branch', mit Teil II im Arbeitsverzeichnis.
 
@@ -214,12 +205,16 @@ erweitern. Es ist genauso einfach rückwirkend zu 'branchen': angenommen, du
 merkst zu spät, dass vor sieben 'Commits' ein 'Branch' erforderlich gewesen
 wäre. Dann tippe:
 
- $ git branch -m master teil2
- $  # Umbenennen des 'Branch' "master" zu "teil2".
- $ git checkout HEAD~7 -b master
+ $ git branch -m master teil2  # Umbenennen des 'Branch' "master" zu "teil2".
+ $ git branch master HEAD~7    # Erstelle neuen "master", 7 Commits voraus
+
+Der `master` Branch enthält nun Teil I, und der `teil2` Branch enthält den
+Rest. Wir befinden uns in letzterem Branch; wir haben `master` erzeugt ohne
+dorthin zu wechseln, denn wir wollen im `teil2` weiterarbeiten. Das ist
+unüblich. Bisher haben wir unmittelbar nach dem Erstellen in einen 'Branch'
+gewechselt, wie in:
 
-Der `master` 'Branch' enthält nun nur den Teil I und der `teil2` 'Branch'
-enthält den Rest.
+ $ git checkout HEAD~7 -b master  # erzeuge einen Branch, und wechsle zu ihm.
 
 === Mischmasch Reorganisieren ===
 
@@ -228,8 +223,8 @@ abzuarbeiten. Du willst deine laufenden Arbeiten für dich behalten und
 andere sollen deine 'Commits' nur sehen, wenn du sie hübsch organisiert
 hast. Beginne ein paar 'Branches':
 
-  $ git checkout -b bereinigt
-  $ git checkout -b mischmasch
+  $ git branch sauber           # Erzeuge einen Branch für gesäuberte Commits.
+  $ git checkout -b mischmasch  # Erzeuge und wechsle in den Branch zum Arbeiten.
 
 Fahre fort alles zu bearbeiten: Behebe Fehler, füge Funktionen hinzu,
 erstelle temporären Code und so weiter und 'commite' deine Änderungen

de/clone.txt

@@ -47,7 +47,7 @@ Ordner:
  $ mkdir proj.git
  $ cd proj.git
  $ git init --bare
- $  # einzeilige Variante: GIT_DIR=proj.git git init
+ $ touch proj.git/git-daemon-export-ok
 
 Wenn nötig, starte den Git-Dämon:
 
@@ -59,11 +59,11 @@ Website aus.
 
 Übertrage ('push') dein Projekt auf den zentralen Server mit:
 
- $ git push git://zentraler.server/pfad/zu/proj.git HEAD
+ $ git push zentraler.server/pfad/zu/proj.git HEAD
 
 Um die Quellcodes abzurufen gibt ein Entwickler folgendes ein:
 
- $ git clone git://zentraler.server/pfad/zu/proj.git
+ $ git clone zentraler.server/pfad/zu/proj.git
 
 Nach dem Bearbeiten sichert der Entwickler die Änderungen lokal:
 
@@ -87,6 +87,25 @@ eingegangen sind, schlägt dein 'push' fehl. Aktualisiere das lokale
 'Repository' erneut mit 'pull', löse eventuell aufgetretene
 'Merge'-Konflikte und versuche es nochmal.
 
+Entwickler brauchen SSH Zugriff für die vorherigen 'pull' und 'push'
+Anweisungen. Trotzdem kann jedermann die Quelltexte einsehen, durch Eingabe
+von:
+
+ $ git clone git://zentraler.server/pfad/zu/proj.git
+
+Das ursprüngliche Git-Protokoll ähnelt HTTP: Es gibt keine
+Authentifizierung, also kann jeder das Projekt abrufen. Folglich ist
+standardmäßig das 'Pushen' per Git-Protokoll verboten.
+
+=== Geheime Quellen ===
+
+Für ein Closed-Source-Projekt lasse die 'touch' Anweisung weg und stelle
+sicher, dass niemals eine Datei namens `git-daemon-export-ok` erstellt
+wird. Das 'Repository' kann nun nicht mehr über das Git-Protokol abgerufen
+werden; nur diejenigen mit SSH Zugriff können es einsehen. Wenn alle
+'Repositories' geschlossen sind, ist es unnötig den Git Dämon laufen zu
+lassen, da jegliche Kommunikation über SSH läuft.
+
 === 'Nackte Repositories' ===
 
 Ein nacktes ('bare') 'Repository' wird so genannt, weil es kein
@@ -166,13 +185,14 @@ Nehmen wir an du willst parallel an mehreren Funktionen arbeiten. Dann
 
  $ git clone . /irgendein/neuer/ordner
 
-Wann immer es sicher ist nutzt Git Verknüpfungen und Dateifreigaben um
-diesen 'Clone' zu erzeugen, deshalb wird es blitzartig fertig sein und du
-kannst nun an zwei unabhängigen Funktionen arbeiten. Zum Beispiel kannst du
-im einen 'Clone' editieren, während der andere übersetzt wird.
+http://de.wikipedia.org/wiki/Harter_Link[Harten Links] ist es zu verdanken,
+dass ein lokaler Klon weniger Zeit und Speicherplatz benötigt als eine
+herkömmliche Datensicherung.
 
-Zu jeder Zeit kannst du 'commiten' und die Änderungen vom anderen 'Clone'
-mit 'pull' übernehmen.
+Du kannst nun an zwei unabhängigen Funktionen gleichzeitig arbeiten. Zum
+Beispiel kannst Du einen Klon bearbeiten, während der andere kompiliert
+wird. Zu jeder Zeit kannst Du 'comitten' und die Änderungen des anderen Klon
+'pullen'.
 
  $ git pull /der/andere/clone HEAD
 

de/drawbacks.txt

@@ -0,0 +1,183 @@
+== Anhang A: Git's Mängel ==
+
+Ein paar Git-Probleme habe ich bisher unter den Teppich gekehrt. Einige
+lassen sich einfach mit Skripten und 'Hooks' lösen, andere erfordern eine
+Reorganisation oder Neudefinition des gesamten Projekt und für die wenigen
+verbleibenden Beeinträchtigungen kannst Du nur auf eine Lösung warten. Oder
+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
+Hash-Kollisionen zu finden. In ein paar Jahren hat vielleicht schon ein ganz
+normaler Heim-PC ausreichend Rechenleistung um ein Git 'Reopsitory'
+unbemerkt zu korrumpieren.
+
+Hoffentlich stellt Git auf eine bessere Hash Funktion um, bevor die
+Forschung SHA1 komplett unnütz macht.
+
+=== Microsoft Windows ===
+
+Git unter Microsoft Windows kann frustrierend sein:
+
+- http://cygwin.com/[Cygwin], eine Linux ähnliche Umgebung für Windows,
+enthält http://cygwin.com/packages/git/[eine Windows Portierung von Git].
+
+- http://code.google.com/p/msysgit/[Git unter MSys] ist eine Alternative,
+die sehr wenig Laufzeitunterstützung erfordert, jedoch bedürfen einige
+Kommandos noch einer Überarbeitung.
+
+=== Dateien ohne Bezug ===
+
+Wenn Dein Projekt sehr groß ist und viele Dateien enthält, die in keinem
+direkten Bezug stehen, trotzdem aber häufig geändert werden, kann Git
+nachteiliger sein als andere Systeme, weil es keine einzelnen Dateien
+überwacht. Git überwacht immer das ganze Projekt, was normalerweise schon
+von Vorteil ist.
+
+Eine Lösung ist es, Dein Projekt in kleinere Stücke aufzuteilen, von denen
+jedes nur die in Beziehung stehenden Dateien enthält. Benutze *git
+submodule* wenn Du trotzdem alles in einem einzigen 'Repository' halten
+willst.
+
+=== Wer macht was? ===
+
+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:
+
+  1. Unterschiede sind schnell gefunden, weil nur die markierten Dateien
+     untersucht werden müssen.
+
+  2. Jeder kann herausfinden wer sonst gerade an einer Datei arbeitet, indem
+     er beim zentralen Server anfragt, wer die Datei zum Bearbeiten markiert
+     hat.
+
+Mit geeigneten Skripten kannst Du das auch mit Git hinkriegen. Das erfordert
+aber die Mitarbeit der Programmierer, denn sie müssen die Skripte auch
+aufrufen, wenn sie eine Datei bearbeiten.
+
+=== Dateihistorie ===
+
+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.
+
+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
+komprimieren als eine Sammlung von Änderungen auf Dateibasis.
+
+=== Der erster Klon ===
+
+Einen Klon zu erstellen ist aufwendiger als in anderen
+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
+`--depth` Option zu erstellen. Das geht wesentlich schneller, aber der
+resultierende Klon hat nur eingeschränkte Funktionalität.
+
+=== Unbeständige Projekte ===
+
+Git wurde geschrieben um schnell zu sein, im Hinblick auf die Größe der
+Änderungen. Leute machen kleine Änderungen von Version zu Version. Ein
+einzeiliger Bugfix hier, eine neue Funktion da, verbesserte Kommentare und
+so weiter. Aber wenn sich Deine Dateien zwischen aufeinanderfolgenden
+Versionen gravierend ändern, dann wird zwangsläufig mit jedem 'Commit' Dein
+Verlauf um die Größe des gesamten Projekts wachsen. 
+
+Es gibt nichts, was irgendein Versionsverwaltungssystem dagegen machen kann,
+aber der Standard Git Anwender leidet mehr darunter, weil normalerweise der
+ganze Verlauf geklont wird.
+
+Die Ursachen für die großen Unterschiede sollten ermittelt
+werden. Vielleicht können Dateiformate geändert werden. Kleinere
+Bearbeitungen sollten auch nur minimale Änderungen an so wenig Dateien wie
+möglich bewirken.
+
+Vielleicht ist eher eine Datenbank oder Sicherungs-/Archivierungslösung
+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
+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'
+übermittelt werden. Das funktioniert wahrscheinlich ganz gut, wenn auch
+unklar ist, warum jemand die Versionsgeschichte von wahnsinnig instabilen
+Dateien braucht.
+
+Ein anderes Beispiel ist ein Projekt, das von Firmware abhängig ist, welche
+die Form einer großen Binärdatei annimmt. Der Verlauf der Firmware
+interessiert den Anwender nicht und Änderungen lassen sich schlecht
+komprimieren, so blähen Firmwarerevisionen die Größe des 'Repository'
+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
+Quellcode zu klonen und 'rsync' oder einen oberflächlichen Klon für die
+Firmware.
+
+=== Globaler Zähler ===
+
+Verschiedene Versionsverwaltungssysteme unterhalten einen Zähler, der mit
+jedem 'Commit' erhöht wird. Git referenziert Änderungen anhand ihres
+SHA1-Hash, was in vielen Fällen besser ist.
+
+Aber einige Leute sind diesen Zähler gewöhnt. Zum Glück ist es einfach,
+Skripte zu schreiben, sodass  mit jedem Update das zentrale Git 'Repository'
+einen Zähler erhöht. Vielleicht in Form eines 'Tags', der mit dem SHA1-Hash
+des letzten 'Commit' verknüpft ist.
+
+Jeder Klon könnte einen solchen Zähler bereitstellen, aber der wäre
+vermutlich nutzlos, denn nur der Zähler des zentralen 'Repository' ist für
+alle relevant.
+
+=== Leere Unterverzeichnisse ===
+
+Leere Unterverzeichnisse können nicht überwacht werden. Erstelle eine
+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
+zunimmt und mehr Anwender nach dieser Funktion verlangen, wird sie
+vielleicht implementiert.
+
+=== Initialer 'Commit' ===
+
+Ein klischeehafter Computerwissenschaftler zählt von 0 statt von 1. Leider,
+bezogen auf 'Commits', hält sich Git nicht an diese Konvention. Viele
+Kommandos sind mürrisch vor dem intialen 'Commit'. Zusätzlich müssen
+verschiedene Grenzfälle speziell behandelt werden, wie der 'Rebase' eines
+'Branch' mit einem abweichenden initialen 'Commit'.
+
+Git würde davon provitieren, einen Null-'Commit' zu definieren: sofort nach
+dem Erstellen eines 'Repository' wird der 'HEAD' auf eine Zeichenfolge von
+20 Null-Bytes gesetzt. Dieser spezielle 'Commit' repräsentiert einen leeren
+'Tree', ohne Eltern, irgendwann vielleicht der Vorfahr aller Git
+'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
+Anweisungen.
+
+Jeder initiale 'Commit' ist dann stillschweigend ein Abkömmling dieses
+Null-'Commits'.
+
+Leider gibt es noch ein paar Problemfälle. Wenn mehrere 'Branches' mit
+unterschiedlichen initialen 'Commits' zusammengeführt und dann ein 'Rebase'
+gemacht wird, ist ein manuelles Eingreifen erforderlich.
+
+=== Eigenarten der Anwendung ===
+
+Für die 'Commits' A und B, hängt die Bedeutung der Ausdrücke "A..B" und
+"A...B" davon ab, ob eine Anweisung zwei Endpunkte erwartet oder einen
+Bereich. Siehe *git help diff* und *git help rev-parse*.