Permalink
Browse files

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

  • Loading branch information...
2 parents c1636d8 + d0afd83 commit a71238b4ae648063aa177f2b8b713bebcdc93bd0 @blynn blynn committed Jan 10, 2015
Showing with 103 additions and 101 deletions.
  1. +10 −10 de/basic.txt
  2. +14 −14 de/branch.txt
  3. +10 −10 de/clone.txt
  4. +13 −13 de/drawbacks.txt
  5. +5 −5 de/grandmaster.txt
  6. +17 −17 de/history.txt
  7. +3 −3 de/intro.txt
  8. +6 −6 de/multiplayer.txt
  9. +19 −17 de/secrets.txt
  10. +6 −6 de/translate.txt
View
@@ -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
@@ -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
@@ -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
@@ -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.
Oops, something went wrong.

0 comments on commit a71238b

Please sign in to comment.