From dd466c983b126abd3cb2148b820c42373c60f0b8 Mon Sep 17 00:00:00 2001 From: Mechtilde Date: Wed, 31 Dec 2014 10:17:01 +0100 Subject: [PATCH] correct typos2 --- de/branch.txt | 28 ++++++++++++++-------------- de/clone.txt | 20 ++++++++++---------- de/history.txt | 32 ++++++++++++++++---------------- 3 files changed, 40 insertions(+), 40 deletions(-) diff --git a/de/branch.txt b/de/branch.txt index dc00145..ea370d6 100644 --- a/de/branch.txt +++ b/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. diff --git a/de/clone.txt b/de/clone.txt index f26e7d0..3f6f65e 100644 --- a/de/clone.txt +++ b/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 diff --git a/de/history.txt b/de/history.txt index ce37f81..8cdb18d 100644 --- a/de/history.txt +++ b/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. -- 2.11.4.GIT