Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Merge https://github.com/lordofbikes/gitmagic

  • Loading branch information...
commit 5a140f76eb1e6287b95afa35bc083998a7a4f974 2 parents c7ed234 + 370dc18
@blynn blynn authored
View
309 de/branch.txt
@@ -0,0 +1,309 @@
+== 'Branch'-Magie ==
+
+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.
+
+Den Gedankengang zu unterbrechen ist schlecht für die Produktivität und je
+komplizierter der Kontextwechsel ist, desto größer ist der Verlust. Mit
+zentraler Versionsverwaltung müssen wir eine neue Arbeitskopie vom Server
+herunterladen. Bei verteilen Systemen ist das viel besser, da wir die
+benötigt Version lokal 'clonen' können.
+
+Doch das 'Clonen' bringt das Kopieren des gesamten Arbeitsverzeichnis wie
+auch die ganze Geschichte bis zum angegebenen Punkt mit sich. Auch wenn Git
+die Kosten durch Dateifreigaben und Verknüpfungen reduziert, müssen doch die
+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
+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
+weiter.
+
+=== Die Chef-Taste ===
+
+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?
+
+In irgendeinem Verzeichnis:
+
+ $ echo "Ich bin klüger als mein Chef" > meinedatei.txt
+ $ git init
+ $ git add .
+ $ git commit -m "Erster Stand"
+
+Wir haben ein Git 'Repository' erstellt, das eine Textdatei mit einer
+bestimmten Nachricht enthält. Nun gib ein:
+
+ $ git checkout -b chef # scheinbar hat sich danach nichts geändert
+ $ 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 ist eine Illusion. Tippe:
+
+ $ git checkout master # wechsle zur Originalversion der Datei
+
+und Simsalabim! Die Textdatei ist wiederhergestellt. Und wenn der Chef in
+diesem Verzeichnis herumschnüffelt, tippe:
+
+ $ git checkout chef # wechsle zur Version die der Chef ruhig sehen kann
+
+Du kannst zwischen den beiden Versionen wechseln, so oft du willst und du
+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:
+
+ $ 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,
+
+ $ git checkout master
+
+um zur ursprünglichen Arbeit zurückzukehren. Beachte, dass alle Änderungen,
+die nicht 'commitet' sind übernommen werden.
+
+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:
+
+ $ git checkout schnmutzig
+
+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
+Namen geben können.
+
+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.
+
+=== Schnelle Fehlerbehebung ===
+
+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:
+
+ $ 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:
+
+ $ 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'
+einfach, aber das Zusammenfügen ('Mergen') ist schwierig. Mit Git ist
+'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
+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
+Konflikte melden.
+
+Normalerweise hat ein 'Commit' genau einen Eltern-'Commit', nämlich den
+vorhergehenden 'Commit'. Das 'Mergen' mehrerer 'Branches' erzeugt einen
+'Commit' mit mindestens zwei Eltern. Das wirft die Frage auf: Welchen
+'Commit' referenziert `HEAD~10` tatsächlich? Ein 'Commit' kann mehrere
+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
+die von anderen 'Branches' eingebracht wurden.
+
+Du kannst einen bestimmten Elternteil mit einem Caret-Zeichen
+referenzieren. Um zum Beispiel die Logs vom zweiten Elternteil anzuzeigen:
+
+ $ git log HEAD^2
+
+Du kannst die Nummer für den ersten Elternteil weglassen. Um zum Beispiel
+die Unterschiede zum ersten Elternteil anzuzeigen:
+
+ $ git diff HEAD^
+
+Du kannst diese Notation mit anderen Typen kombinieren. Zum Beispiel:
+
+ $ git checkout 1b6d^^2~10 -b uralt
+
+beginnt einen neuen 'Branch' ``uralt'', welcher den Stand 10 'Commits'
+zurück vom zweiten Elternteil des ersten Elternteil des 'Commits', dessen
+Hashwert mit 1b6d beginnt.
+
+=== Kontinuierlicher Arbeitsfluss ===
+
+In Herstellungsprozessen muss der zweiter 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
+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.
+
+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
+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.
+
+ $ git checkout master # Gehe zurück zu Teil I.
+ $ fix_problem
+ $ git commit -a # 'Commite' die Lösung.
+ $ git checkout teil2 # Gehe zurück zu Teil II.
+ $ git merge master # 'Merge' die Lösung.
+
+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
+
+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
+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
+
+Der `master` 'Branch' enthält nun nur den Teil I und der `teil2` 'Branch'
+enthält den Rest.
+
+=== 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
+hast. Beginne ein paar 'Branches':
+
+ $ git checkout -b bereinigt
+ $ git checkout -b mischmasch
+
+Fahre fort alles zu bearbeiten: Behebe Fehler, füge Funktionen hinzu,
+erstelle temporären Code und so weiter und 'commite' deine Änderungen
+oft. Dann:
+
+ $ git checkout bereinigt
+ $ 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
+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:
+
+ $ git branch
+
+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.
+
+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
+respektieren.
+
+=== Temporäre 'Branches' ===
+
+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
+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
+temporären 'Branches'. Glücklicherweise hat Git eine Abkürzung dafür, die
+genauso komfortabel ist wie eine Fernbedienung:
+
+ $ git stash
+
+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
+Änderungen willst, tippe:
+
+ $ 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.
+
+=== 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
+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
+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.
View
275 de/history.txt
@@ -0,0 +1,275 @@
+== Geschichtsstunde ==
+
+Eine Folge von Git's verteilter Natur ist, dass die Chronik einfach
+verändert werden kann. Aber, wenn du an der Vergangenheit manipulierst, sei
+vorsichtig: verändere nur den Teil der Chronik, den du ganz alleine hast. So
+wie Nationen ewig diskutieren, wer welche Greueltaten vollbracht hat, wirst
+du beim Abgleichen in Schwierigkeiten geraten, falls jemand einen 'Clone'
+mit abweichender Chronik hat und die Zweige sich austauschen sollen.
+
+Einige Entwickler setzen sich nachhaltig für die Unantastbarkeit der Chronik
+ein, mit allen Fehlern, Nachteilen und Mängeln. Andere denken, daß Zweige
+vorzeigbar gemacht werden sollten, bevor sie auf die Öffentlichkeit
+losgelassen werden. Git versteht beide Gesichtspunkte. Wie 'Clonen',
+'Branchen' und 'Mergen' ist das Umschreiben der Chronik lediglich eine
+weitere Stärke, die Git dir bietet. Es liegt an dir diese weise zu nutzen.
+
+=== Ich nehme alles zurück ===
+
+Hast du gerade 'commitet', aber du hättest gerne eine andere Beschreibung
+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
+vorhergehende Anweisung.
+
+Du willst noch ein paar Änderungen zu deinem letzten 'Commit' hinzufügen?
+Dann mache diese Änderungen und gib ein:
+
+ $ git commit --amend -a
+
+=== ... und noch viel mehr ===
+
+Nehmen wir jetzt an, das vorherige Problem ist zehnmal schlimmer. Nach einer
+längeren Sitzung hast du einen Haufen 'Commits' gemacht. Aber du bist mit
+der Art der Organisation nicht glücklich und einige 'Commits' könnten etwas
+umformuliert werden. Dann gib ein:
+
+ $ git rebase -i HEAD~10
+
+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 100834f Push-Ziel zum Makefile hinzugefügt
+
+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.
+
+Speichere und Beende. Wenn du einen 'Commit' mit 'edit' markiert hast, gib
+ein:
+
+ $ git commit --amend
+
+Ansonsten:
+
+ $ git rebase --continue
+
+Also 'commite' früh und oft: du kannst später mit 'rebase' aufräumen.
+
+=== Lokale Änderungen zum Schluß ===
+
+Du arbeitest an einem aktiven Projekt. Über die Zeit haben sich einige
+lokale 'Commits' angesammelt und dann synchronisierst du mit einem 'Merge'
+mit dem offiziellen Zweig. Dieser Zyklus wiederholt sich ein paar Mal bevor
+du zum 'Pushen' in den zentralen Zweig bereit bist.
+
+Aber nun ist die Chronik in deinem lokalen Git-'Clone' ein chaotisches
+Durcheinander deiner Änderungen und den Änderungen vom offiziellen Zweig. Du
+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.
+
+Siehe auch *git help rebase* für ausführliche Beispiele dieser erstaunlichen
+Anweisung. Du kannst auch 'Commits' aufteilen. Du kannst sogar 'Branches' in
+einem 'Repository' umorganisieren.
+
+=== Chronik umschreiben ===
+
+Gelegentlich brauchst du Versionsverwaltung vergleichbar dem Wegretuschieren
+von Personen aus einem offiziellen Foto, um diese in stalinistischer Art aus
+der Geschichte zu löschen. Stell dir zum Beispiel vor, du willst ein Projekt
+veröffentlichen, aber es enthält eine Datei, die aus irgendwelchen Gründen
+privat bleiben muss. Vielleicht habe ich meine Kreditkartennummer in einer
+Textdatei notiert und diese versehentlich dem Projekt hinzugefügt. Die Datei
+zu löschen ist zwecklos, da über ältere 'Commits' auf sie zugegriffen werden
+könnte. Wir müssen die Datei aus allen 'Commits' entfernen:
+
+ $ git filter-branch --tree-filter 'rm sehr/geheime/Datei' HEAD
+
+Siehe *git help filter-branch*, wo dieses Beispiel erklärt und eine
+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
+wolltest, dann lösche dieses Verzeichnis bevor du weitere 'filter-branch'
+Operationen durchführst.
+
+Zuletzt, ersetze alle 'Clones' deines Projekts mit deiner überarbeiteten
+Version, falls du später mit ihnen interagieren möchtest.
+
+=== Geschichte machen ===
+
+[[makinghistory]] Du möchtest ein Projekt zu Git umziehen? Wenn es mit einem
+der bekannteren Systeme verwaltet wird, besteht die Möglichkeit, dass schon
+jemand ein Skript geschrieben hat, das die gesamte Chronik für Git
+exportiert.
+
+Anderenfalls, sieh dir *git fast-import* an, das Text in einem speziellen
+Format einliest um eine Git Chronik von Anfang an zu
+erstellen. Normalerweise wird ein Skript, das diese Anweisung benutzt,
+hastig zusammengeschustert und einmalig ausgeführt um das Projekt in einem
+einzigen Lauf zu migrieren.
+
+As an example, paste the following listing into temporary file, such as `/tmp/history`:
+----------------------------------
+commit refs/heads/master committer Alice <alice@example.com> Thu, 01 Jan
+1970 00:00:00 +0000 data <<EOT Initial commit. EOT
+
+M 100644 inline hello.c data <<EOT #include <stdio.h>
+
+int main() {
+ printf("Hallo, Welt!\n");
+ return 0;
+}
+EOT
+
+
+commit refs/heads/master committer Bob <bob@example.com> Tue, 14 Mar 2000
+01:59:26 -0800 data <<EOT Ersetze printf() mit write(). EOT
+
+M 100644 inline hello.c data <<EOT #include <unistd.h>
+
+int main() {
+ write(1, "Hallo, Welt!\n", 14);
+ return 0;
+}
+EOT
+
+----------------------------------
+
+Dann, erstelle ein Git 'Repository' aus dieser temporären Datei, durch
+Eingabe von:
+
+ $ mkdir project; cd project; git init
+ $ git fast-import --date-format=rfc2822 < /tmp/history
+
+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, diese Ausgabe kannst du studieren um Exporteure zu
+schreiben und außerdem um 'Repositories' in Klartext zu übertragen.
+untersuchen wes you can study for writing exporters, and also to transport
+repositories in a human-readable format. Wirklich, diese Anweisung kann
+Klartext-'Repositories' über reine Textkanäle übertragen.
+
+=== Wo ging alles schief? ===
+
+Du hast gerade ein 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.
+
+Dafür ist es nun zu spät. Wie auch immer, vorausgesetzt du hast oft
+'comittet', kann Git dir sagen, wo das Problem liegt:
+
+ $ git bisect start
+ $ git bisect bad HEAD
+ $ git bisect good 1b6d
+
+Git ruft eine Stand ab, der genau dazwischen liegt. Teste die Funktion und
+wenn sich immer noch nicht funktioniert:
+
+ $ git bisect bad
+
+Wenn nicht, ersetzte "bad" mit "good". Git versetzt dich wieder auf einen
+Stand genau zwischen den bekannten Versionen "good" und "bad" und reduziert
+so die Möglichkeiten. Nach ein paar Durchläufen wird dich diese binäre Suche
+zu dem 'Commit' führen, der die Probleme verursacht. Wenn du deine
+Ermittlungen abgeschlossen hast, kehre zum Originalstand zurück mit:
+
+ $ git bisect reset
+
+Anstatt jede Änderung per Hand zu untersuchen, automatisiere die Suche durch
+Ausführen von:
+
+ $ git bisect run mein_skript
+
+Git benutzt den Rückgabewert der übergebenen Anweisung, normalerweise ein
+Skript für einmalige Ausführung, um zu entscheiden, ob eine Änderung gut
+('good') oder schlecht ('bad') ist: Das Skript sollte 0 für 'good'
+zurückgeben, 125 wenn die Änderung übersprungen werden soll und irgendetwas
+zwischen 1 und 127 für 'bad'. Ein negativer Rückgabewert beendet die
+'bisect'-Operation sofort.
+
+Du kannst noch viel mehr machen: die Hilfe erklärt, wie man
+'bisect'-Operationen visualisiert, das 'bisect'-Log untersucht oder
+wiedergibt und sicher unschuldige Änderungen ausschließt um die Suche zu
+beschleunigen.
+
+=== Wer ist verantwortlich? ===
+
+Wie viele andere Versionsverwaltungssysteme hat Git eine 'blame' Anweisung:
+
+ $ git blame bug.c
+
+das jede Zeile in der angegebenen Datei kommentiert um anzuzeigen, wer sie
+zuletzt geändert hat und wann. Im Gegensatz zu vielen anderen
+Versionsverwaltungssystemen funktioniert diese Operation offline, es wird
+nur von der lokalen Festplatte gelesen.
+
+=== Persönliche Erfahrungen ===
+
+In einem zentralisierten Versionsverwaltungssystem ist das Bearbeiten der
+Chronik eine schwierige Angelegenheit und den Administratoren
+vorbehalten. 'Clonen', 'Branchen' und 'Mergen' sind unmöglich ohne
+Netzwerkverbindung. Ebenso grundlegende Funktionen wie das Durchsuchen der
+Chronik oder das 'comitten' einer Änderung. In manchen Systemen benötigt der
+Anwender schon eine Netzwerkverbindung nur um seine eigenen Änderungen zu
+sehen oder um eine Datei zum Bearbeiten zu öffnen.
+
+Zentralisierte Systeme schließen es aus offline zu arbeiten und benötigen
+teurere Netzwerkinfrastruktur, vor allem, wenn die Zahl der Entwickler
+steigt. Am wichtigsten ist, dass alle Operationen bis zu einem gewissen Grad
+langsamer sind, in der Regel bis zu dem Punkt, wo Anwender erweiterte
+Anweisungen scheuen, bis sie absolut notwendig sind. In extremen Fällen
+trifft das auch auf die grundlegenden Anweisungen zu. Wenn Anwender langsame
+Anweisungen ausführen müssen, sinkt die Produktivität, da der Arbeitsfluss
+unterbrochen wird.
+
+Ich habe diese Phänomen aus erster Hand erfahren. Git war das erste
+Versionsverwaltungssystem, das ich benutzt habe. Ich bin schnell in die
+Anwendung hineingewachsen und betrachtete viele Funktionen als
+selbstverständlich. Ich habe einfach vorausgesetzt, dass andere Systeme
+ähnlich sind: die Auswahl eines Versionsverwaltungssystems sollte nicht
+anders sein als die Auswahl eines Texteditors oder Internetbrowser.
+
+Ich war geschockt, als ich später gezwungen war ein zentralisiertes System
+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
+meinem gewohnten Arbeitsablauf zu folgen.
+
+Wenn ich eine langsame Anweisung auszuführen hatte, wurde durch die
+Unterbrechung meiner Gedankengänge dem Arbeitsfluss ein unverhältnismäßiger
+Schaden zugefügt. Während dem Warten auf das Ende der Serverkommunikation
+tat ich etwas anderes um die Wartezeit zu überbrücken, zum Beispiel E-Mails
+lesen oder Dokumentation schreiben. Wenn ich zur ursprünglichen Arbeit
+zurückkehrte, war die Operation längst beendet und ich vergeudete noch mehr
+Zeit beim Versuch mich zu erinnern was ich getan habe. Menschen sind nicht
+gut im Kontextwechsel.
+
+Da war auch ein interessanter
+http://de.wikipedia.org/wiki/Tragik_der_Allmende[Tragik-der-Allmende]
+Effekt: Netzwerküberlastungen erahnend, verbrauchten einzelne Individuen für
+diverse Operationen mehr Netzwerkbandbreite als erforderlich, um zukünftige
+Engpässe zu vermeiden. Die Summe der Bemühungen verschlimmerte die
+Überlastungen, was einzelne wiederum ermutigte noch mehr Bandbreite zu
+verbrauchen um noch längere Wartezeiten zu verhindern.
View
265 de/multiplayer.txt
@@ -0,0 +1,265 @@
+== Multiplayer Git ==
+
+Anfangs benutzte ich Git bei einem privaten Projekt, bei dem ich der einzige
+Entwickler war. Unter den Befehlen im Zusammenhang mit Git's verteilter Art,
+brauchte ich nur *pull* und *clone*, damit konnte ich das selbe Projekt an
+unterschiedlichen Orten halten.
+
+Später wollte ich meinen Code mit Git veröffentlichen und Änderungen von
+Mitstreitern einbinden. Ich musste lernen, wie man Projekte verwaltet, an
+denen mehrere Entwickler aus aller Welt beteiligt waren. Glücklicherweise
+ist das Git's Stärke und wohl auch seine Daseinsberechtigung.
+
+=== Wer bin ich? ===
+
+Jeder 'Commit' enthält Name und Emailadresse des Autors, welche mit *git
+log* angezeigt werden. Standardmäßig nutzt Git Systemeinstellungen um diese
+Felder auszufüllen. Um diese Angaben explizit zu setzen, gib ein:
+
+ $ git config --global user.name "Max Mustermann"
+ $ git config --global user.email maxmustermann@beispiel.de
+
+Lasse den -global Schalter weg um diese Einstellungen für das aktuelle
+'Repository' zu setzen.
+
+=== Git über SSH, HTTP ===
+
+Angenommen, Du hast einen SSH-Zugang zu einem Webserver aber Git ist nicht
+installiert. Wenn auch nicht so effizient wie mit dem systemeigenen
+Protokoll, kann Git über HTTP kommunizieren.
+
+Lade Git herunter, compiliere und installiere es unter Deinem Benutzerkonto
+und erstellen ein 'Repository' in Deinem Webverzeichnis:
+
+ $ GIT_DIR=proj.git git init
+ $ cd proj.git
+ $ git --bare update-server-info
+ $ cp hooks/post-update.sample hooks/post-update
+
+Bei älteren Git Versionen funktioniert der 'copy'-Befehl nicht, stattdessen
+gib ein:
+
+ $ chmod a+x hooks/post-update
+
+Nun kannst Du Deine letzten Änderungen über SSH von jedem 'Clone' aus
+veröffentlichen.
+
+ $ git push web.server:/pfad/zu/proj.git master
+
+und jedermann kann Dein Projekt abrufen mit:
+
+ $ git clone http://web.server/proj.git
+
+=== Git über alles ===
+
+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
+'Repositories' über jedes beliebige Medium zu transportieren, aber ein
+effizienteres Werkzeug ist *git bundle*.
+
+Der Absender erstellt ein 'bundle':
+
+ $ git bundle create einedatei HEAD
+
+und transportiert das 'Bundle' +einedatei+ irgendwie zum anderen
+Beteiligten: per eMail, USB-Stick, einen *xxd* Hexdump und einen OCR
+Scanner, Morsecode über Telefon, Rauchzeichen usw. Der Empfänger holt sich
+die 'Commits' aus dem 'Bundle' durch Eingabe von:
+
+ $ git pull einedatei
+
+Der Empfänger kann das sogar mit einem leeren 'Repository' tun. Trotz seiner
+Größe, +einedatei+ enthält das komplette original Git 'Repository'.
+
+In größeren Projekten, vermeidest Du Datenmüll indem Du nur Änderungen
+'bundlest', die in den anderen 'Repositories' fehlen. Zum Beispiel, nehmen
+wir an, der 'Commit' ``1b6d...'' ist der aktuellste, den beide Parteien
+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
+dieses Problem zu lösen. Das heißt, nachdem Du ein 'Bundle' gesendet hast,
+gib ein:
+
+ $ git tag -f letztesbundle HEAD
+
+und erstelle neue Aktuelisierungsbundles mit:
+
+ $ git bundle create neuesbundle HEAD ^letztesbundle
+
+=== Patches: Das globale Zahlungsmittel ===
+
+'Patches' sind die Klartextdarstellung Deiner Änderungen, die von Computern
+und Menschen gleichermaßen einfach verstanden werden. Dies verleiht ihnen
+eine universelle Anziehungskraft. Du kannst einen 'Patch' Entwicklern
+schicken, ganz egal, was für ein Versionsverwaltungssystem sie
+benutzen. Solange Deine Mitstreiter ihre eMails lesen können, können sie
+auch Deine Änderungen sehen. Auch auf Deiner Seite ist alles was Du brauchst
+ein eMail Konto: es gibt keine Notwendigkeit ein Online Git 'Repository'
+aufzusetzen.
+
+Erinnere Dich an das erste Kapitel:
+
+ $ git diff 1b6d > mein.patch
+
+gibt einen 'Patch' aus, der zur Diskussion einfach in eine eMail eingefügt
+werden kann. In einem Git 'Repository' gib ein:
+
+ $ git apply < mein.patch
+
+um den 'Patch' anzuwenden.
+
+In einer offizielleren Umgebung, wenn Autorennamen und eventuell Signaturen
+aufgezeichnet werden sollen, erstelle die entsprechenden 'Patches' nach
+einem bestimmten Punkt durch Eingabe von:
+
+ $ git format-patch 1b6d
+
+Die resultierenden Dateien können an *git-send-email* übergeben werden oder
+von Hand verschickt werden. Du kannst auch eine Gruppe von 'Commits'
+angeben:
+
+ $ git format-patch 1b6d..HEAD^^
+
+Auf der Empfängerseite speichere die eMail in eine Datei, dann gib ein:
+
+ $ git am < email.txt
+
+Das wendet den eingegangenen 'Patch' an und erzeugt einen 'Commit',
+inklusive der Informationen wie z.B. den Autor.
+
+Mit einer Webmail Anwendung musst Du eventuell ein Button anklicken um die
+eMail in ihrem rohen Originalformat anzuzeigen, bevor Du den 'Patch' in eine
+Datei sicherst.
+
+Es gibt geringfügige Unterschiede bei mbox-basierten eMail Anwendungen, aber
+wenn Du eine davon benutzt, gehörst Du vermutlich zu der Gruppe Personen,
+die damit einfach umgehen können ohne Anleitungen zu lesen.!
+
+=== Entschuldigung, wir sind umgezogen. ===
+
+Nach dem 'Clonen' eines 'Repositories', wird *git push* oder *git pull*
+automatisch auf die original URL zugreifen. Wie macht Git das? Das Geheimnis
+liegt in der Konfiguration, die beim 'Clonen' erzeugt wurde. Lasst uns einen
+Blick riskieren:
+
+ $ git config --list
+
+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.
+
+Wenn das original 'Repository' verschoben wird, können wir die URL
+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
+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.
+
+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
+'pull' aus anderen 'Repositories' müssen wir explizit angeben, welchen
+'Branch' wir wollen:
+
+ $ git pull git://beispiel.com/anderes.git master
+
+Das obige erklärt, warum einige von unseren früheren 'push' und 'pull'
+Beispielen keine Argumente hatten.
+
+=== Entfernte 'Branches' ===
+
+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
+einfacher für Anfänger.
+
+Zeige die entfernten 'Branches' an mit:
+
+ $ git branch -r
+
+Du solltes etwas sehen wie:
+
+ origin/HEAD
+ origin/master
+ origin/experimentell
+
+Diese Liste zeigt die 'Branches' und den HEAD des entfernten 'Repository',
+welche auch in regulären Git Anweisungen verwendet werden können. Zum
+Beispiel, angenommen Du hast viele 'Commits' gemacht und möchtest einen
+Vergleich zur letzten abgeholten Version machen. Du kannst die Logs nach dem
+entsprechenden SHA1 Hashwert durchsuchen, aber es ist viel einfacher
+folgendes einzugeben:
+
+ $ git diff origin/HEAD
+
+Oder Du kannst schauen, was auf dem 'Branch' ``experimentell'' los war:
+
+ $ git log origin/experimentell
+
+=== Mehrere 'Remotes' ===
+
+Angenommen, zwei andere Entwickler arbeiten an Deinem Projekt und wir wollen
+beide im Auge behalten. Wir können mehr als ein 'Repository' gleichzeitig
+beobachten mit:
+
+ $ git remote add other git://example.com/some_repo.git
+ $ git pull other some_branch
+
+Nun haben wir einen 'Branch' vom zweiten 'Repository' eingebunden und wir
+haben einfachen Zugriff auf alle 'Branches' von allen 'Repositories':
+
+ $ git diff origin/experimentell^ other/some_branch~5
+
+Aber was, wenn wir nur deren Änderungen vergleichen wollen, ohne unsere
+eigene Arbeit zu beeinflussen? Mit anderen Worten, wir wollen ihre
+'Branches' untersuchen ohne dass deren Änderungen in unser
+Arbeitsverzeichnis einfließen. Anstatt 'pull' benutzt Du dann:
+
+ $ git fetch # Fetch vom origin, der Standard.
+ $ git fetch other # Fetch vom zweiten Programmierer.
+
+Dies holt lediglich die Chroniken. Obwohl das Arbeitsverzeichnis unverändert
+bleibt, können wir nun jeden 'Branch' aus jedem 'Repository' in einer Git
+Anweisung referenzieren, da wir eine lokale Kopie besitzen.
+
+Erinnere Dich, dass ein 'Pull' hinter den Kulissen einfach ein *fetch*
+gefolgt von einem *merge* ist. Normalerweise machen wir einen *pull* weil
+wir die letzten 'Commits' abrufen und einbinden wollen. Die beschriebene
+Situation ist eine erwähnenswerte Ausnahme.
+
+Siehe *git help remote* um zu sehen wie man Remote-'Repositories' entfernt,
+bestimmte 'Branches' ignoriert und mehr.
+
+=== Meine Einstellungen ===
+
+Für meine Projekte bevorzuge ich es, wenn Unterstützer 'Repositories'
+vorbereiten, von denen ich 'pullen' kann. Verschiedene Git Hosting Anbieter
+lassen Dich mit einem Klick deine eigene 'Fork' eines Projekts hosten.
+
+Nachdem ich einen Zweig abgerufen habe, benutze ich Git Anweisungen um durch
+die Änderungen zu navigieren und zu untersuchen, die idealerweise gut
+organisiert und dokumentiert sind. Ich 'merge' meine eigenen Änderungen und
+führe eventuell weitere Änderungen durch. Wenn ich zufrieden bin, 'pushe'
+ich in das zentrale 'Repository'.
+
+Obwohl ich nur unregelmäßig Beiträge erhalte, glaube ich, dass diese Methode
+sich auszahlt. Siehe
+http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[diesen
+Blog Beitrag von Linus Torvalds (englisch)].
+
+In der Git Welt zu bleiben ist etwas bequemer als 'Patch'-Dateien, denn es
+erspart mir sie in Git 'Commits' zu konvertieren. Außerdem kümmert sich Git
+um die Details wie Autorname und eMail-Adresse, genauso wie um Datum und
+Uhrzeit und es fordert den Autor zum Beschreiben seiner eigenen Änderungen
+auf.
View
190 de/pot/basic.po
@@ -6,7 +6,8 @@
msgid ""
msgstr ""
"Project-Id-Version: Git Magic deutsch\n"
-"POT-Creation-Date: 2010-09-12 12:56+0300\n"
+"Report-Msgid-Bugs-To: git-magic@lordofbikes.de\n"
+"POT-Creation-Date: 2010-11-05 17:47+0100\n"
"PO-Revision-Date: 2010-11-01 22:14+0100\n"
"Last-Translator: Armin Stebich <armin@lordofbikes.de>\n"
"Language-Team: DE <gitmagic@lordofbikes.de>\n"
@@ -14,16 +15,15 @@ msgstr ""
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: UTF-8\n"
-"Report-Msgid-Bugs-To: git-magic@lordofbikes.de\n"
"Plural-Forms: \n"
#. type: Plain text
-#: basic.txt:2
+#: ../en/basic.txt:2
msgid "== Basic Tricks =="
msgstr "== Erste Schritte =="
#. type: Plain text
-#: basic.txt:6
+#: ../en/basic.txt:6
msgid ""
"Rather than diving into a sea of Git commands, use these elementary examples "
"to get your feet wet. Despite their simplicity, each of them are useful. "
@@ -36,12 +36,12 @@ msgstr ""
"mehr als in diesem Kapitel beschrieben steht."
#. type: Plain text
-#: basic.txt:8
+#: ../en/basic.txt:8
msgid "=== Saving State ==="
msgstr "=== Stand sichern ==="
#. type: Plain text
-#: basic.txt:11
+#: ../en/basic.txt:11
msgid ""
"About to attempt something drastic? Before you do, take a snapshot of all "
"files in the current directory with:"
@@ -50,7 +50,7 @@ msgstr ""
"Stand vorher lieber nochmal ab:"
#. type: Plain text
-#: basic.txt:15
+#: ../en/basic.txt:15
#, no-wrap
msgid ""
" $ git init\n"
@@ -62,36 +62,36 @@ msgstr ""
" $ git commit -m \"Meine erste Sicherung\"\n"
#. type: Plain text
-#: basic.txt:17
+#: ../en/basic.txt:17
msgid "Now if your new edits go awry, restore the pristine version:"
msgstr ""
"Falls deine Änderungen schief gehen, kannst du jetzt die alte Version "
"wiederherstellen:"
#. type: Plain text
-#: basic.txt:19
+#: ../en/basic.txt:19
#, no-wrap
msgid " $ git reset --hard\n"
msgstr " $ git reset --hard\n"
#. type: Plain text
-#: basic.txt:21
+#: ../en/basic.txt:21
msgid "To save the state again:"
msgstr "Um den neuen Stand zu sichern:"
#. type: Plain text
-#: basic.txt:23
+#: ../en/basic.txt:23
#, no-wrap
msgid " $ git commit -a -m \"Another backup\"\n"
msgstr " $ git commit -a -m \"Eine andere Sicherung\"\n"
#. type: Plain text
-#: basic.txt:25
+#: ../en/basic.txt:25
msgid "=== Add, Delete, Rename ==="
msgstr "=== Hinzufügen, Löschen, Umbenennen ==="
#. type: Plain text
-#: basic.txt:27
+#: ../en/basic.txt:27
msgid ""
"The above only keeps track of the files that were present when you first ran "
"*git add*. If you add new files or subdirectories, you'll have to tell Git:"
@@ -101,18 +101,18 @@ msgstr ""
"hinzufügst, musst du Git das mitteilen:"
#. type: Plain text
-#: basic.txt:29
+#: ../en/basic.txt:29
#, no-wrap
msgid " $ git add readme.txt Documentation\n"
msgstr " $ git add readme.txt Dokumentation\n"
#. type: Plain text
-#: basic.txt:31
+#: ../en/basic.txt:31
msgid "Similarly, if you want Git to forget about certain files:"
msgstr "Ebenso, wenn Git Dateien vergessen soll:"
#. type: Plain text
-#: basic.txt:34
+#: ../en/basic.txt:34
#, no-wrap
msgid ""
" $ git rm kludge.h obsolete.c\n"
@@ -122,12 +122,12 @@ msgstr ""
" $ git rm -r belastendes/material/\n"
#. type: Plain text
-#: basic.txt:36
+#: ../en/basic.txt:36
msgid "Git deletes these files for you if you haven't already."
msgstr "Git löscht diese Dateien für dich, falls du es noch nicht getan hast."
#. type: Plain text
-#: basic.txt:38
+#: ../en/basic.txt:38
msgid ""
"Renaming a file is the same as removing the old name and adding the new "
"name. There's also the shortcut *git mv* which has the same syntax as the "
@@ -138,18 +138,18 @@ msgstr ""
"gleiche Syntax wie *mv* hat. Zum Beispiel:"
#. type: Plain text
-#: basic.txt:40
+#: ../en/basic.txt:40
#, no-wrap
msgid " $ git mv bug.c feature.c\n"
msgstr " $ git mv fehler.c feature.c\n"
#. type: Plain text
-#: basic.txt:42
+#: ../en/basic.txt:42
msgid "=== Advanced Undo/Redo ==="
msgstr "=== Fortgeschrittenes Rückgängig machen/Wiederherstellen ==="
#. type: Plain text
-#: basic.txt:44
+#: ../en/basic.txt:44
msgid ""
"Sometimes you just want to go back and forget about every change past a "
"certain point because they're all wrong. Then:"
@@ -158,25 +158,25 @@ msgstr ""
"bestimmten Zeitpunkt verwerfen, weil sie falsch waren. Dann:"
#. type: Plain text
-#: basic.txt:46
+#: ../en/basic.txt:46
#, no-wrap
msgid " $ git log\n"
msgstr " $ git log\n"
#. type: Plain text
-#: basic.txt:48
+#: ../en/basic.txt:48
msgid "shows you a list of recent commits, and their SHA1 hashes:"
msgstr ""
"zeigt dir eine Liste der bisherigen 'Commits' und deren SHA1 Hashwerte:"
#. type: Plain text
-#: basic.txt:49
+#: ../en/basic.txt:49
#, no-wrap
msgid "----------------------------------\n"
msgstr "----------------------------------\n"
#. type: Plain text
-#: basic.txt:53
+#: ../en/basic.txt:53
#, no-wrap
msgid ""
"commit 766f9881690d240ba334153047649b8b8f11c664\n"
@@ -188,13 +188,13 @@ msgstr ""
"Date: Tue Mar 14 01:59:26 2000 -0800\n"
#. type: Plain text
-#: basic.txt:55
+#: ../en/basic.txt:55
#, no-wrap
msgid " Replace printf() with write().\n"
msgstr " Ersetze printf() mit write().\n"
#. type: Plain text
-#: basic.txt:59
+#: ../en/basic.txt:59
#, no-wrap
msgid ""
"commit 82f5ea346a2e651544956a8653c0f58dc151275c\n"
@@ -206,7 +206,7 @@ msgstr ""
"Date: Thu Jan 1 00:00:00 1970 +0000\n"
#. type: Plain text
-#: basic.txt:61
+#: ../en/basic.txt:61
#, no-wrap
msgid ""
" Initial commit.\n"
@@ -216,7 +216,7 @@ msgstr ""
"----------------------------------\n"
#. type: Plain text
-#: basic.txt:65
+#: ../en/basic.txt:65
msgid ""
"The first few characters of the hash are enough to specify the commit; "
"alternatively, copy and paste the entire hash. Type:"
@@ -226,13 +226,13 @@ msgstr ""
"Hashwert. Gib ein:"
#. type: Plain text
-#: basic.txt:67
+#: ../en/basic.txt:67
#, no-wrap
msgid " $ git reset --hard 766f\n"
msgstr " $ git reset --hard 766f\n"
#. type: Plain text
-#: basic.txt:69
+#: ../en/basic.txt:69
msgid ""
"to restore the state to a given commit and erase all newer commits from the "
"record permanently."
@@ -241,7 +241,7 @@ msgstr ""
"nachfolgenden Änderungen für immer zu löschen."
#. type: Plain text
-#: basic.txt:71
+#: ../en/basic.txt:71
msgid ""
"Other times you want to hop to an old state briefly. In this case, type:"
msgstr ""
@@ -249,13 +249,13 @@ msgstr ""
"diesem Fall, gib folgendes ein:"
#. type: Plain text
-#: basic.txt:73
+#: ../en/basic.txt:73
#, no-wrap
msgid " $ git checkout 82f5\n"
msgstr " $ git checkout 82f5\n"
#. type: Plain text
-#: basic.txt:75
+#: ../en/basic.txt:75
msgid ""
"This takes you back in time, while preserving newer commits. However, like "
"time travel in a science-fiction movie, if you now edit and commit, you will "
@@ -268,7 +268,7 @@ msgstr ""
"Änderungen sind anders als beim früheren 'Commit'."
#. type: Plain text
-#: basic.txt:77
+#: ../en/basic.txt:77
msgid ""
"This alternate reality is called a 'branch', and <<branch,we'll have more to "
"say about this later>>. For now, just remember that"
@@ -277,13 +277,13 @@ msgstr ""
"darauf zurück>>. Für jetzt, merke dir"
#. type: Plain text
-#: basic.txt:79
+#: ../en/basic.txt:79
#, no-wrap
msgid " $ git checkout master\n"
msgstr " $ git checkout master\n"
#. type: Plain text
-#: basic.txt:82
+#: ../en/basic.txt:82
msgid ""
"will take you back to the present. Also, to stop Git complaining, always "
"commit or reset your changes before running checkout."
@@ -293,12 +293,12 @@ msgstr ""
"'reseten'."
#. type: Plain text
-#: basic.txt:84
+#: ../en/basic.txt:84
msgid "To take the computer game analogy again:"
msgstr "Um wieder die Computerspielanalogie anzuwenden:"
#. type: Plain text
-#: basic.txt:86
+#: ../en/basic.txt:86
msgid ""
"- *`git reset --hard`*: load an old save and delete all saved games newer "
"than the one just loaded."
@@ -307,7 +307,7 @@ msgstr ""
"die neuer sind als der jetzt geladene."
#. type: Plain text
-#: basic.txt:88
+#: ../en/basic.txt:88
msgid ""
"- *`git checkout`*: load an old game, but if you play on, the game state "
"will deviate from the newer saves you made the first time around. Any saved "
@@ -321,7 +321,7 @@ msgstr ""
"später>>."
#. type: Plain text
-#: basic.txt:90
+#: ../en/basic.txt:90
msgid ""
"You can choose only to restore particular files and subdirectories by "
"appending them after the command:"
@@ -330,13 +330,13 @@ msgstr ""
"indem du sie an den Befehl anhängst:"
#. type: Plain text
-#: basic.txt:92
+#: ../en/basic.txt:92
#, no-wrap
msgid " $ git checkout 82f5 some.file another.file\n"
msgstr " $ git checkout 82f5 eine.datei andere.datei\n"
#. type: Plain text
-#: basic.txt:96
+#: ../en/basic.txt:96
msgid ""
"Take care, as this form of *checkout* can silently overwrite files. To "
"prevent accidents, commit before running any checkout command, especially "
@@ -350,18 +350,18 @@ msgstr ""
"irgendeine andere Operation, führe zuerst *git commit -a* aus."
#. type: Plain text
-#: basic.txt:98
+#: ../en/basic.txt:98
msgid "Don't like cutting and pasting hashes? Then use:"
msgstr "Du magst Kopieren und Einfügen von Hashes nicht? Dann nutze:"
#. type: Plain text
-#: basic.txt:100
+#: ../en/basic.txt:100
#, no-wrap
msgid " $ git checkout :/\"My first b\"\n"
msgstr " $ git checkout :/\"Meine erste Si\"\n"
#. type: Plain text
-#: basic.txt:103
+#: ../en/basic.txt:103
msgid ""
"to jump to the commit that starts with a given message. You can also ask "
"for the 5th-last saved state:"
@@ -370,18 +370,18 @@ msgstr ""
"auch nach dem 5. letzten 'Commit' fragen:"
#. type: Plain text
-#: basic.txt:105
+#: ../en/basic.txt:105
#, no-wrap
msgid " $ git checkout master~5\n"
msgstr " $ git checkout master~5\n"
#. type: Plain text
-#: basic.txt:107
+#: ../en/basic.txt:107
msgid "=== Reverting ==="
msgstr "=== Rückgängig machen ==="
#. type: Plain text
-#: basic.txt:109
+#: ../en/basic.txt:109
msgid ""
"In a court of law, events can be stricken from the record. Likewise, you can "
"pick specific commits to undo."
@@ -390,7 +390,7 @@ msgstr ""
"Ähnlich kannst du gezielt 'Commits' rückgängig machen."
#. type: Plain text
-#: basic.txt:112
+#: ../en/basic.txt:112
#, no-wrap
msgid ""
" $ git commit -a\n"
@@ -400,7 +400,7 @@ msgstr ""
" $ git revert 1b6d\n"
#. type: Plain text
-#: basic.txt:115
+#: ../en/basic.txt:115
msgid ""
"will undo just the commit with the given hash. The revert is recorded as a "
"new commit, which you can confirm by running *git log*."
@@ -410,12 +410,12 @@ msgstr ""
"überprüft werden kann."
#. type: Plain text
-#: basic.txt:117
+#: ../en/basic.txt:117
msgid "=== Changelog Generation ==="
msgstr "=== Changelog erstellen ==="
#. type: Plain text
-#: basic.txt:120
+#: ../en/basic.txt:120
msgid ""
"Some projects require a http://en.wikipedia.org/wiki/Changelog[changelog]. "
"Generate one by typing:"
@@ -425,52 +425,52 @@ msgstr ""
"Befehl erstellen:"
#. type: Plain text
-#: basic.txt:122
+#: ../en/basic.txt:122
#, no-wrap
msgid " $ git log > ChangeLog\n"
msgstr " $ git log > ChangeLog\n"
#. type: Plain text
-#: basic.txt:124
+#: ../en/basic.txt:124
msgid "=== Downloading Files ==="
msgstr "=== Dateien herunterladen ==="
#. type: Plain text
-#: basic.txt:126
+#: ../en/basic.txt:126
msgid "Get a copy of a project managed with Git by typing:"
msgstr "Eine Kopie eines mit Git verwalteten Projekts bekommst du mit:"
#. type: Plain text
-#: basic.txt:128
+#: ../en/basic.txt:128
#, no-wrap
msgid " $ git clone git://server/path/to/files\n"
msgstr " $ git clone git://server/pfad/zu/dateien\n"
#. type: Plain text
-#: basic.txt:130
+#: ../en/basic.txt:130
msgid "For example, to get all the files I used to create this site:"
msgstr ""
"Um zum Beispiel alle Dateien zu bekommen, die ich zum Erzeugen dieser Seiten "
"benutze:"
#. type: Plain text
-#: basic.txt:132
+#: ../en/basic.txt:132
#, no-wrap
msgid " $ git clone git://git.or.cz/gitmagic.git\n"
msgstr " $ git clone git://git.or.cz/gitmagic.git\n"
#. type: Plain text
-#: basic.txt:134
+#: ../en/basic.txt:134
msgid "We'll have much to say about the *clone* command soon."
msgstr "Es gibt gleich noch viel mehr über den 'clone' Befehl zu sagen."
#. type: Plain text
-#: basic.txt:136
+#: ../en/basic.txt:136
msgid "=== The Bleeding Edge ==="
msgstr "=== Das Neueste vom Neuen ==="
#. type: Plain text
-#: basic.txt:138
+#: ../en/basic.txt:138
msgid ""
"If you've already downloaded a copy of a project using *git clone*, you can "
"upgrade to the latest version with:"
@@ -479,18 +479,18 @@ msgstr ""
"Version aktualisieren mit:"
#. type: Plain text
-#: basic.txt:140 basic.txt:166
+#: ../en/basic.txt:140 ../en/basic.txt:166
#, no-wrap
msgid " $ git pull\n"
msgstr " $ git pull\n"
#. type: Plain text
-#: basic.txt:142
+#: ../en/basic.txt:142
msgid "=== Instant Publishing ==="
msgstr "=== Einfaches Veröffentlichen ==="
#. type: Plain text
-#: basic.txt:144
+#: ../en/basic.txt:144
msgid ""
"Suppose you've written a script you'd like to share with others. You could "
"just tell them to download from your computer, but if they do so while "
@@ -507,12 +507,12 @@ msgstr ""
"veröffentlichen den Code aber nur, wenn sie ihn für vorzeigbar halten."
#. type: Plain text
-#: basic.txt:146
+#: ../en/basic.txt:146
msgid "To do this with Git, in the directory where your script resides:"
msgstr "Um dies in Git zu tun, gehe ins Verzeichnis in dem das Skript liegt:"
#. type: Plain text
-#: basic.txt:150
+#: ../en/basic.txt:150
#, no-wrap
msgid ""
" $ git init\n"
@@ -524,18 +524,18 @@ msgstr ""
" $ git commit -m \"Erster Stand\"\n"
#. type: Plain text
-#: basic.txt:152
+#: ../en/basic.txt:152
msgid "Then tell your users to run:"
msgstr "Dann sage deinen Nutzern:"
#. type: Plain text
-#: basic.txt:154
+#: ../en/basic.txt:154
#, no-wrap
msgid " $ git clone your.computer:/path/to/script\n"
msgstr " $ git clone dein.computer:/pfad/zum/skript\n"
#. type: Plain text
-#: basic.txt:156
+#: ../en/basic.txt:156
msgid ""
"to download your script. This assumes they have ssh access. If not, run *git "
"daemon* and tell your users to instead run:"
@@ -544,31 +544,31 @@ msgstr ""
"haben. Falls nicht, führe *git deamon* aus und sage den Nutzern folgendes:"
#. type: Plain text
-#: basic.txt:158
+#: ../en/basic.txt:158
#, no-wrap
msgid " $ git clone git://your.computer/path/to/script\n"
msgstr " $ git clone git://dein.computer/pfad/zum/skript\n"
#. type: Plain text
-#: basic.txt:160
+#: ../en/basic.txt:160
msgid "From now on, every time your script is ready for release, execute:"
msgstr "Ab jetzt, immer wenn dein Skript reif für eine Veröffentlichung ist:"
#. type: Plain text
-#: basic.txt:162
+#: ../en/basic.txt:162
#, no-wrap
msgid " $ git commit -a -m \"Next release\"\n"
msgstr " $ git commit -a -m \"Nächster Stand\"\n"
#. type: Plain text
-#: basic.txt:164
+#: ../en/basic.txt:164
msgid ""
"and your users can upgrade their version by changing to the directory "
"containing your script and typing:"
msgstr "und deine Nutzer können ihr Skript aktualisieren mit:"
#. type: Plain text
-#: basic.txt:168
+#: ../en/basic.txt:168
msgid ""
"Your users will never end up with a version of your script you don't want "
"them to see."
@@ -578,45 +578,45 @@ msgstr ""
"Skripts."
#. type: Plain text
-#: basic.txt:170
+#: ../en/basic.txt:170
msgid "=== What Have I Done? ==="
msgstr "=== Was habe ich getan? ==="
#. type: Plain text
-#: basic.txt:172
+#: ../en/basic.txt:172
msgid "Find out what changes you've made since the last commit with:"
msgstr "Finde heraus was du seit dem letzten 'Commit' getan hast:"
#. type: Plain text
-#: basic.txt:174
+#: ../en/basic.txt:174
#, no-wrap
msgid " $ git diff\n"
msgstr " $ git diff\n"
#. type: Plain text
-#: basic.txt:176
+#: ../en/basic.txt:176
msgid "Or since yesterday:"
msgstr "Oder seit Gestern:"
#. type: Plain text
-#: basic.txt:178
+#: ../en/basic.txt:178
#, no-wrap
msgid " $ git diff \"@{yesterday}\"\n"
msgstr " $ git diff \"@{gestern}\"\n"
#. type: Plain text
-#: basic.txt:180
+#: ../en/basic.txt:180
msgid "Or between a particular version and 2 versions ago:"
msgstr "Oder zwischen irgendeiner Version und der vorvorletzten:"
#. type: Plain text
-#: basic.txt:182
+#: ../en/basic.txt:182
#, no-wrap
msgid " $ git diff 1b6d \"master~2\"\n"
msgstr " $ git diff 1b6d \"master~2\"\n"
#. type: Plain text
-#: basic.txt:185
+#: ../en/basic.txt:185
msgid ""
"In each case the output is a patch that can be applied with *git apply*. "
"Try also:"
@@ -625,13 +625,13 @@ msgstr ""
"kann. Versuche auch:"
#. type: Plain text
-#: basic.txt:187
+#: ../en/basic.txt:187
#, no-wrap
msgid " $ git whatchanged --since=\"2 weeks ago\"\n"
msgstr " $ git whatchanged --since=\"2 weeks ago\"\n"
#. type: Plain text
-#: basic.txt:193
+#: ../en/basic.txt:193
msgid ""
"Often I'll browse history with http://sourceforge.net/projects/qgit[qgit] "
"instead, due to its slick photogenic interface, or http://jonas.nitro.dk/tig/"
@@ -647,12 +647,12 @@ msgstr ""
"kannst du mit jedem Webbrowser darauf zugreifen."
#. type: Plain text
-#: basic.txt:195
+#: ../en/basic.txt:195
msgid "=== Exercise ==="
msgstr "=== Übung ==="
#. type: Plain text
-#: basic.txt:197
+#: ../en/basic.txt:197
msgid ""
"Let A, B, C, D be four successive commits where B is the same as A except "
"some files have been removed. We want to add the files back at D. How can we "
@@ -663,12 +663,12 @@ msgstr ""
"wieder hinzufügen, aber nicht in B. Wie machen wir das?"
#. type: Plain text
-#: basic.txt:199
+#: ../en/basic.txt:199
msgid "There are at least three solutions. Assuming we are at D:"
msgstr "Es gibt mindestens 3 Lösungen. Angenommen, wir sind bei D:"
#. type: Bullet: ' 1. '
-#: basic.txt:201
+#: ../en/basic.txt:201
msgid ""
"The difference between A and B are the removed files. We can create a patch "
"representing this difference and apply it:"
@@ -678,39 +678,39 @@ msgstr ""
"auf D anwenden:"
#. type: Plain text
-#: basic.txt:203
+#: ../en/basic.txt:203
#, no-wrap
msgid " $ git diff B A | git apply\n"
msgstr " $ git diff B A | git apply\n"
#. type: Bullet: ' 2. '
-#: basic.txt:205
+#: ../en/basic.txt:205
msgid "Since we saved the files back at A, we can retrieve them:"
msgstr ""
"Da die Dateien im 'Repository' unter dem 'Commit' A gespeichert sind, können "
"wir sie wieder herstellen:"
#. type: Plain text
-#: basic.txt:207
+#: ../en/basic.txt:207
#, no-wrap
msgid " $ git checkout A foo.c bar.h\n"
msgstr " $ git checkout A foo.c bar.h\n"
#. type: Bullet: ' 3. '
-#: basic.txt:209
+#: ../en/basic.txt:209
msgid "We can view going from A to B as a change we want to undo:"
msgstr ""
"Wir können den 'Commit' von A auf B als Änderung betrachten, die wir "
"rückgängig machen wollen:"
#. type: Plain text
-#: basic.txt:211
+#: ../en/basic.txt:211
#, no-wrap
msgid " $ git revert B\n"
msgstr " $ git revert B\n"
#. type: Plain text
-#: basic.txt:212
+#: ../en/basic.txt:212
msgid ""
"Which choice is best? Whichever you prefer most. It is easy to get what you "
"want with Git, and often there are many ways to get it."
View
261 de/pot/branch.po
@@ -2,29 +2,33 @@
# This file is distributed under the GNU GENERAL PUBLIC LICENSE Version 3.
# Benn Lynn <benlynn@gmail.com>, 2007.
# Armin Stebich <armin@lordofbikes.de>, 2010.
+#
msgid ""
msgstr ""
"Project-Id-Version: Git Magic deutsch\n"
"Report-Msgid-Bugs-To: bennlynn@gmail.com\n"
"POT-Creation-Date: 2010-10-30 08:21+0300\n"
-"PO-Revision-Date: 2010-10-26 18:38+0300\n"
+"PO-Revision-Date: 2010-11-05 22:03+0100\n"
"Last-Translator: Armin Stebich <armin@lordofbikes.de>\n"
-"Language-Team: de <git-magic@lordofbikes.de>\n"
+"Language-Team: DE <gitmagic@lordofbikes.de>\n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
+"Content-Transfer-Encoding: UTF-8\n"
+"Plural-Forms: \n"
#. type: Plain text
#: ../en/branch.txt:2
msgid "== Branch Wizardry =="
-msgstr ""
+msgstr "== 'Branch'-Magie =="
#. type: Plain text
#: ../en/branch.txt:4
msgid ""
"Instant branching and merging are the most lethal of Git's killer features."
msgstr ""
+"Unverzügliches 'Branchen' und 'Mergen' sind die hervorstechenden "
+"Eigenschaften von Git."
#. type: Plain text
#: ../en/branch.txt:8
@@ -33,7 +37,7 @@ msgid ""
"*Problem*: External factors inevitably necessitate context switching. A severe\n"
"bug manifests in the released version without warning. The deadline for a\n"
"certain feature is moved closer. A developer whose help you need for a key section of the project is about to leave. In all cases, you must abruptly drop what you are doing and focus on a completely different task.\n"
-msgstr ""
+msgstr "*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.\n"
#. type: Plain text
#: ../en/branch.txt:10
@@ -44,6 +48,11 @@ msgid ""
"central server. Distributed systems fare better, as we can clone the desired "
"version locally."
msgstr ""
+"Den Gedankengang zu unterbrechen ist schlecht für die Produktivität und je "
+"komplizierter der Kontextwechsel ist, desto größer ist der Verlust. Mit "
+"zentraler Versionsverwaltung müssen wir eine neue Arbeitskopie vom Server "
+"herunterladen. Bei verteilen Systemen ist das viel besser, da wir die "
+"benötigt Version lokal 'clonen' können."
#. type: Plain text
#: ../en/branch.txt:12
@@ -53,12 +62,16 @@ msgid ""
"this with file sharing and hard links, the project files themselves must be "
"recreated in their entirety in the new working directory."
msgstr ""
+"Doch das 'Clonen' bringt das Kopieren des gesamten Arbeitsverzeichnis wie "
+"auch die ganze Geschichte bis zum angegebenen Punkt mit sich. Auch wenn Git "
+"die Kosten durch Dateifreigaben und Verknüpfungen reduziert, müssen doch die "
+"gesamten Projektdateien im neuen Arbeitsverzeichnis erstellt werden."
#. type: Plain text
#: ../en/branch.txt:14
#, no-wrap
msgid "*Solution*: Git has a better tool for these situations that is much faster and more space-efficient than cloning: *git branch*.\n"
-msgstr ""
+msgstr "*Lösung*: Git hat ein besseres Werkzeug für diese Situationen, die wesentlich schneller und platzsparender als 'clonen' ist: *git branch*.\n"
#. type: Plain text
#: ../en/branch.txt:16
@@ -69,11 +82,17 @@ msgid ""
"experimental version to the current development version to your friend's "
"version and so on."
msgstr ""
+"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 "
+"weiter."
#. type: Plain text
#: ../en/branch.txt:18
msgid "=== The Boss Key ==="
-msgstr ""
+msgstr "=== Die Chef-Taste ==="
#. type: Plain text
#: ../en/branch.txt:20
@@ -83,11 +102,15 @@ msgid ""
"the boss walked in the office while you were playing the game you could "
"quickly hide it away?"
msgstr ""
+"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?"
#. type: Plain text
#: ../en/branch.txt:22
msgid "In some directory:"
-msgstr ""
+msgstr "In irgendeinem Verzeichnis:"
#. type: Plain text
#: ../en/branch.txt:27
@@ -98,6 +121,10 @@ msgid ""
" $ git add .\n"
" $ git commit -m \"Initial commit\"\n"
msgstr ""
+" $ echo \"Ich bin klüger als mein Chef\" > meinedatei.txt\n"
+" $ git init\n"
+" $ git add .\n"
+" $ git commit -m \"Erster Stand\"\n"
#. type: Plain text
#: ../en/branch.txt:29
@@ -105,6 +132,8 @@ msgid ""
"We have created a Git repository that tracks one text file containing a "
"certain message. Now type:"
msgstr ""
+"Wir haben ein Git 'Repository' erstellt, das eine Textdatei mit einer "
+"bestimmten Nachricht enthält. Nun gib ein:"
#. type: Plain text
#: ../en/branch.txt:33
@@ -114,6 +143,9 @@ msgid ""
" $ echo \"My boss is smarter than me\" > myfile.txt\n"
" $ git commit -a -m \"Another commit\"\n"
msgstr ""
+" $ git checkout -b chef # scheinbar hat sich danach nichts geändert\n"
+" $ echo \"Mein Chef ist klüger als ich\" > meinedatei.txt\n"
+" $ git commit -a -m \"Ein anderer Stand\"\n"
#. type: Plain text
#: ../en/branch.txt:35
@@ -121,12 +153,14 @@ msgid ""
"It looks like we've just overwritten our file and committed it. But it's an "
"illusion. Type:"
msgstr ""
+"Es sieht aus als hätten wir unsere Datei überschrieben und 'commitet'. Aber "
+"es ist eine Illusion. Tippe:"
#. type: Plain text
#: ../en/branch.txt:37
#, no-wrap
msgid " $ git checkout master # switch to original version of the file\n"
-msgstr ""
+msgstr " $ git checkout master # wechsle zur Originalversion der Datei\n"
#. type: Plain text
#: ../en/branch.txt:39
@@ -134,12 +168,14 @@ msgid ""
"and hey presto! The text file is restored. And if the boss decides to snoop "
"around this directory, type:"
msgstr ""
+"und Simsalabim! Die Textdatei ist wiederhergestellt. Und wenn der Chef in "
+"diesem Verzeichnis herumschnüffelt, tippe:"
#. type: Plain text
#: ../en/branch.txt:41
#, no-wrap
msgid " $ git checkout boss # switch to version suitable for boss' eyes\n"
-msgstr ""
+msgstr " $ git checkout chef # wechsle zur Version die der Chef ruhig sehen kann\n"
#. type: Plain text
#: ../en/branch.txt:43
@@ -147,11 +183,13 @@ msgid ""
"You can switch between the two versions of the file as much as you like, and "
"commit to each independently."
msgstr ""
+"Du kannst zwischen den beiden Versionen wechseln, so oft du willst und du "
+"kannst unabhängig voneinander in jeder Version Änderungen 'commiten'"
#. type: Plain text
#: ../en/branch.txt:45
msgid "=== Dirty Work ==="
-msgstr ""
+msgstr "=== Schmutzarbeit ==="
#. type: Plain text
#: ../en/branch.txt:48
@@ -160,6 +198,9 @@ msgid ""
"to go back three versions and temporarily put in a few print statements to "
"see how something works. Then:"
msgstr ""
+"[[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:"
#. type: Plain text
#: ../en/branch.txt:51
@@ -168,6 +209,8 @@ msgid ""
" $ git commit -a\n"
" $ git checkout HEAD~3\n"
msgstr ""
+" $ git commit -a\n"
+" $ git checkout HEAD~3\n"
#. type: Plain text
#: ../en/branch.txt:53
@@ -175,12 +218,14 @@ msgid ""
"Now you can add ugly temporary code all over the place. You can even commit "
"these changes. When you're done,"
msgstr ""
+"Nun kannst du überall wild temporären Code hinzufügen. Du kannst diese "
+"Änderungen sogar 'commiten'. Wenn du fertig bist,"
#. type: Plain text
#: ../en/branch.txt:55
#, no-wrap
msgid " $ git checkout master\n"
-msgstr ""
+msgstr " $ git checkout master\n"
#. type: Plain text
#: ../en/branch.txt:57
@@ -188,17 +233,20 @@ msgid ""
"to return to your original work. Observe that any uncommitted changes are "
"carried over."
msgstr ""
+"um zur ursprünglichen Arbeit zurückzukehren. Beachte, dass alle Änderungen, "
+"die nicht 'commitet' sind übernommen werden."
#. type: Plain text
#: ../en/branch.txt:59
msgid "What if you wanted to save the temporary changes after all? Easy:"
msgstr ""
+"Was, wenn du am Ende die temporären Änderungen sichern willst? Einfach:"
#. type: Plain text
#: ../en/branch.txt:61
#, no-wrap
msgid " $ git checkout -b dirty\n"
-msgstr ""
+msgstr " $ git checkout -b schmutzig\n"
#. type: Plain text
#: ../en/branch.txt:63
@@ -206,12 +254,14 @@ msgid ""
"and commit before switching back to the master branch. Whenever you want to "
"return to the dirty changes, simply type:"
msgstr ""
+"und 'commite' bevor du auf den 'Master Branch' zurückschaltest. Wann immer "
+"du zu deiner Schmutzarbeit zurückkehren willst, tippe einfach:"
#. type: Plain text
#: ../en/branch.txt:65
#, no-wrap
msgid " $ git checkout dirty\n"
-msgstr ""
+msgstr " $ git checkout schnmutzig\n"
#. type: Plain text
#: ../en/branch.txt:67
@@ -221,6 +271,12 @@ msgid ""
"requested state, but we must leave the master branch. Any commits made from "
"now on take your files down a different road, which can be named later."
msgstr ""
+"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 "
+"Namen geben können."
#. type: Plain text
#: ../en/branch.txt:69
@@ -229,11 +285,14 @@ msgid ""
"in a new, unnamed branch, which can be named and saved with *git checkout -"
"b*."
msgstr ""
+"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."
#. type: Plain text
#: ../en/branch.txt:71
msgid "=== Quick Fixes ==="
-msgstr ""
+msgstr "=== Schnelle Fehlerbehebung ==="
#. type: Plain text
#: ../en/branch.txt:73
@@ -241,6 +300,8 @@ msgid ""
"You're in the middle of something when you are told to drop everything and "
"fix a newly discovered bug in commit `1b6d...`:"
msgstr ""
+"Du steckst mitten in der Arbeit, als es heißt alles fallen zu lassen um "
+"einen neu entdeckten Fehler in 'Commit' `1b6d...` zu beheben:"
#. type: Plain text
#: ../en/branch.txt:76
@@ -249,11 +310,13 @@ msgid ""
" $ git commit -a\n"
" $ git checkout -b fixes 1b6d\n"
msgstr ""
+" $ git commit -a\n"
+" $ git checkout -b fixes 1b6d\n"
#. type: Plain text
#: ../en/branch.txt:78
msgid "Then once you've fixed the bug:"
-msgstr ""
+msgstr "Dann, wenn du den Fehler behoben hast:"
#. type: Plain text
#: ../en/branch.txt:82
@@ -263,43 +326,49 @@ msgid ""
" $ git push # to the central repository\n"
" $ git checkout master\n"
msgstr ""
+" $ git commit -a -m \"Fehler behoben\"\n"
+" $ git push # ins zentrale 'Repository'\n"
+" $ git checkout master\n"
#. type: Plain text
#: ../en/branch.txt:84
msgid "and resume work on your original task."
-msgstr ""
+msgstr "und fahre mit deiner ursprünglichen Arbeit fort."
#. type: Plain text
#: ../en/branch.txt:86
msgid "You can even 'merge' in the bugfix you just made, either by typing:"
msgstr ""
+"Du kannst die Fehlerbehebung, die du gerade gemacht hast, auch 'mergen'. "
+"Entweder durch:"
#. type: Plain text
#: ../en/branch.txt:88
#, no-wrap
msgid " $ git merge fixes\n"
-msgstr ""
+msgstr " $ git merge fixes\n"
#. type: Plain text
#: ../en/branch.txt:90
msgid "or:"
-msgstr ""
+msgstr "oder:"
#. type: Plain text
#: ../en/branch.txt:92
#, no-wrap
msgid " $ git pull\n"
-msgstr ""
+msgstr " $ git pull\n"
#. type: Plain text
#: ../en/branch.txt:94
msgid "since you have already pushed the bugfix to the main repository."
msgstr ""
+"da du die Fehlerbehebung schon ins zentrale 'Repository' ge'pushed' hast."
#. type: Plain text
#: ../en/branch.txt:96
msgid "=== Merging ==="
-msgstr ""
+msgstr "=== 'Mergen' ==="
#. type: Plain text
#: ../en/branch.txt:100
@@ -308,6 +377,9 @@ msgid ""
"them back together is tough. With Git, merging is so trivial that you might "
"be unaware of it happening."
msgstr ""
+"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."
#. type: Plain text
#: ../en/branch.txt:106
@@ -319,6 +391,13 @@ msgid ""
"if you do have local changes, Git will automatically merge, and report any "
"conflicts."
msgstr ""
+"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 "
+"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 "
+"Konflikte melden."
#. type: Plain text
#: ../en/branch.txt:111
@@ -328,6 +407,11 @@ msgid ""
"parents. This begs the question: what commit does `HEAD~10` really refer "
"to? A commit could have multiple parents, so which one do we follow?"
msgstr ""
+"Normalerweise hat ein 'Commit' genau einen Eltern-'Commit', nämlich den "
+"vorhergehenden 'Commit'. Das 'Mergen' mehrerer 'Branches' erzeugt einen "
+"'Commit' mit mindestens zwei Eltern. Das wirft die Frage auf: Welchen "
+"'Commit' referenziert `HEAD~10` tatsächlich? Ein 'Commit' kann mehrere "
+"Eltern haben, welchem folgen wir also?"
#. type: Plain text
#: ../en/branch.txt:116
@@ -337,6 +421,11 @@ msgid ""
"merge; frequently you're only concerned with the changes you made in the "
"current branch, as opposed to changes merged in from other branches."
msgstr ""
+"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 "
+"die von anderen 'Branches' eingebracht wurden."
#. type: Plain text
#: ../en/branch.txt:119
@@ -344,12 +433,14 @@ msgid ""
"You can refer to a specific parent with a caret. For example, to show the "
"logs from the second parent:"
msgstr ""
+"Du kannst einen bestimmten Elternteil mit einem Caret-Zeichen referenzieren. "
+"Um zum Beispiel die Logs vom zweiten Elternteil anzuzeigen:"
#. type: Plain text
#: ../en/branch.txt:121
#, no-wrap
msgid " $ git log HEAD^2\n"
-msgstr ""
+msgstr " $ git log HEAD^2\n"
#. type: Plain text
#: ../en/branch.txt:124
@@ -357,23 +448,25 @@ msgid ""
"You may omit the number for the first parent. For example, to show the "
"differences with the first parent:"
msgstr ""
+"Du kannst die Nummer für den ersten Elternteil weglassen. Um zum Beispiel "
+"die Unterschiede zum ersten Elternteil anzuzeigen:"
#. type: Plain text
#: ../en/branch.txt:126
#, no-wrap
msgid " $ git diff HEAD^\n"
-msgstr ""
+msgstr " $ git diff HEAD^\n"
#. type: Plain text
#: ../en/branch.txt:128
msgid "You can combine this notation with other types. For example:"
-msgstr ""
+msgstr "Du kannst diese Notation mit anderen Typen kombinieren. Zum Beispiel:"
#. type: Plain text
#: ../en/branch.txt:130
#, no-wrap
msgid " $ git checkout 1b6d^^2~10 -b ancient\n"
-msgstr ""
+msgstr " $ git checkout 1b6d^^2~10 -b uralt\n"
#. type: Plain text
#: ../en/branch.txt:133
@@ -381,11 +474,14 @@ msgid ""
"starts a new branch ``ancient'' representing the state 10 commits back from "
"the second parent of the first parent of the commit starting with 1b6d."
msgstr ""
+"beginnt einen neuen 'Branch' ``uralt'', welcher den Stand 10 'Commits' "
+"zurück vom zweiten Elternteil des ersten Elternteil des 'Commits', dessen "
+"Hashwert mit 1b6d beginnt."
#. type: Plain text
#: ../en/branch.txt:135
msgid "=== Uninterrupted Workflow ==="
-msgstr ""
+msgstr "=== Kontinuierlicher Arbeitsfluss ==="
#. type: Plain text
#: ../en/branch.txt:137
@@ -395,6 +491,11 @@ msgid ""
"garage until a particular part arrives from the factory. A prototype might "
"wait for a chip to be fabricated before construction can continue."
msgstr ""
+"In Herstellungsprozessen muss der zweiter 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 "
+"Konstruktion fortgesetzt werden kann."
#. type: Plain text
#: ../en/branch.txt:142
@@ -404,6 +505,11 @@ msgid ""
"require your code to be reviewed before accepting it, so you might wait "
"until the first part is approved before starting the second part."
msgstr ""
+"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."
#. type: Plain text
#: ../en/branch.txt:147
@@ -413,12 +519,16 @@ msgid ""
"and sent it for review. Let's say you're in the `master` branch. Then branch "
"off:"
msgstr ""
+"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 II:"
#. type: Plain text
#: ../en/branch.txt:149
#, no-wrap
msgid " $ git checkout -b part2\n"
-msgstr ""
+msgstr " $ git checkout -b teil2\n"
#. type: Plain text
#: ../en/branch.txt:153
@@ -427,6 +537,10 @@ msgid ""
"human, and often you'll want to go back and fix something in Part I. If "
"you're lucky, or very good, you can skip these lines."
msgstr ""
+"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."
#. type: Plain text
#: ../en/branch.txt:159
@@ -438,11 +552,16 @@ msgid ""
" $ git checkout part2 # Go back to Part II.\n"
" $ git merge master # Merge in those fixes.\n"
msgstr ""
+" $ git checkout master # Gehe zurück zu Teil I.\n"
+" $ fix_problem\n"
+" $ git commit -a # 'Commite' die Lösung.\n"
+" $ git checkout teil2 # Gehe zurück zu Teil II.\n"
+" $ git merge master # 'Merge' die Lösung.\n"
#. type: Plain text
#: ../en/branch.txt:161
msgid "Eventually, Part I is approved:"
-msgstr ""
+msgstr "Schließlich, Teil I ist zugelassen:"
#. type: Plain text
#: ../en/branch.txt:166
@@ -453,6 +572,10 @@ msgid ""
" $ git merge part2 # Merge in Part II.\n"
" $ git branch -d part2\n"
msgstr ""
+" $ git checkout master # Gehe zurück zu Teil I.\n"
+" $ submit files # Veröffentliche deine Dateien!\n"
+" $ git merge teil2 # 'Merge' in Teil II.\n"
+" $ git branch -d teil2\n"
#. type: Plain text
#: ../en/branch.txt:168
@@ -460,6 +583,7 @@ msgid ""
"Now you're in the `master` branch again, with Part II in the working "
"directory."
msgstr ""
+"Nun bist du wieder im `master` 'Branch', mit Teil II im Arbeitsverzeichnis."
#. type: Plain text
#: ../en/branch.txt:172
@@ -468,6 +592,10 @@ msgid ""
"branch off retroactively: suppose you belatedly realize you should have "
"created a branch 7 commits ago. Then type:"
msgstr ""
+"Es ist einfach, diesen Trick auf eine beliebige Anzahl von Teilen zu "
+"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:"
#. type: Plain text
#: ../en/branch.txt:176
@@ -477,6 +605,9 @@ msgid ""
" $ # Rename \"master\" branch to \"part2\".\n"
" $ git checkout HEAD~7 -b master\n"
msgstr ""
+" $ git branch -m master teil2\n"
+" $ # Umbenennen des 'Branch' \"master\" zu \"teil2\".\n"
+" $ git checkout HEAD~7 -b master\n"
#. type: Plain text
#: ../en/branch.txt:179
@@ -484,11 +615,13 @@ msgid ""
"The `master` branch now contains just Part I, and the `part2` branch "
"contains the rest."
msgstr ""
+"Der `master` 'Branch' enthält nun nur den Teil I und der `teil2` 'Branch' "
+"enthält den Rest."
#. type: Plain text
#: ../en/branch.txt:181
msgid "=== Reorganizing a Medley ==="
-msgstr ""
+msgstr "=== Mischmasch Reorganisieren ==="
#. type: Plain text
#: ../en/branch.txt:183
@@ -498,6 +631,10 @@ msgid ""
"commits only when they have been neatly organized. Start a couple of "
"branches:"
msgstr ""
+"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':"
#. type: Plain text
#: ../en/branch.txt:186
@@ -506,6 +643,8 @@ msgid ""
" $ git checkout -b sanitized\n"
" $ git checkout -b medley\n"
msgstr ""
+" $ git checkout -b bereinigt\n"
+" $ git checkout -b mischmasch\n"
#. type: Plain text
#: ../en/branch.txt:188
@@ -513,6 +652,9 @@ msgid ""
"Next, work on anything: fix bugs, add features, add temporary code, and so "
"forth, committing often along the way. Then:"
msgstr ""
+"Fahre fort alles zu bearbeiten: Behebe Fehler, füge Funktionen hinzu, "
+"erstelle temporären Code und so weiter und 'commite' deine Änderungen oft. "
+"Dann:"
#. type: Plain text
#: ../en/branch.txt:191
@@ -521,6 +663,8 @@ msgid ""
" $ git checkout sanitized\n"
" $ git cherry-pick medley^^\n"
msgstr ""
+" $ git checkout bereinigt\n"
+" $ git cherry-pick mischmasch^^\n"
#. type: Plain text
#: ../en/branch.txt:193
@@ -530,22 +674,26 @@ msgid ""
"branch that contains only permanent code, and has related commits grouped "
"together."
msgstr ""
+"wendet den Urahn des obersten 'Commit' des ``mischmasch'' 'Branch' auf den "
+"``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."
#. type: Plain text
#: ../en/branch.txt:195
msgid "=== Managing Branches ==="
-msgstr ""
+msgstr "=== 'Branches' verwalten ==="
#. type: Plain text
#: ../en/branch.txt:197
msgid "List all branches by typing:"
-msgstr ""
+msgstr "Ein Liste aller 'Branches' bekommst du mit:"
#. type: Plain text
#: ../en/branch.txt:199
#, no-wrap
msgid " $ git branch\n"
-msgstr ""
+msgstr " $ git branch\n"
#. type: Plain text
#: ../en/branch.txt:202
@@ -553,6 +701,9 @@ msgid ""
"By default, you start in a branch named ``master''. Some advocate leaving "
"the ``master'' branch untouched and creating new branches for your own edits."
msgstr ""
+"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."
#. type: Plain text
#: ../en/branch.txt:205
@@ -560,6 +711,8 @@ msgid ""
"The *-d* and *-m* options allow you to delete and move (rename) branches. "
"See *git help branch*."
msgstr ""
+"Die *-d* und *-m* Optionen erlauben dir 'Branches' zu löschen und zu "
+"verschieben (umzubenennen). Siehe *git help branch*."
#. type: Plain text
#: ../en/branch.txt:210
@@ -569,11 +722,16 @@ msgid ""
"version of your project. Although you can rename or obliterate the "
"``master'' branch, you might as well respect this convention."
msgstr ""
+"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 "
+"respektieren."
#. type: Plain text
#: ../en/branch.txt:212
msgid "=== Temporary Branches ==="
-msgstr ""
+msgstr "=== Temporäre 'Branches' ==="
#. type: Plain text
#: ../en/branch.txt:217
@@ -583,6 +741,11 @@ msgid ""
"current state so you can briefly hop back to an older state to fix a high-"
"priority bug or something."
msgstr ""
+"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 "
+"irgendetwas anderes."
#. type: Plain text
#: ../en/branch.txt:222
@@ -592,12 +755,17 @@ msgid ""
"out, merge, and delete temporary branches. Luckily, Git has a shortcut that "
"is as convenient as a TV remote control:"
msgstr ""
+"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 "
+"genauso komfortabel ist wie eine Fernbedienung:"
#. type: Plain text
#: ../en/branch.txt:224
#, no-wrap