From 4924e9c19c3c968076964d6da5a571a7c4b41f51 Mon Sep 17 00:00:00 2001 From: Mechtilde Date: Tue, 17 Dec 2013 20:12:22 +0100 Subject: [PATCH] Typo-Korrekturen3 --- de/branch.txt | 118 +++++++++++++++++++++++++++++----------------------------- 1 file changed, 59 insertions(+), 59 deletions(-) diff --git a/de/branch.txt b/de/branch.txt index 315e8b7..dc00145 100644 --- a/de/branch.txt +++ b/de/branch.txt @@ -3,7 +3,7 @@ Unverzügliches 'Branchen' und 'Mergen' sind die hervorstechenden Eigenschaften von Git. -*Problem*: Externe Faktoren zwingen zum Wechsel des Kontext. Ein schwerwiegender Fehler in der veröffentlichten Version tritt ohne Vorwarnung auf. Die Frist für ein bestimmtes Leistungsmerkmal rückt näher. Ein Entwickler, dessen Unterstützung für eine Schlüsselstelle im Projekt wichtig ist, verlässt das Team. In allen Fällen musst du alles stehen und liegen lassen und dich auf eine komplett andere Aufgabe konzentrieren. +*Problem*: Externe Faktoren zwingen zum Wechsel des Kontext. Ein schwerwiegender Fehler in der veröffentlichten Version tritt ohne Vorwarnung auf. Die Frist für ein bestimmtes Leistungsmerkmal rückt näher. Ein Entwickler, dessen Unterstützung für eine Schlüsselstelle im Projekt wichtig ist, verlässt das Team. In allen Fällen musst Du alles stehen und liegen lassen und Dich auf eine komplett andere Aufgabe konzentrieren. Den Gedankengang zu unterbrechen ist schlecht für die Produktivität und je komplizierter der Kontextwechsel ist, desto größer ist der Verlust. Mit @@ -18,19 +18,19 @@ gesamten Projektdateien im neuen Arbeitsverzeichnis erstellt werden. *Lösung*: Git hat ein besseres Werkzeug für diese Situationen, die wesentlich schneller und platzsparender als 'clonen' ist: *git branch*. -Mit diesem Zauberwort verwandeln sich die Dateien in deinem +Mit diesem Zauberwort verwandeln sich die Dateien in Deinem Arbeitsverzeichnis plötzlich von einer Version in eine andere. Diese Verwandlung kann mehr als nur in der Geschichte vor und zurück gehen. Deine Dateien können sich verwandeln, vom aktuellsten Stand, zur experimentellen -Version, zum neusten Entwicklungsstand, zur Version deines Freundes und so +Version, zum neusten Entwicklungsstand, zur Version Deines Freundes und so weiter. === Die Chef-Taste === -Hast du schon einmal ein Spiel gespielt, wo beim Drücken einer Taste (``der +Hast Du schon einmal ein Spiel gespielt, wo beim Drücken einer Taste (``der Chef-Taste''), der Monitor sofort ein Tabellenblatt oder etwas anderes -angezeigt hat? Dass, wenn der Chef ins Büro spaziert, während du das Spiel -spielst, du es schnell verstecken kannst? +angezeigt hat? Dass, wenn der Chef ins Büro spaziert, während Du das Spiel +spielst, Du es schnell verstecken kannst? In irgendeinem Verzeichnis: @@ -46,7 +46,7 @@ bestimmten Nachricht enthält. Nun gib ein: $ echo "Mein Chef ist klüger als ich" > meinedatei.txt $ git commit -a -m "Ein anderer Stand" -Es sieht aus als hätten wir unsere Datei überschrieben und 'commitet'. Aber +Es sieht aus, als hätten wir unsere Datei überschrieben und 'commitet'. Aber es ist eine Illusion. Tippe: $ git checkout master # wechsle zur Originalversion der Datei @@ -61,22 +61,22 @@ kannst unabhängig voneinander in jeder Version Änderungen 'commiten' === Schmutzarbeit === -[[branch]] Sagen wir, du arbeitest an einer Funktion und du musst, warum -auch immer, drei Versionen zurückgehen um ein paar print Anweisungen -einzufügen, damit du siehst, wie etwas funktioniert. Dann: +[[branch]] Sagen wir, Du arbeitest an einer Funktion und Du musst, warum +auch immer, drei Versionen zurückgehen, um ein paar print Anweisungen +einzufügen, damit Du siehst, wie etwas funktioniert. Dann: $ git commit -a $ git checkout HEAD~3 -Nun kannst du überall wild temporären Code hinzufügen. Du kannst diese -Änderungen sogar 'commiten'. Wenn du fertig bist, +Nun kannst Du überall wild temporären Code hinzufügen. Du kannst diese +Änderungen sogar 'commiten'. Wenn Du fertig bist, $ git checkout master um zur ursprünglichen Arbeit zurückzukehren. Beachte, dass alle Änderungen, -die nicht 'commitet' sind übernommen werden. +die nicht 'commitet' sind, übernommen werden. -Was, wenn du am Ende die temporären Änderungen sichern willst? Einfach: +Was, wenn Du am Ende die temporären Änderungen sichern willst? Einfach: $ git checkout -b schmutzig @@ -89,7 +89,7 @@ Wir sind mit dieser Anweisung schon in einem früheren Kapitel in Berührung gekommen, als wir das Laden alter Stände besprochen haben. Nun können wir die ganze Geschichte erzählen: Die Dateien ändern sich zu dem angeforderten 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 +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 @@ -98,18 +98,18 @@ benannt und gesichert werden kann. === Schnelle Fehlerbehebung === -Du steckst mitten in der Arbeit, als es heißt alles fallen zu lassen um +Du steckst mitten in der Arbeit, als es heißt, alles fallen zu lassen, um einen neu entdeckten Fehler in 'Commit' `1b6d...` zu beheben: $ git commit -a $ git checkout -b fixes 1b6d -Dann, wenn du den Fehler behoben hast: +Dann, wenn Du den Fehler behoben hast: $ git commit -a -m "Fehler behoben" $ git checkout master -und fahre mit deiner ursprünglichen Arbeit fort. Du kannst sogar die frisch +und fahre mit Deiner ursprünglichen Arbeit fort. Du kannst sogar die frisch gebackene Fehlerkorrektur auf Deinen aktuellen Stand übernehmen: $ git merge fixes @@ -118,14 +118,14 @@ gebackene Fehlerkorrektur auf Deinen aktuellen Stand übernehmen: Mit einigen Versionsverwaltungssystemen ist das Erstellen eines 'Branch' einfach, aber das Zusammenfügen ('Mergen') ist schwierig. Mit Git ist -'Mergen' so einfach, dass du gar nicht merkst, wenn es passiert. +'Mergen' so einfach, dass Du gar nicht merkst, wenn es passiert. Tatsächlich sind wir dem 'Mergen' schon lange begegnet. Die *pull* Anweisung holt ('fetch') eigentlich die 'Commits' und verschmilzt ('merged') diese -dann mit dem aktuellen 'Branch'. Wenn du keine lokalen Änderungen hast, dann +dann mit dem aktuellen 'Branch'. Wenn Du keine lokalen Änderungen hast, dann ist 'merge' eine 'schnelle Weiterleitung', ein Ausnahmefall, ähnlich dem Abrufen der letzten Version eines zentralen Versionsverwaltungssystems. Wenn -du aber Änderungen hast, wird Git diese automatisch 'mergen' und dir +Du aber Änderungen hast, wird Git diese automatisch 'mergen' und Dir Konflikte melden. Normalerweise hat ein 'Commit' genau einen Eltern-'Commit', nämlich den @@ -136,8 +136,8 @@ Eltern haben, welchem folgen wir also? Es stellt sich heraus, dass diese Notation immer den ersten Elternteil wählt. Dies ist erstrebenswert, denn der aktuelle 'Branch' wird zum ersten -Elternteil während eines 'Merge'; häufig bist du nur von Änderungen -betroffen, die du im aktuellen 'Branch' gemacht hast, als von den Änderungen +Elternteil während eines 'Merge'; häufig bist Du nur von Änderungen +betroffen, die Du im aktuellen 'Branch' gemacht hast, als von den Änderungen, die von anderen 'Branches' eingebracht wurden. Du kannst einen bestimmten Elternteil mit einem Caret-Zeichen @@ -160,7 +160,7 @@ Hashwert mit 1b6d beginnt. === Kontinuierlicher Arbeitsfluss === -In Herstellungsprozessen muss der zweiter Schritt eines Plans oft auf die +In Herstellungsprozessen muss der zweite Schritt eines Plans oft auf die Fertigstellung des ersten Schritt warten. Ein Auto, das repariert werden soll, steht unbenutzt in der Garage bis ein Ersatzteil geliefert wird. Ein Prototyp muss warten, bis ein Baustein fabriziert wurde, bevor die @@ -168,9 +168,9 @@ Konstruktion fortgesetzt werden kann. Bei Softwareprojekten kann das ähnlich sein. Der zweite Teil eines Leistungsmerkmals muss warten, bis der erste Teil veröffentlicht und -getestet wurde. Einige Projekte erfordern, dass dein Code überprüft werden -muss bevor er akzeptiert wird, du musst also warten, bis der erste Teil -geprüft wurde, bevor du mit dem zweiten Teil anfangen kannst. +getestet wurde. Einige Projekte erfordern, dass Dein Code überprüft werden +muss, bevor er akzeptiert wird; Du musst also warten, bis der erste Teil +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 @@ -181,9 +181,9 @@ II: $ git checkout -b teil2 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 -bist, kannst du die nächsten Zeilen überspringen. +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 +bist, kannst Du die nächsten Zeilen überspringen. $ git checkout master # Gehe zurück zu Teil I. $ fix_problem @@ -198,10 +198,10 @@ Schließlich, Teil I ist zugelassen: $ git merge teil2 # 'Merge' in Teil II. $ git branch -d teil2 # Lösche den Branch "teil2" -Nun bist du wieder im `master` 'Branch', mit Teil II im Arbeitsverzeichnis. +Nun bist Du wieder im `master` 'Branch', mit Teil II im Arbeitsverzeichnis. Es ist einfach, diesen Trick auf eine beliebige Anzahl von Teilen zu -erweitern. Es ist genauso einfach rückwirkend zu 'branchen': angenommen, du +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: @@ -209,7 +209,7 @@ wäre. Dann tippe: $ 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 +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: @@ -218,15 +218,15 @@ gewechselt, wie in: === Mischmasch Reorganisieren === -Vielleicht magst du es, alle Aspekte eines Projekts im selben 'Branch' -abzuarbeiten. Du willst deine laufenden Arbeiten für dich behalten und -andere sollen deine 'Commits' nur sehen, wenn du sie hübsch organisiert +Vielleicht magst Du es, alle Aspekte eines Projekts im selben 'Branch' +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 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, +Fahre fort, alles zu bearbeiten: Behebe Fehler, füge Funktionen hinzu, erstelle temporären Code und so weiter und 'commite' deine Änderungen oft. Dann: @@ -234,17 +234,17 @@ oft. Dann: $ git cherry-pick mischmasch^^ wendet den Urahn des obersten 'Commit' des ``mischmasch'' 'Branch' auf den -``bereinigt'' 'Branch' an. Durch das Herauspicken der Rosinen kannst du +``bereinigt'' 'Branch' an. Durch das Herauspicken der Rosinen kannst Du einen 'Branch' konstruieren, der nur endgültigen Code enthält und zusammengehörige 'Commits' gruppiert hat. === 'Branches' verwalten === -Ein Liste aller 'Branches' bekommst du mit: +Ein Liste aller 'Branches' bekommst Du mit: $ git branch -Standardmäßig beginnst du in einem 'Branch' namens ``master''. Einige +Standardmäßig beginnst Du in einem 'Branch' namens ``master''. Einige plädieren dafür, den ``master'' 'Branch' unangetastet zu lassen und für seine Arbeit einen neuen 'Branch' anzulegen. @@ -252,20 +252,20 @@ Die *-d* und *-m* Optionen erlauben dir 'Branches' zu löschen und zu verschieben (umzubenennen). Siehe *git help branch*. Der ``master'' 'Branch' ist ein nützlicher Brauch. Andere können davon -ausgehen, dass dein 'Repository' einen 'Branch' mit diesem Namen hat und -dass er die offizielle Version enthält. Auch wenn du den ``master'' 'Branch' -umbenennen oder auslöschen könntest, kannst du diese Konvention aber auch +ausgehen, dass Dein 'Repository' einen 'Branch' mit diesem Namen hat und +dass er die offizielle Version enthält. Auch wenn Du den ``master'' 'Branch' +umbenennen oder auslöschen könntest, kannst Du diese Konvention aber auch respektieren. === Temporäre 'Branches' === -Nach einer Weile wirst du feststellen, dass du regelmäßig kurzlebige +Nach einer Weile wirst Du feststellen, dass Du regelmäßig kurzlebige 'Branches' erzeugst, meist aus dem gleichen Grund: jeder neue 'Branch' dient -lediglich dazu, den aktuellen Stand zu sichern, damit du kurz zu einem alten -Stand zurück kannst um eine vorrangige Fehlerbehebung zu machen oder +lediglich dazu, den aktuellen Stand zu sichern, damit Du kurz zu einem alten +Stand zurück kannst, um eine vorrangige Fehlerbehebung zu machen oder irgendetwas anderes. -Es ist vergleichbar mit dem kurzzeitigen Umschalten des Fernsehkanals um zu +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 temporären 'Branches'. Glücklicherweise hat Git eine Abkürzung dafür, die @@ -275,30 +275,30 @@ genauso komfortabel ist wie eine Fernbedienung: Das sichert den aktuellen Stand an einem temporären Ort ('stash'=Versteck) und stellt den vorherigen Stand wieder her. Dein Arbeitsverzeichnis -erscheint wieder exakt in dem Zustand wie es war, bevor du anfingst zu -editieren. Nun kannst du Fehler beheben, Änderungen vom zentralen -'Repository' holen ('pull') und so weiter. Wenn du wieder zurück zu deinen +erscheint wieder exakt in dem Zustand, wie es war, bevor Du anfingst zu +editieren. Nun kannst Du Fehler beheben, Änderungen vom zentralen +'Repository' holen ('pull') und so weiter. Wenn Du wieder zurück zu Deinen Änderungen willst, tippe: - $ git stash apply # Es kann sein, dass du Konflikte auflösen musst. + $ git stash apply # Es kann sein, dass Du Konflikte auflösen musst. 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. +*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 -Fenster? Weil beides zu erlauben eine Vielzahl an Stilen unterstützt. Einige +Fenster? Weil beides zu erlauben, eine Vielzahl an Stilen unterstützt. Einige 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 Ö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. +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. -- 2.11.4.GIT