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

note: type: Plain text
en: Initially I used Git on a private project where I was the sole developer.  Amongst the commands related to Git's distributed nature, I needed only *pull* and *clone* so could I keep the same project in different places.
de: 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.

note: type: Plain text
en: Later I wanted to publish my code with Git, and include changes from contributors. I had to learn how to manage projects with multiple developers from all over the world. Fortunately, this is Git's forte, and arguably its raison d'être.
de: 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.

note: type: Plain text
en: === Who Am I? ===
de: === Wer bin ich? ===

note: type: Plain text
en: Every commit has an author name and email, which is shown by *git log*.  By default, Git uses system settings to populate these fields.  To set them explicitly, type:
de: Jeder 'Commit' enthält Name und eMail-Adresse 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:

note: type: Plain text
en:   $ git config --global user.name "John Doe"
      $ git config --global user.email johndoe@example.com
de:   $ git config --global user.name "Max Mustermann"
      $ git config --global user.email maxmustermann@beispiel.de

note: type: Plain text
en: Omit the global flag to set these options only for the current repository.
de: Lasse den -global Schalter weg um diese Einstellungen für das aktuelle 'Repository' zu setzen.

note: type: Plain text
en: === Git Over SSH, HTTP ===
de: === Git über SSH, HTTP ===

note: type: Plain text
en: Suppose you have SSH access to a web server, but Git is not installed. Though less efficient than its native protocol, Git can communicate over HTTP.
de: 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.

note: type: Plain text
en: Download, compile and install Git in your account, and create a repository in your web directory:
de: Lade Git herunter, compiliere und installiere es unter Deinem Benutzerkonto und erstellen ein 'Repository' in Deinem Webverzeichnis:

note: type: Plain text
en: For older versions of Git, the copy command fails and you should run:
de: Bei älteren Git Versionen funktioniert der 'copy'-Befehl nicht, stattdessen gib ein:

note: type: Plain text
en: Now you can publish your latest edits via SSH from any clone:
de: Nun kannst Du Deine letzten Änderungen über SSH von jedem 'Clone' aus veröffentlichen.

note: type: Plain text
en:  $ git push web.server:/path/to/proj.git master
de:  $ git push web.server:/pfad/zu/proj.git master

note: type: Plain text
en: and anybody can get your project with:
de: und jedermann kann Dein Projekt abrufen mit:

note: type: Plain text
en: === Git Over Anything ===
de: === Git über alles ===

note: type: Plain text
en: Want to synchronize repositories without servers, or even a network connection? Need to improvise during an emergency? We've seen <<makinghistory, *git fast-export* and *git fast-import* can convert repositories to a single file and back>>. We could shuttle such files back and forth to transport git repositories over any medium, but a more efficient tool is *git bundle*.
de: 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*.

note: type: Plain text
en: The sender creates a 'bundle':
de: Der Absender erstellt ein 'Bundle':

note: type: Plain text
en:  $ git bundle create somefile HEAD
de:  $ git bundle create einedatei HEAD

note: type: Plain text
en: then transports the bundle, +somefile+, to the other party somehow: email, thumb drive, an *xxd* printout and an OCR scanner, reading bits over the phone, smoke signals, etc. The receiver retrieves commits from the bundle by typing:
de: 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:

note: type: Plain text
en:  $ git pull somefile
de:  $ git pull einedatei

note: type: Plain text
en: The receiver can even do this from an empty repository. Despite its size, +somefile+ contains the entire original git repository.
de: Der Empfänger kann das sogar mit einem leeren 'Repository' tun. Trotz seiner Größe, +einedatei+ enthält das komplette original Git 'Repository'.

note: type: Plain text
en: In larger projects, eliminate waste by bundling only changes the other repository lacks. For example, suppose the commit ``1b6d...'' is the most recent commit shared by both parties:
de: 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:

note: type: Plain text
en:  $ git bundle create somefile HEAD ^1b6d
de:  $ git bundle create einedatei HEAD ^1b6d

note: type: Plain text
en: If done frequently, one could easily forget which commit was last sent. The help page suggests using tags to solve this. Namely, after you send a bundle, type:
de: 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:

note: type: Plain text
en:  $ git tag -f lastbundle HEAD
de:  $ git tag -f letztesbundle HEAD

note: type: Plain text
en: and create new refresher bundles with:
de: und erstelle neue Aktualisierungsbundles mit:

note: type: Plain text
en:  $ git bundle create newbundle HEAD ^lastbundle
de:  $ git bundle create neuesbundle HEAD ^letztesbundle

note: type: Plain text
en: === Patches: The Global Currency ===
de: === Patches: Das globale Zahlungsmittel ===

note: type: Plain text
en: Patches are text representations of your changes that can be easily understood by computers and humans alike. This gives them universal appeal. You can email a patch to developers no matter what version control system they're using. As long as your audience can read their email, they can see your edits. Similarly, on your side, all you require is an email account: there's no need to setup an online Git repository.
de: '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.

note: type: Plain text
en: Recall from the first chapter:
de: Erinnere Dich an das erste Kapitel:

note: type: Plain text
en:  $ git diff 1b6d > my.patch
de:  $ git diff 1b6d > mein.patch

note: type: Plain text
en: outputs a patch which can be pasted into an email for discussion. In a Git repository, type:
de: gibt einen 'Patch' aus, der zur Diskussion einfach in eine eMail eingefügt werden kann. In einem Git 'Repository' gib ein:

note: type: Plain text
en:  $ git apply < my.patch
de:  $ git apply < mein.patch

note: type: Plain text
en: to apply the patch.
de: um den 'Patch' anzuwenden.

note: type: Plain text
en: In more formal settings, when author names and perhaps signatures should be recorded, generate the corresponding patches past a certain point by typing:
de: In einer offizielleren Umgebung, wenn Autorennamen und eventuell Signaturen aufgezeichnet werden sollen, erstelle die entsprechenden 'Patches' nach einem bestimmten Punkt durch Eingabe von:

note: type: Plain text
en: The resulting files can be given to *git-send-email*, or sent by hand. You can also specify a range of commits:
de: Die resultierenden Dateien können an *git-send-email* übergeben werden oder von Hand verschickt werden. Du kannst auch eine Gruppe von 'Commits' angeben:

note: type: Plain text
en: On the receiving end, save an email to a file, then type:
de: Auf der Empfängerseite speichere die eMail in eine Datei, dann gib ein:

note: type: Plain text
en: This applies the incoming patch and also creates a commit, including information such as the author.
de: Das wendet den eingegangenen 'Patch' an und erzeugt einen 'Commit', inklusive der Informationen wie z.B. den Autor.

note: type: Plain text
en: With a browser email client, you may need to click a button to see the email in its raw original form before saving the patch to a file.
de: 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.

note: type: Plain text
en: There are slight differences for mbox-based email clients, but if you use one of these, you're probably the sort of person who can figure them out easily without reading tutorials!
de: 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.!

note: type: Plain text
en: === Sorry, We've Moved ===
de: === Entschuldigung, wir sind umgezogen. ===

note: type: Plain text
en: After cloning a repository, running *git push* or *git pull* will automatically push to or pull from the original URL. How does Git do this? The secret lies in config options created with the clone. Let's take a peek:
de: 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:

note: type: Plain text
en: The +remote.origin.url+ option controls the source URL; ``origin'' is a nickname given to the source repository. As with the ``master'' branch convention, we may change or delete this nickname but there is usually no reason for doing so.
de: 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.

note: type: Plain text
en: If the original repository moves, we can update the URL via:
de: Wenn das original 'Repository' verschoben wird, können wir die URL aktualisieren mit:

note: type: Plain text
en:  $ git config remote.origin.url git://new.url/proj.git
de:  $ git config remote.origin.url git://neue.url/proj.git

note: type: Plain text
en: The +branch.master.merge+ option specifies the default remote branch in a *git pull*. During the initial clone, it is set to the current branch of the source repository, so even if the HEAD of the source repository subsequently moves to a different branch, a later pull will faithfully follow the original branch.
de: 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.

note: type: Plain text
en: This option only applies to the repository we first cloned from, which is recorded in the option +branch.master.remote+. If we pull in from other repositories we must explicitly state which branch we want:
de: 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:

note: type: Plain text
en:  $ git pull git://example.com/other.git master
de:  $ git pull git://beispiel.com/anderes.git master

note: type: Plain text
en: The above explains why some of our earlier push and pull examples had no arguments.
de: Das obige erklärt, warum einige von unseren früheren 'push' und 'pull' Beispielen keine Argumente hatten.

note: type: Plain text
en: === Remote Branches ===
de: === Entfernte 'Branches' ===

note: type: Plain text
en: When you clone a repository, you also clone all its branches. You may not have noticed this because Git hides them away: you must ask for them specifically.  This prevents branches in the remote repository from interfering with your branches, and also makes Git easier for beginners.
de: 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.

note: type: Plain text
en: List the remote branches with:
de: Zeige die entfernten 'Branches' an mit:

note: type: Plain text
en: You should see something like:
de: Du solltes etwas sehen wie:

note: type: Plain text
en:  origin/HEAD
     origin/master
     origin/experimental
de:  origin/HEAD
     origin/master
     origin/experimentell

note: type: Plain text
en: These represent branches and the HEAD of the remote repository, and can be used in regular Git commands. For example, suppose you have made many commits, and wish to compare against the last fetched version. You could search through the logs for the appropriate SHA1 hash, but it's much easier to type:
de: 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:

note: type: Plain text
en: Or you can see what the ``experimental'' branch has been up to:
de: Oder Du kannst schauen, was auf dem 'Branch' ``experimentell'' los war:

note: type: Plain text
en:  $ git log origin/experimental
de:  $ git log origin/experimentell

note: type: Plain text
en: === Multiple Remotes ===
de: === Mehrere 'Remotes' ===

note: type: Plain text
en: Suppose two other developers are working on our project, and we want to keep tabs on both. We can follow more than one repository at a time with:
de: 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:

note: type: Plain text
en: Now we have merged in a branch from the second repository, and we have easy access to all branches of all repositories:
de: Nun haben wir einen 'Branch' vom zweiten 'Repository' eingebunden und wir haben einfachen Zugriff auf alle 'Branches' von allen 'Repositories':

note: type: Plain text
en:  $ git diff origin/experimental^ other/some_branch~5
de:  $ git diff origin/experimentell^ other/some_branch~5

note: type: Plain text
en: But what if we just want to compare their changes without affecting our own work? In other words, we want to examine their branches without having their changes invade our working directory. Then rather than pull, run:
de: 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:

note: type: Plain text
en:  $ git fetch        # Fetch from origin, the default.
     $ git fetch other  # Fetch from the second programmer.
de:  $ git fetch        # Fetch vom origin, der Standard.
     $ git fetch other  # Fetch vom zweiten Programmierer.

note: type: Plain text
en: This just fetches histories. Although the working directory remains untouched, we can refer to any branch of any repository in a Git command because we now possess a local copy.
de: 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.

note: type: Plain text
en: Recall that behind the scenes, a pull is simply a *fetch* then *merge*.  Usually we *pull* because we want to merge the latest commit after a fetch; this situation is a notable exception.
de: 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.

note: type: Plain text
en: See *git help remote* for how to remove remote repositories, ignore certain branches, and more.
de: Siehe *git help remote* um zu sehen wie man Remote-'Repositories' entfernt, bestimmte 'Branches' ignoriert und mehr.

note: type: Plain text
en: === My Preferences ===
de: === Meine Einstellungen ===

note: type: Plain text
en: For my projects, I like contributors to prepare repositories from which I can pull. Some Git hosting services let you host your own fork of a project with the click of a button.
de: 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.

note: type: Plain text
en: After I fetch a tree, I run Git commands to navigate and examine the changes, which ideally are well-organized and well-described. I merge my own changes, and perhaps make further edits. Once satisfied, I push to the main repository.
de: 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'.

note: type: Plain text
en: Though I infrequently receive contributions, I believe this approach scales well. See http://torvalds-family.blogspot.com/2009/06/happiness-is-warm-scm.html[this blog post by Linus Torvalds].
de: 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)].

note: type: Plain text
en: Staying in the Git world is slightly more convenient than patch files, as it saves me from converting them to Git commits. Furthermore, Git handles details such as recording the author's name and email address, as well as the time and date, and asks the author to describe their own change.
de: 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.
