Git Magic deutsch - en to de translation catalogue (78 entries)

note: type: Plain text
en: == Branch Wizardry ==
de: == 'Branch'-Magie ==

note: type: Plain text
en: Instant branching and merging are the most lethal of Git's killer features.
de: Unverzügliches 'Branchen' und 'Mergen' sind die hervorstechenden Eigenschaften von Git.

note: type: Plain text
en: *Problem*: External factors inevitably necessitate context switching. A severe
    bug manifests in the released version without warning. The deadline for a
    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.
de: *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.

note: type: Plain text
en: Interrupting your train of thought can be detrimental to your productivity, and the more cumbersome it is to switch contexts, the greater the loss. With centralized version control we must download a fresh working copy from the central server. Distributed systems fare better, as we can clone the desired version locally.
de: 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.

note: type: Plain text
en: But cloning still entails copying the whole working directory as well as the entire history up to the given point. Even though Git reduces the cost of this with file sharing and hard links, the project files themselves must be recreated in their entirety in the new working directory.
de: 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.

note: type: Plain text
en: *Solution*: Git has a better tool for these situations that is much faster and more space-efficient than cloning: *git branch*.
de: *Lösung*: Git hat ein besseres Werkzeug für diese Situationen, die wesentlich schneller und platzsparender als 'clonen' ist: *git branch*.

note: type: Plain text
en: With this magic word, the files in your directory suddenly shapeshift from one version to another. This transformation can do more than merely go back or forward in history. Your files can morph from the last release to the experimental version to the current development version to your friend's version and so on.
de: 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.

note: type: Plain text
en: === The Boss Key ===
de: === Die Chef-Taste ===

note: type: Plain text
en: Ever played one of those games where at the push of a button (``the boss key''), the screen would instantly display a spreadsheet or something? So if the boss walked in the office while you were playing the game you could quickly hide it away?
de: 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?

note: type: Plain text
en: In some directory:
de: In irgendeinem Verzeichnis:

note: type: Plain text
en:  $ echo "I'm smarter than my boss" > myfile.txt
     $ git init
     $ git add .
     $ git commit -m "Initial commit"
de:  $ echo "Ich bin klüger als mein Chef" > meinedatei.txt
     $ git init
     $ git add .
     $ git commit -m "Erster Stand"

note: type: Plain text
en: We have created a Git repository that tracks one text file containing a certain message. Now type:
de: Wir haben ein Git 'Repository' erstellt, das eine Textdatei mit einer bestimmten Nachricht enthält. Nun gib ein:

note: type: Plain text
en:  $ git checkout -b boss  # nothing seems to change after this
     $ echo "My boss is smarter than me" > myfile.txt
     $ git commit -a -m "Another commit"
de:  $ 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"

note: type: Plain text
en: It looks like we've just overwritten our file and committed it. But it's an illusion. Type:
de: Es sieht aus als hätten wir unsere Datei überschrieben und 'commitet'. Aber es ist eine Illusion. Tippe:

note: type: Plain text
en:  $ git checkout master  # switch to original version of the file
de:  $ git checkout master  # wechsle zur Originalversion der Datei

note: type: Plain text
en: and hey presto! The text file is restored. And if the boss decides to snoop around this directory, type:
de: und Simsalabim! Die Textdatei ist wiederhergestellt. Und wenn der Chef in diesem Verzeichnis herumschnüffelt, tippe:

note: type: Plain text
en:  $ git checkout boss  # switch to version suitable for boss' eyes
de:  $ git checkout chef  # wechsle zur Version die der Chef ruhig sehen kann

note: type: Plain text
en: You can switch between the two versions of the file as much as you like, and commit to each independently.
de: Du kannst zwischen den beiden Versionen wechseln, so oft du willst und du kannst unabhängig voneinander in jeder Version Änderungen 'commiten'

note: type: Plain text
en: === Dirty Work ===
de: === Schmutzarbeit ===

note: type: Plain text
en: [[branch]] Say you're working on some feature, and for some reason, you need to go back three versions and temporarily put in a few print statements to see how something works. Then:
de: [[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:

note: type: Plain text
en: Now you can add ugly temporary code all over the place. You can even commit these changes. When you're done,
de: Nun kannst du überall wild temporären Code hinzufügen. Du kannst diese Änderungen sogar 'commiten'. Wenn du fertig bist,

note: type: Plain text
en: to return to your original work. Observe that any uncommitted changes are carried over.
de: um zur ursprünglichen Arbeit zurückzukehren. Beachte, dass alle Änderungen, die nicht 'commitet' sind übernommen werden.

note: type: Plain text
en: What if you wanted to save the temporary changes after all? Easy:
de: Was, wenn du am Ende die temporären Änderungen sichern willst? Einfach:

note: type: Plain text
en:  $ git checkout -b dirty
de:  $ git checkout -b schmutzig

note: type: Plain text
en: and commit before switching back to the master branch. Whenever you want to return to the dirty changes, simply type:
de: und 'commite' bevor du auf den 'Master Branch' zurückschaltest. Wann immer du zu deiner Schmutzarbeit zurückkehren willst, tippe einfach:

note: type: Plain text
en:  $ git checkout dirty
de:  $ git checkout schnmutzig

note: type: Plain text
en: We touched upon this command in an earlier chapter, when discussing loading old states. At last we can tell the whole story: the files change to the 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.
de: 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.

note: type: Plain text
en: In other words, after checking out an old state, Git automatically puts you in a new, unnamed branch, which can be named and saved with *git checkout -b*.
de: 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.

note: type: Plain text
en: === Quick Fixes ===
de: === Schnelle Fehlerbehebung ===

note: type: Plain text
en: You're in the middle of something when you are told to drop everything and fix a newly discovered bug in commit `1b6d...`:
de: Du steckst mitten in der Arbeit, als es heißt alles fallen zu lassen um einen neu entdeckten Fehler in 'Commit' `1b6d...` zu beheben:

note: type: Plain text
en: Then once you've fixed the bug:
de: Dann, wenn du den Fehler behoben hast:

note: type: Plain text
en:  $ git commit -a -m "Bug fixed"
     $ git checkout master
de:  $ git commit -a -m "Fehler behoben"
     $ git checkout master

note: type: Plain text
en: and resume work on your original task. You can even 'merge' in the freshly baked bugfix:
de: und fahre mit deiner ursprünglichen Arbeit fort. Du kannst sogar die frisch gebackene Fehlerkorrektur auf Deinen aktuellen Stand übernehmen:

note: type: Plain text
en: === Merging ===
de: === 'Mergen' ===

note: type: Plain text
en: With some version control systems, creating branches is easy but merging them back together is tough. With Git, merging is so trivial that you might be unaware of it happening.
de: 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.

note: type: Plain text
en: We actually encountered merging long ago. The *pull* command in fact 'fetches' commits and then merges them into your current branch. If you have no local changes, then the merge is a 'fast forward', a degenerate case akin to fetching the latest version in a centralized version control system. But if you do have local changes, Git will automatically merge, and report any conflicts.
de: 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.

note: type: Plain text
en: Ordinarily, a commit has exactly one 'parent commit', namely, the previous commit. Merging branches together produces a commit with at least two 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?
de: 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?

note: type: Plain text
en: It turns out this notation chooses the first parent every time. This is desirable because the current branch becomes the first parent during a merge; frequently you're only concerned with the changes you made in the current branch, as opposed to changes merged in from other branches.
de: 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.

note: type: Plain text
en: You can refer to a specific parent with a caret. For example, to show the logs from the second parent:
de: Du kannst einen bestimmten Elternteil mit einem Caret-Zeichen referenzieren. Um zum Beispiel die Logs vom zweiten Elternteil anzuzeigen:

note: type: Plain text
en: You may omit the number for the first parent. For example, to show the differences with the first parent:
de: Du kannst die Nummer für den ersten Elternteil weglassen. Um zum Beispiel die Unterschiede zum ersten Elternteil anzuzeigen:

note: type: Plain text
en: You can combine this notation with other types. For example:
de: Du kannst diese Notation mit anderen Typen kombinieren. Zum Beispiel:

note: type: Plain text
en:  $ git checkout 1b6d^^2~10 -b ancient
de:  $ git checkout 1b6d^^2~10 -b uralt

note: type: Plain text
en: 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.
de: 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.

note: type: Plain text
en: === Uninterrupted Workflow ===
de: === Kontinuierlicher Arbeitsfluss ===

note: type: Plain text
en: Often in hardware projects, the second step of a plan must await the completion of the first step. A car undergoing repairs might sit idly in a garage until a particular part arrives from the factory. A prototype might wait for a chip to be fabricated before construction can continue.
de: 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.

note: type: Plain text
en: Software projects can be similar. The second part of a new feature may have to wait until the first part has been released and tested. Some projects require your code to be reviewed before accepting it, so you might wait until the first part is approved before starting the second part.
de: 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.

note: type: Plain text
en: Thanks to painless branching and merging, we can bend the rules and work on Part II before Part I is officially ready. Suppose you have committed Part I and sent it for review. Let's say you're in the `master` branch. Then branch off:
de: 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:

note: type: Plain text
en:  $ git checkout -b part2
de:  $ git checkout -b teil2

note: type: Plain text
en: Next, work on Part II, committing your changes along the way. To err is 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.
de: 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.

note: type: Plain text
en:  $ git checkout master  # Go back to Part I.
     $ fix_problem
     $ git commit -a        # Commit the fixes.
     $ git checkout part2   # Go back to Part II.
     $ git merge master     # Merge in those fixes.
de:  $ 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.

note: type: Plain text
en: Eventually, Part I is approved:
de: Schließlich, Teil I ist zugelassen:

note: type: Plain text
en:  $ git checkout master  # Go back to Part I.
     $ submit files         # Release to the world!
     $ git merge part2      # Merge in Part II.
     $ git branch -d part2  # Delete "part2" branch.
de:  $ 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  # Lösche den Branch "teil2"

note: type: Plain text
en: Now you're in the `master` branch again, with Part II in the working directory.
de: Nun bist du wieder im `master` 'Branch', mit Teil II im Arbeitsverzeichnis.

note: type: Plain text
en: It's easy to extend this trick for any number of parts. It's also easy to branch off retroactively: suppose you belatedly realize you should have created a branch 7 commits ago. Then type:
de: 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:

note: type: Plain text
en:  $ git branch -m master part2  # Rename "master" branch to "part2".
     $ git branch master HEAD~7    # Create new "master", 7 commits upstream.
de:  $ git branch -m master teil2  # Umbenennen des 'Branch' "master" zu "teil2".
     $ git branch master HEAD~7    # Erstelle neuen "master", 7 Commits voraus

note: type: Plain text
en: The `master` branch now contains just Part I, and the `part2` branch contains the rest. We are in the latter branch; we created `master` without switching to it, because we want to continue work on `part2`. This is unusual. Until now, we've been switching to branches immediately after creation, as in:
de: 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 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:

note: type: Plain text
en:  $ git checkout HEAD~7 -b master  # Create a branch, and switch to it.
de:  $ git checkout HEAD~7 -b master  # erzeuge einen Branch, und wechsle zu ihm.

note: type: Plain text
en: === Reorganizing a Medley ===
de: === Mischmasch Reorganisieren ===

note: type: Plain text
en: Perhaps you like to work on all aspects of a project in the same branch. You want to keep works-in-progress to yourself and want others to see your commits only when they have been neatly organized. Start a couple of branches:
de: 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':

note: type: Plain text
en:   $ git branch sanitized    # Create a branch for sanitized commits.
      $ git checkout -b medley  # Create and switch to a branch to work in.
de:   $ git branch sauber           # Erzeuge einen Branch für gesäuberte Commits.
      $ git checkout -b mischmasch  # Erzeuge und wechsle in den Branch zum Arbeiten.

note: type: Plain text
en: Next, work on anything: fix bugs, add features, add temporary code, and so forth, committing often along the way. Then:
de: Fahre fort alles zu bearbeiten: Behebe Fehler, füge Funktionen hinzu, erstelle temporären Code und so weiter und 'commite' deine Änderungen oft. Dann:

note: type: Plain text
en:   $ git checkout sanitized
      $ git cherry-pick medley^^
de:   $ git checkout bereinigt
      $ git cherry-pick mischmasch^^

note: type: Plain text
en: applies the grandparent of the head commit of the ``medley'' branch to the ``sanitized'' branch. With appropriate cherry-picks you can construct a branch that contains only permanent code, and has related commits grouped together.
de: 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.

note: type: Plain text
en: === Managing Branches ===
de: === 'Branches' verwalten ===

note: type: Plain text
en: List all branches by typing:
de: Ein Liste aller 'Branches' bekommst du mit:

note: type: Plain text
en: By default, you start in a branch named ``master''. Some advocate leaving the ``master'' branch untouched and creating new branches for your own edits.
de: 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.

note: type: Plain text
en: The *-d* and *-m* options allow you to delete and move (rename) branches.  See *git help branch*.
de: Die *-d* und *-m* Optionen erlauben dir 'Branches' zu löschen und zu verschieben (umzubenennen). Siehe *git help branch*.

note: type: Plain text
en: The ``master'' branch is a useful custom. Others may assume that your repository has a branch with this name, and that it contains the official version of your project. Although you can rename or obliterate the ``master'' branch, you might as well respect this convention.
de: 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.

note: type: Plain text
en: === Temporary Branches ===
de: === Temporäre 'Branches' ===

note: type: Plain text
en: After a while you may realize you are creating short-lived branches frequently for similar reasons: every other branch merely serves to save the current state so you can briefly hop back to an older state to fix a high-priority bug or something.
de: 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.

note: type: Plain text
en: It's analogous to changing the TV channel temporarily to see what else is on.  But instead of pushing a couple of buttons, you have to create, check out, merge, and delete temporary branches. Luckily, Git has a shortcut that is as convenient as a TV remote control:
de: 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:

note: type: Plain text
en: This saves the current state in a temporary location (a 'stash') and restores the previous state. Your working directory appears exactly as it was before you started editing, and you can fix bugs, pull in upstream changes, and so on. When you want to go back to the stashed state, type:
de: 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:

note: type: Plain text
en:  $ git stash apply  # You may need to resolve some conflicts.
de:  $ git stash apply  # Es kann sein, dass du Konflikte auflösen musst.

note: type: Plain text
en: You can have multiple stashes, and manipulate them in various ways. See *git help stash*. As you may have guessed, Git maintains branches behind the scenes to perform this magic trick.
de: 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.

note: type: Plain text
en: === Work How You Want ===
de: === Arbeite wie du willst ===

note: type: Plain text
en: You might wonder if branches are worth the bother. After all, clones are almost as fast, and you can switch between them with *cd* instead of esoteric Git commands.
de: 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.

note: type: Plain text
en: Consider web browsers. Why support multiple tabs as well as multiple windows? Because allowing both accommodates a wide variety of styles. Some users like to keep only one browser window open, and use tabs for multiple webpages. Others might insist on the other extreme: multiple windows with no tabs anywhere.  Others still prefer something in between.
de: 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.

note: type: Plain text
en: Branching is like tabs for your working directory, and cloning is like opening a new browser window. These operations are fast and local, so why not experiment to find the combination that best suits you? Git lets you work exactly how you want.
de: '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.
