Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Merge branch 'trunk' of https://github.com/Mechtilde/gitmagic

  • Loading branch information...
commit a71238b4ae648063aa177f2b8b713bebcdc93bd0 2 parents c1636d8 + d0afd83
@blynn authored
View
20 de/basic.txt
@@ -1,9 +1,9 @@
== Erste Schritte ==
Bevor wir uns in ein Meer von Git-Befehlen stürzen, schauen wir uns ein paar
-einfache Beispiele an. Trotz ihrer Einfachheit, sind alle davon wichtig und
-nützlich. Um ehrlich zu sein, meine ersten Monate mit Git brauchte ich nicht
-mehr als in diesem Kapitel beschrieben steht.
+einfache Beispiele an. Trotz ihrer Einfachheit sind alle davon wichtig und
+nützlich. Um ehrlich zu sein, in meinen ersten Monaten mit Git brauchte ich nicht
+mehr, als in diesem Kapitel beschrieben steht.
=== Stand sichern ===
@@ -67,7 +67,7 @@ Date: Thu Jan 1 00:00:00 1970 +0000
Initial commit.
----------------------------------
-Die ersten paar Zeichen eines Hashwert reichen aus um einen 'Commit' zu
+Die ersten paar Zeichen eines Hashwert reichen aus, um einen 'Commit' zu
identifizieren; alternativ benutze kopieren und einfügen für den kompletten
Hashwert. Gib ein:
@@ -83,11 +83,11 @@ diesem Fall, gib folgendes ein:
Damit springst Du in der Zeit zurück, behältst aber neuere Änderungen. Aber,
wie bei Zeitreisen in einem Science-Fiction-Film, wenn Du jetzt etwas
-änderst und 'commitest', gelangst Du in ein alternative Realität, denn Deine
+änderst und 'commitest', gelangst Du in eine alternative Realität, denn Deine
Änderungen sind anders als beim früheren 'Commit'.
-Diese alternative Realität heißt 'Branch' und <<branch,wir kommen später
-darauf zurück>>. Für jetzt, merke Dir
+Diese alternative Realität heißt 'Branch', und <<branch,wir kommen später
+darauf zurück>>. Für jetzt merke Dir,
$ git checkout master
@@ -113,7 +113,7 @@ indem Du sie an den Befehl anhängst:
Sei vorsichtig, diese Art des '*Checkout*' kann Dateien überschreiben, ohne
dass Du etwas merkst. Um Unfälle zu vermeiden, solltest Du immer 'commiten'
-bevor du ein 'Checkout' machst, besonders am Anfang, wenn Du Git noch
+bevor Du ein 'Checkout' machst, besonders am Anfang, wenn Du Git noch
erlernst. Allgemein gilt: Wenn Du unsicher bist, egal, ob ein Git Befehl oder
irgendeine andere Operation, führe zuerst *git commit -a* aus.
@@ -169,8 +169,8 @@ Version aktualisieren mit:
=== Einfaches Veröffentlichen ===
Angenommen Du hast ein Skript geschrieben und möchtest es anderen zugänglich
-machen. Du könntest sie einfach bitten, es von deinem Computer
-herunterzuladen, aber falls sie das tun, während du experimentierst oder das
+machen. Du könntest sie einfach bitten, es von Deinem Computer
+herunterzuladen, aber falls sie das tun, während Du experimentierst oder das
Skript verbesserst, könnten sie in Schwierigkeiten geraten. Genau deswegen
gibt es Releasezyklen. Entwickler arbeiten regelmäßig an einem Projekt,
veröffentlichen den Code aber nur, wenn sie ihn für vorzeigbar halten.
View
28 de/branch.txt
@@ -80,8 +80,8 @@ Was, wenn Du am Ende die temporären Änderungen sichern willst? Einfach:
$ git checkout -b schmutzig
-und 'commite' bevor du auf den 'Master Branch' zurückschaltest. Wann immer
-du zu deiner Schmutzarbeit zurückkehren willst, tippe einfach:
+und 'commite', bevor Du auf den 'Master Branch' zurückschaltest. Wann immer
+Du zu Deiner Schmutzarbeit zurückkehren willst, tippe einfach:
$ git checkout schnmutzig
@@ -92,7 +92,7 @@ Stand, aber wir müssen den 'Master Branch' verlassen. Jeder 'Commit' ab
jetzt führt Deine Dateien auf einen anderen Weg, dem wir später noch einen
Namen geben können.
-Mit anderen Worten, nach dem Abrufen eines alten Stands versetzt dich Git
+Mit anderen Worten, nach dem Abrufen eines alten Stands versetzt Dich Git
automatisch in einen neuen, unbenannten 'Branch', der mit *git checkout -b*
benannt und gesichert werden kann.
@@ -174,15 +174,15 @@ geprüft wurde, bevor Du mit dem zweiten Teil anfangen kannst.
Dank des schmerzlosen 'Branchen' und 'Mergen' können wir die Regeln beugen
und am Teil II arbeiten, bevor Teil I offiziell freigegeben
-wurde. Angenommen du hast Teil I 'commitet' und zur Prüfung
-eingereicht. Sagen wir du bist im `master` 'Branch'. Dann 'branche' zu Teil
+wurde. Angenommen Du hast Teil I 'commitet' und zur Prüfung
+eingereicht. Sagen wir, Du bist im `master` 'Branch'. Dann 'branche' zu Teil
II:
$ git checkout -b teil2
-Du arbeitest also an Teil II und 'commitest' deine Änderungen
+Du arbeitest also an Teil II und 'commitest' Deine Änderungen
regelmäßig. Irren ist menschlich und so kann es vorkommen, dass Du zurück zu
-Teil I willst, um einen Fehler zu beheben. Wenn du Glück hast oder sehr gut
+Teil I willst, um einen Fehler zu beheben. Wenn Du Glück hast oder sehr gut
bist, kannst Du die nächsten Zeilen überspringen.
$ git checkout master # Gehe zurück zu Teil I.
@@ -227,7 +227,7 @@ hast. Beginne ein paar 'Branches':
$ 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
+erstelle temporären Code und so weiter und 'commite' Deine Änderungen
oft. Dann:
$ git checkout bereinigt
@@ -266,8 +266,8 @@ Stand zurück kannst, um eine vorrangige Fehlerbehebung zu machen oder
irgendetwas anderes.
Es ist vergleichbar mit dem kurzzeitigen Umschalten des Fernsehkanals, um zu
-sehen was auf dem anderen Kanal los ist. Doch anstelle ein paar Knöpfe zu
-drücken, machst du 'create', 'check out', 'merge' und 'delete' von
+sehen, was auf dem anderen Kanal los ist. Doch anstelle ein paar Knöpfe zu
+drücken, machst du 'create', 'checkout', 'merge' und 'delete' von
temporären 'Branches'. Glücklicherweise hat Git eine Abkürzung dafür, die
genauso komfortabel ist wie eine Fernbedienung:
@@ -286,10 +286,10 @@ Du kannst mehrere 'stashes' haben und diese unterschiedlich handhaben. Siehe
*git help stash*. Wie Du Dir vielleicht schon gedacht hast, verwendet Git
'Branches' im Hintergrund, um diesen Zaubertrick durchzuführen.
-=== Arbeite wie Du willst ===
+=== Arbeite, wie Du willst ===
-Du magst Dich fragen, ob 'Branches' diesen Aufwand Wert sind. Immerhin sind
-'Clone' fast genauso schnell und Du kannst mit *cd* anstelle von
+Du magst Dich fragen, ob 'Branches' diesen Aufwand wert sind. Immerhin sind
+'Clone' fast genauso schnell, und Du kannst mit *cd* anstelle von
esoterischen Git Befehlen zwischen ihnen wechseln.
Betrachten wir Webbrowser. Warum mehrere Tabs unterstützen und mehrere
@@ -298,7 +298,7 @@ Anwender möchten nur ein Browserfenster geöffnet haben und benutzen Tabs für
unterschiedliche Webseiten. Andere bestehen auf dem anderen Extrem: mehrere
Fenster, ganz ohne Tabs. Wieder andere bevorzugen irgendetwas dazwischen.
-'Branchen' ist wie Tabs für dein Arbeitsverzeichnis und 'Clonen' ist wie das
+'Branchen' ist wie Tabs für dein Arbeitsverzeichnis, und 'Clonen' ist wie das
Öffnen eines neuen Browserfenster. Diese Operationen sind schnell und lokal,
also warum nicht damit experimentieren, um die beste Kombination für sich
selbst zu finden? Git lässt Dich genauso arbeiten, wie Du es willst.
View
20 de/clone.txt
@@ -12,7 +12,7 @@ auch mit deinem 'Clone' tun.
=== Computer synchronisieren ===
-Es ist akzeptabel, für Datensicherungen und einfaches Synchronisieren, mit
+Es ist akzeptabel, für Datensicherungen und einfaches Synchronisieren mit
'tarball' Archiven oder *rsync* zu arbeiten. Aber manchmal arbeite ich an
meinem Laptop, dann an meinem Desktop-PC, und die beiden haben sich
inzwischen nicht austauschen können.
@@ -30,12 +30,12 @@ jetzt an wird
den Zustand der Dateien des anderen Computer auf den übertragen, an dem Du
gerade arbeitest. Solltest Du kürzlich konkurrierende Änderungen an der
-selben Datei vorgenommen haben, lässt Git Dich das wissen und musst erneut
+selben Datei vorgenommen haben, lässt Git Dich das wissen, und Du musst erneut
'commiten', nachdem Du die Konflikte aufgelöst hast.
=== Klassische Quellcodeverwaltung ===
-Erstelle ein Git 'Repository' für deine Dateien:
+Erstelle ein Git 'Repository' für Deine Dateien:
$ git init
$ git add .
@@ -61,7 +61,7 @@ Website aus.
$ git push zentraler.server/pfad/zu/proj.git HEAD
-Um die Quellcodes abzurufen gibt ein Entwickler folgendes ein:
+Um die Quellcodes abzurufen, gibt ein Entwickler folgendes ein:
$ git clone zentraler.server/pfad/zu/proj.git
@@ -83,7 +83,7 @@ Um die lokalen Änderungen in das zentrale 'Repository' zu übertragen:
$ git push
Wenn inzwischen neue Änderungen von anderen Entwicklern beim Hauptserver
-eingegangen sind, schlägt dein 'push' fehl. Aktualisiere das lokale
+eingegangen sind, schlägt Dein 'push' fehl. Aktualisiere das lokale
'Repository' erneut mit 'pull', löse eventuell aufgetretene
'Merge'-Konflikte und versuche es nochmal.
@@ -122,7 +122,7 @@ der nicht viel tut außer Daten zu verbreiten. Die Entwicklung findet in den
'Clonen' statt, so kann das Heim-'Repository' ohne Arbeitsverzeichnis
auskommen.
-Viele Git Befehle funktionieren nicht in 'bare Repositories'. Es sei denn
+Viele Git Befehle funktionieren nicht in 'bare Repositories'. Es sei denn,
die `GIT_DIR` Umgebungsvariable wird auf das Arbeitsverzeichnis gesetzt,
oder die `--bare` Option wird übergeben.
@@ -143,7 +143,7 @@ Wie auch immer, abgesehen von diesem Fall, raten wir vom 'Pushen' in ein
Verwirrungen entstehen.
Kurzum, während du lernst mit Git umzugehen, 'pushe' nur, wenn das Ziel ein
-'bare Repository' ist; andernfalls benutze 'pull'.
+'bare Repository' ist, andernfalls benutze 'pull'.
=== 'Fork' eines Projekts ===
@@ -152,7 +152,7 @@ besser? Dann mache folgendes auf deinem Server:
$ git clone git://haupt.server/pfad/zu/dateien
-Dann erzähle jedem von Deiner 'Fork' des Projekts auf Deinem Server.
+Dann erzähle jedem von Deinem 'Fork' des Projekts auf Deinem Server.
Zu jedem späteren Zeitpunkt kannst du die Änderungen des Originalprojekts
'mergen' mit:
@@ -180,8 +180,8 @@ Zeitungskopie zu manipulieren.
=== Multitasking mit Lichtgeschwindigkeit ===
-Nehmen wir an du willst parallel an mehreren Funktionen arbeiten. Dann
-'commite' dein Projekt und gib ein:
+Nehmen wir an Du willst parallel an mehreren Funktionen arbeiten. Dann
+'commite' Dein Projekt und gib ein:
$ git clone . /irgendein/neuer/ordner
View
26 de/drawbacks.txt
@@ -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
10 de/grandmaster.txt
@@ -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
34 de/history.txt
@@ -21,8 +21,8 @@ eingegeben? Dann gib ein:
$ git commit --amend
-um die letzte Beschreibung zu ändern. Du merkst, dass Du vergessen hast eine
-Datei hinzuzufügen? Führe *git add* aus, um sie hinzuzufügen und dann die
+um die letzte Beschreibung zu ändern. Du merkst, dass Du vergessen hast, eine
+Datei hinzuzufügen? Führe *git add* aus, um sie hinzuzufügen, und dann die
vorhergehende Anweisung.
Du willst noch ein paar Änderungen zu deinem letzten 'Commit' hinzufügen?
@@ -39,11 +39,11 @@ umformuliert werden. Dann gib ein:
$ git rebase -i HEAD~10
-und die letzten zehn 'Commits' erscheinen in deinem bevorzugten
+und die letzten zehn 'Commits' erscheinen in Deinem bevorzugten
$EDITOR. Auszug aus einem Beispiel:
pick 5c6eb73 Link repo.or.cz hinzugefügt
- pick a311a64 Analogien in "Arbeite wie du willst" umorganisiert
+ pick a311a64 Analogien in "Arbeite wie Du willst" umorganisiert
pick 100834f Push-Ziel zum Makefile hinzugefügt
Dann:
@@ -51,12 +51,12 @@ Dann:
- Entferne 'Commits' durch das Löschen von Zeilen.
- Organisiere 'Commits' durch verschieben von Zeilen.
- Ersetze `pick` mit:
- * `edit` um einen 'Commit' für 'amends' zu markieren.
- * `reword` um die Log-Beschreibung zu ändern.
- * `squash` um einen 'Commit' mit dem vorhergehenden zu vereinen ('merge').
- * `fixup` um einen 'Commit' mit dem vorhergehenden zu vereinen ('merge') und die Log-Beschreibung zu verwerfen.
+ * `edit`, um einen 'Commit' für 'amends' zu markieren.
+ * `reword`, um die Log-Beschreibung zu ändern.
+ * `squash`, um einen 'Commit' mit dem vorhergehenden zu vereinen ('merge').
+ * `fixup`, um einen 'Commit' mit dem vorhergehenden zu vereinen ('merge') und die Log-Beschreibung zu verwerfen.
-Speichere und Beende. Wenn du einen 'Commit' mit 'edit' markiert hast, gib
+Speichere und Beende. Wenn Du einen 'Commit' mit 'edit' markiert hast, gib
ein:
$ git commit --amend
@@ -65,7 +65,7 @@ Ansonsten:
$ git rebase --continue
-Also 'commite' früh und oft: du kannst später mit 'rebase' aufräumen.
+Also 'commite' früh und oft: Du kannst später mit 'rebase' aufräumen.
=== Lokale Änderungen zum Schluss ===
@@ -80,7 +80,7 @@ willst alle Deine Änderungen lieber in einem fortlaufenden Abschnitt und
hinter den offiziellen Änderungen sehen.
Das ist eine Aufgabe für *git rebase*, wie oben beschrieben. In vielen
-Fällen kannst du den *--onto* Schalter benutzen, um Interaktion zu vermeiden.
+Fällen kannst Du den *--onto* Schalter benutzen, um Interaktion zu vermeiden.
Siehe auch *git help rebase* für ausführliche Beispiele dieser erstaunlichen
Anweisung. Du kannst auch 'Commits' aufteilen. Du kannst sogar 'Branches' in
@@ -104,11 +104,11 @@ schnellere Methode vorstellt wird. Allgemein, *filter-branch* lässt Dich
große Bereiche der Chronik mit einer einzigen Anweisung verändern.
Danach beschreibt der Ordner +.git/refs/original+ den Zustand der Lage vor
-der Operation. Prüfe, ob die 'filter-branch' Anweisung getan hat, was du
+der Operation. Prüfe, ob die 'filter-branch' Anweisung getan hat, was Du
wolltest, dann lösche dieses Verzeichnis, bevor Du weitere 'filter-branch'
Operationen durchführst.
-Zuletzt, ersetze alle 'Clones' Deines Projekts mit deiner überarbeiteten
+Zuletzt, ersetze alle 'Clones' Deines Projekts mit Deiner überarbeiteten
Version, falls Du später mit ihnen interagieren möchtest.
=== Geschichte machen ===
@@ -162,7 +162,7 @@ Die aktuellste Version des Projekts kannst Du abrufen ('checkout') mit:
$ git checkout master .
Die Anweisung *git fast-export* konvertiert jedes 'Repository' in das *git
-fast-import* Format, dessen Ausgabe Du studieren kannst, um Exporteure zu
+fast-import* Format, dessen Ausgabe Du studieren kannst, um Exporte zu
schreiben und außerdem, um 'Repositories' im menschenlesbaren Text zu übertragen.
Tatsächlich können diese Anweisungen Klartext-'Repositories' über reine
@@ -170,8 +170,8 @@ Textkanäle übertragen.
=== Wo ging alles schief? ===
-Du hast gerade eine Funktion in deiner Anwendung entdeckt, die nicht mehr
-funktioniert und du weißt sicher, dass sie vor ein paar Monaten noch
+Du hast gerade eine Funktion in Deiner Anwendung entdeckt, die nicht mehr
+funktioniert und Du weißt sicher, dass sie vor ein paar Monaten noch
ging. Argh! Wo kommt dieser Fehler her? Hättest Du nur die Funktion während
der Entwicklung getestet.
@@ -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
6 de/intro.txt
@@ -10,14 +10,14 @@ Versionsverwaltung].
Ich spiele Computerspiele schon fast mein ganzes Leben. Im Gegensatz dazu
habe ich erst als Erwachsener damit begonnen, Versionsverwaltungssysteme zu
benutzen. Ich vermute, dass ich damit nicht alleine bin, und der Vergleich
-hilft vielleicht, dabei die Konzepte einfacher zu erklären und zu verstehen.
+hilft vielleicht dabei, die Konzepte einfacher zu erklären und zu verstehen.
Stelle Dir das Bearbeiten deines Codes oder Deiner Dokumente wie ein
Computerspiel vor. Wenn Du gut vorangekommen bist, willst Du das Erreichte
sichern. Um das zu tun, klickst Du auf auf Speichern in Deinem vertrauten
Editor.
-Aber, das überschreibt die vorherige Version. Das ist wie bei den Spielen
+Aber das überschreibt die vorherige Version. Das ist wie bei den Spielen
der alten Schule, die nur Speicherplatz für eine Sicherung hatten:
sicherlich konntest Du speichern, aber Du konntest nie zu einem älteren
Stand zurück. Das war eine Schande, denn vielleicht war Deine vorherige
@@ -134,7 +134,7 @@ Dateiende. Beide laden ihre Änderungen hoch. Die meisten Systeme wählen
automatisch eine vernünftige Vorgehensweise: akzeptiere beide Änderungen und
füge sie zusammen, damit fließen beide Änderungen in das Dokument mit ein.
-Nun stell dir vor beide, Alice und Bob, machen Änderungen in der selben
+Nun stell Dir vor beide, Alice und Bob, machen Änderungen in der selben
Zeile. Dann ist es unmöglich, ohne menschlichen Eingriff fortzufahren. Die
zweite Person, welche die Datei hoch lädt, wird über einen _'Merge'
Konflikt_ informiert und muss entscheiden, welche Änderung übernommen wird
View
12 de/multiplayer.txt
@@ -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,7 +153,7 @@ 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:
@@ -161,10 +161,10 @@ 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
36 de/secrets.txt
@@ -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
12 de/translate.txt
@@ -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'.
Please sign in to comment.
Something went wrong with that request. Please try again.