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

note: type: Plain text
en: == Secrets Revealed ==
de: == Aufgedeckte Geheimnisse ==

note: type: Plain text
en: We take a peek under the hood and explain how Git performs its miracles. I will skimp over details. For in-depth descriptions refer to http://www.kernel.org/pub/software/scm/git/docs/user-manual.html[the user manual].
de: Wir werfen einen Blick unter die Motorhaube und erklären, wie Git seine Wunder vollbringt. Ich werde nicht ins Detail gehen. Für tiefer gehende Erklärungen verweise ich auf das http://www.kernel.org/pub/software/scm/git/docs/user-manual.html[englischsprachige Benutzerhandbuch].

note: type: Plain text
en: === Invisibility ===
de: === Unsichtbarkeit ===

note: type: Plain text
en: How can Git be so unobtrusive? Aside from occasional commits and merges, you can work as if you were unaware that version control exists. That is, until you need it, and that's when you're glad Git was watching over you the whole time.
de: Wie kann Git so unauffällig sein? Abgesehen von gelegentlichen 'Commits' und 'Merges' kannst Du arbeiten, als würde die Versionsverwaltung nicht existieren. Das heißt, bis Du sie brauchst. Und das ist, wenn Du froh bist, dass Git die ganze Zeit über Dich gewacht hat.

note: type: Plain text
en: Other version control systems force you to constantly struggle with red tape and bureaucracy. Permissions of files may be read-only unless you explicitly tell a central server which files you intend to edit. The most basic commands may slow to a crawl as the number of users increases. Work grinds to a halt when the network or the central server goes down.
de: Andere Versionsverwaltungssysteme zwingen Dich ständig Dich mit Verwaltungskram und Bürokratie herumzuschlagen. Dateien sind können schreibgeschützt sein, bis Du einem zentralen Server mitteilst, welche Dateien Du gerne bearbeiten möchtest. Die einfachsten Befehle werden bis zum Schneckentempo verlangsamt, wenn die Anzahl der Anwender steigt. Deine Arbeit kommt zum Stillstand, wenn das Netzwerk oder der zentrale Server weg sind.

note: type: Plain text
en: In contrast, Git simply keeps the history of your project in the `.git` directory in your working directory. This is your own copy of the history, so you can stay offline until you want to communicate with others. You have total control over the fate of your files because Git can easily recreate a saved state from `.git` at any time.
de: Im Gegensatz dazu hält Git seinen Verlauf einfach im `.git` Verzeichnis von Deinem Arbeitsverzeichnis. Das ist Deine eigene Kopie der Versionsgeschichte, damit kannst Du so lange offline bleiben, bis Du mit anderen kommunizieren willst. Du hast die absolute Kontrolle über das Schicksal Deiner Dateien, denn Git kann jederzeit einfach einen gesicherten Stand aus `.git` wiederherstellen.

note: type: Plain text
en: === Integrity ===
de: === Integrität ===

note: type: Plain text
en: Most people associate cryptography with keeping information secret, but another equally important goal is keeping information safe. Proper use of cryptographic hash functions can prevent accidental or malicious data corruption.
de: Die meisten Leute verbinden mit Kryptographie die Geheimhaltung von Informationen, aber ein genau so wichtiges Ziel ist es Informationen zu sichern. Die richtige Anwendung von kryptographischen Hash-Funktionen kann einen versehentlichen oder bösartigen Datenverlust verhindern.

note: type: Plain text
en: A SHA1 hash can be thought of as a unique 160-bit ID number for every string of bytes you'll encounter in your life. Actually more than that: every string of bytes that any human will ever use over many lifetimes.
de: Einen SHA1-Hash-Wert kann man sich als eindeutige 160-Bit Identitätsnummer für jegliche Zeichenkette vorstellen, welche Dir in Deinem ganzen Leben begegnen wird. Sogar mehr als das: jegliche Zeichenfolge, die alle Menschen über mehrere Generationen verwenden.

note: type: Plain text
en: As a SHA1 hash is itself a string of bytes, we can hash strings of bytes containing other hashes. This simple observation is surprisingly useful: look up 'hash chains'. We'll later see how Git uses it to efficiently guarantee data integrity.
de: Ein SHA1-Hash-Wert selbst ist eine Zeichenfolge von Bytes. Wir können SHA1-Hash-Werte aus Zeichenfolgen generieren, die selbst SHA1-Hash-Werte enthalten. Diese einfache Beobachtung ist überraschend nützlich: suche nach 'hash chains'. Wir werden später sehen, wie Git diese nutzt um effizient die Datenintegrität zu garantieren.

note: type: Plain text
en: Briefly, Git keeps your data in the `.git/objects` subdirectory, where instead of normal filenames, you'll find only IDs. By using IDs as filenames, as well as a few lockfiles and timestamping tricks, Git transforms any humble filesystem into an efficient and robust database.
de: Kurz gesagt, Git hält Deine Daten in dem `.git/objects` Unterverzeichnis, wo Du anstelle von normalen Dateinamen nur Identitätsnummern findest. Durch die Verwendung von Identitätsnummern als Dateiname, zusammen mit ein paar Sperrdateien und Zeitstempeltricks, macht Git aus einem einfachen Dateisystem eine effiziente und robuste Datenbank.

note: type: Plain text
en: === Intelligence ===
de: === Intelligenz ===

note: type: Plain text
en: How does Git know you renamed a file, even though you never mentioned the fact explicitly? Sure, you may have run *git mv*, but that is exactly the same as a *git rm* followed by a *git add*.
de: Woher weiß Git, dass Du eine Datei umbenannt hast, obwohl Du es ihm niemals explizit mitgeteilt hast? Sicher, Du hast vielleicht *git mv* benutzt, aber das ist exakt das selbe wie *git rm* gefolgt von *git add*.

note: type: Plain text
en: Git heuristically ferrets out renames and copies between successive versions. In fact, it can detect chunks of code being moved or copied around between files! Though it cannot cover all cases, it does a decent job, and this feature is always improving. If it fails to work for you, try options enabling more expensive copy detection, and consider upgrading.
de: Git stöbert Umbenennungen und Kopien zwischen aufeinander folgenden Versionen heuristisch auf. Vielmehr kann es sogar Codeblöcke erkennen, die zwischen Dateien hin und her kopiert oder verschoben wurden! Jedoch kann es nicht alle Fälle abdecken, aber es leistet ordentliche Arbeit und diese Eigenschaft wird immer besser. Wenn es bei Dir nicht funktioniert, versuche Optionen zur aufwendigeren Erkennung von Kopien oder erwäge einen Upgrade.

note: type: Plain text
en: === Indexing ===
de: === Indizierung ===

note: type: Plain text
en: For every tracked file, Git records information such as its size, creation time and last modification time in a file known as the 'index'. To determine whether a file has changed, Git compares its current stats with those cached in the index. If they match, then Git can skip reading the file again.
de: Für jede überwachte Datei speichert Git Informationen wie deren Größe, ihren Erstellzeitpunkt und den Zeitpunkt der letzten Bearbeitung in einer Datei die wir als 'Index' kennen. Um zu ermitteln, ob eine Datei verändert wurde, vergleicht Git den aktuellen Status mit dem im Index gespeicherten. Stimmen diese Daten überein, kann Git das Lesen des Dateiinhalts überspringen.

note: type: Plain text
en: Since stat calls are considerably faster than file reads, if you only edit a few files, Git can update its state in almost no time.
de: Da das Abfragen des Dateistatus erheblich schneller ist als das Lesen der Datei, kann Git, wenn Du nur ein paar Dateien verändert hast, seinen Status im Nu aktualisieren.

note: type: Plain text
en: We stated earlier that the index is a staging area. Why is a bunch of file stats a staging area? Because the add command puts files into Git's database and updates these stats, while the commit command, without options, creates a commit based only on these stats and the files already in the database.
de: Wir haben früher festgestellt, dass der Index ein Bereitstellungsraum ist. Warum kann ein Haufen von Dateistatusinformationen ein Bereitstellungsraum sein? Weil die 'add' Anweisung Dateien in die Git Datenbank befördert und die Dateistatusinformationen aktualisiert, während die 'commit' Anweisung, ohne Optionen, einen 'Commit' nur auf Basis der Dateistatusinformationen erzeugt, weil die Dateien ja schon in der Datenbank sind.

note: type: Plain text
en: === Git's Origins ===
de: === Git's Wurzeln ===

note: type: Plain text
en: This http://lkml.org/lkml/2005/4/6/121[Linux Kernel Mailing List post] describes the chain of events that led to Git. The entire thread is a fascinating archaeological site for Git historians.
de: Dieser http://lkml.org/lkml/2005/4/6/121['Linux Kernel Mailing List' Beitrag] beschreibt die Kette von Ereignissen, die zu Git geführt haben. Der ganze Beitrag ist eine faszinierende archäologische Seite für Git Historiker.

note: type: Plain text
en: === The Object Database ===
de: === Die Objektdatenbank ===

note: type: Plain text
en: Every version of your data is kept in the 'object database', which lives in the subdirectory `.git/objects`; the other residents of `.git/` hold lesser data: the index, branch names, tags, configuration options, logs, the current location of the head commit, and so on. The object database is elementary yet elegant, and the source of Git's power.
de: Jegliche Version Deiner Daten wird in der Objektdatenbank gehalten, welche im Unterverzeichnis `.git/objects` liegt; Die anderen Orte in `.git/` enthalten weniger wichtige Daten: den Index, 'Branch' Namen, Bezeichner ('tags'), Konfigurationsoptionen, Logdateien, die Position des aktuellen 'HEAD Commit' und so weiter. Die Objektdatenbank ist einfach aber trotzdem elegant und sie ist die Quelle von Git's Macht.

note: type: Plain text
en: Each file within `.git/objects` is an 'object'. There are 3 kinds of objects that concern us: 'blob' objects, 'tree' objects, and 'commit' objects.
de: Jede Datei in `.git/objects` ist ein 'Objekt'. Es gibt drei Arten von Objekten die uns betreffen: 'Blob'-, 'Tree'-, und 'Commit'-Objekte.

note: type: Plain text
en: First, a magic trick. Pick a filename, any filename. In an empty directory:
de: Zuerst ein Zaubertrick. Suche Dir einen Dateinamen aus, irgendeinen. In einem leeren Verzeichnis:

note: type: Plain text
en:  $ echo sweet > YOUR_FILENAME
     $ git init
     $ git add .
     $ find .git/objects -type f
de:  $ echo sweet > DEIN_DATEINAME
     $ git init
     $ git add .
     $ find .git/objects -type f

note: type: Plain text
en: You'll see +.git/objects/aa/823728ea7d592acc69b36875a482cdf3fd5c8d+.
de: Du wirst folgendes sehen: +.git/objects/aa/823728ea7d592acc69b36875a482cdf3fd5c8d+.

note: type: Plain text
en: How do I know this without knowing the filename? It's because the SHA1 hash of:
de: Wie konnte ich das wissen, ohne den Dateiname zu kennen? Weil der SHA1-Hash-Wert von:

note: type: Plain text
en: is aa823728ea7d592acc69b36875a482cdf3fd5c8d, where SP is a space, NUL is a zero byte and LF is a linefeed. You can verify this by typing:
de: aa823728ea7d592acc69b36875a482cdf3fd5c8d ist. Wobei SP ein Leerzeichen ist, NUL ist ein Nullbyte und LF ist ein Zeilenumbruch. Das kannst Du kontrollieren, durch die Eingabe von:

note: type: Plain text
en: Git is 'content-addressable': files are not stored according to their filename, but rather by the hash of the data they contain, in a file we call a 'blob object'. We can think of the hash as a unique ID for a file's contents, so in a sense we are addressing files by their content. The initial `blob 6` is merely a header consisting of the object type and its length in bytes; it simplifies internal bookkeeping.
de: Git ist 'assoziativ': Dateien werden nicht nach Ihren Namen gespeichert, sondern eher nach dem SHA1-Hash-Wert der Daten, welche sie enthalten, in einer Datei, die wir als 'Blob'-Objekt bezeichnen. Wir können uns den SHA1-Hash-Wert als eindeutige Identnummer des Dateiinhalts vorstellen, was sinngemäß bedeutet, dass die Dateien über ihren Inhalt adressiert werden. Das führende `blob 6` ist lediglich ein Vermerk, der sich aus dem Objekttyp und seiner Länge in Bytes zusammensetzt; er vereinfacht die interne Verwaltung.

note: type: Plain text
en: Thus I could easily predict what you would see. The file's name is irrelevant: only the data inside is used to construct the blob object.
de: So konnte ich einfach vorhersagen, was Du sehen wirst. Der Dateiname ist irrelevant: nur der Dateiinhalt wird zum Erstellen des 'Blob'-Objekt verwendet.

note: type: Plain text
en: You may be wondering what happens to identical files. Try adding copies of your file, with any filenames whatsoever. The contents of +.git/objects+ stay the same no matter how many you add. Git only stores the data once.
de: Du wirst Dich fragen, was mit identischen Dateien ist. Versuche Kopien Deiner Datei hinzuzufügen, mit beliebigen Dateinamen. Der Inhalt von +.git/objects+ bleibt der selbe, ganz egal wieviele Dateien Du hinzufügst. Git speichert den Dateiinhalt nur ein einziges Mal.

note: type: Plain text
en: By the way, the files within +.git/objects+ are compressed with zlib so you should not stare at them directly. Filter them through http://www.zlib.net/zpipe.c[zpipe -d], or type:
de: Übrigens, die Dateien in +.git/objects+ sind mit zlib komprimiert, Du solltest sie also nicht direkt anschauen. Filtere sie durch http://www.zlib.net/zpipe.c[zpipe -d], oder gib ein:

note: type: Plain text
en: which pretty-prints the given object.
de: was Dir das Objekt im Klartext anzeigt.

note: type: Plain text
en: === Trees ===
de: === 'Trees' ===

note: type: Plain text
en: But where are the filenames? They must be stored somewhere at some stage.  Git gets around to the filenames during a commit:
de: Aber wo sind die Dateinamen? Sie müssen irgendwo gespeichert sein. Git kommt beim 'Commit' dazu sich um die Dateinamen zu kümmern:

note: type: Plain text
en:  $ git commit  # Type some message.
     $ find .git/objects -type f
de:  $ git commit  # Schreibe eine Bemerkung.
     $ find .git/objects -type f

note: type: Plain text
en: You should now see 3 objects. This time I cannot tell you what the 2 new files are, as it partly depends on the filename you picked. We'll proceed assuming you chose ``rose''. If you didn't, you can rewrite history to make it look like you did:
de: Du solltest nun drei Objekte sehen. Dieses mal kann ich Dir nicht sagen, wie die zwei neuen Dateien heißen, weil es zum Teil vom gewählten Dateiname abhängt, den Du ausgesucht hast. Fahren wir fort mit der Annahme, Du hast eine Datei ``rose'' genannt. Wenn nicht, kannst Du den Verlauf so umschreiben, dass es so aussieht als hättest Du es:

note: type: Plain text
en:  $ git filter-branch --tree-filter 'mv YOUR_FILENAME rose'
     $ find .git/objects -type f
de:  $ git filter-branch --tree-filter 'mv DEIN_DATEINAME rose'
     $ find .git/objects -type f

note: type: Plain text
en: Now you should see the file +.git/objects/05/b217bb859794d08bb9e4f7f04cbda4b207fbe9+, because this is the SHA1 hash of its contents:
de: Nun müsstest Du die Datei +.git/objects/05/b217bb859794d08bb9e4f7f04cbda4b207fbe9+ sehen, denn das ist der SHA1-Hash-Wert ihres Inhalts:

note: type: Plain text
en: Check this file does indeed contain the above by typing:
de: Prüfe, ob diese Datei tatsächlich dem obigen Inhalt entspricht, durch Eingabe von:

note: type: Plain text
en: With zpipe, it's easy to verify the hash:
de: Mit zpipe, ist es einfach den SHA1-Hash-Wert zu prüfen:

note: type: Plain text
en: Hash verification is trickier via cat-file because its output contains more than the raw uncompressed object file.
de: Die SHA1-Hash-Wert Prüfung mit 'cat-file' ist etwas kniffliger, da dessen Ausgabe mehr als die rohe unkomprimierte Objektdatei enthält.

note: type: Plain text
en: This file is a 'tree' object: a list of tuples consisting of a file type, a filename, and a hash. In our example, the file type is 100644, which means `rose` is a normal file, and the hash is the blob object that contains the contents of `rose'. Other possible file types are executables, symlinks or directories. In the last case, the hash points to a tree object.
de: Diese Datei ist ein 'Tree'-Objekt: eine Liste von Datensätzen, bestehend aus dem Dateityp, dem Dateinamen und einem SHA1-Hash-Wert. In unserem Beispiel ist der Dateityp 100644, was bedeutet, dass `rose` eine normale Datei ist und der SHA1-Hash-Wert entspricht dem 'Blob'-Objekt, welches den Inhalt von `rose` enthält. Andere mögliche Dateitypen sind ausführbare Programmdateien, symbolische Links oder Verzeichnisse. Im letzten Fall zeigt der SHA1-Hash-Wert auf ein 'Tree'-Objekt.

note: type: Plain text
en: If you ran filter-branch, you'll have old objects you no longer need. Although they will be jettisoned automatically once the grace period expires, we'll delete them now to make our toy example easier to follow:
de: Wenn Du 'filter-branch' aufrufst, bekommst Du alte Objekte, welche nicht länger benötigt werden. Obwohl sie automatisch über Bord geworfen werden, wenn ihre Gnadenfrist abgelaufen ist, wollen wir sie nun löschen, damit wir unserem Beispiel besser folgen können.

note: type: Plain text
en: For real projects you should typically avoid commands like this, as you are destroying backups. If you want a clean repository, it is usually best to make a fresh clone. Also, take care when directly manipulating +.git+: what if a Git command is running at the same time, or a sudden power outage occurs? In general, refs should be deleted with *git update-ref -d*, though usually it's safe to remove +refs/original+ by hand.
de: Für reale Projekte solltest Du solche Anweisungen üblicherweise vermeiden, da Du dadurch Datensicherungen zerstörst. Wenn Du ein sauberes 'Repository' willst, ist es am besten, einen neuen Klon anzulegen. Sei auch vorsichtig, wenn Du +.git+ direkt manipulierst: was, wenn zeitgleich ein Git Kommando ausgeführt wird oder plötzlich der Strom ausfällt? Generell sollten Referenzen mit *git update-ref -d* gelöscht werden, auch wenn es gewöhnlich sicher ist +refs/original+ von Hand zu löschen.

note: type: Plain text
en: === Commits ===
de: === 'Commits' ===

note: type: Plain text
en: We've explained 2 of the 3 objects. The third is a 'commit' object. Its contents depend on the commit message as well as the date and time it was created. To match what we have here, we'll have to tweak it a little:
de: Wir haben nun zwei von drei Objekten erklärt. Das dritte ist ein 'Commit'-Objekt. Sein Inhalt hängt von der 'Commit'-Beschreibung ab, wie auch vom Zeitpunkt der Erstellung. Damit alles zu unserem Beispiel passt, müssen wir ein wenig tricksen:

note: type: Plain text
en:  $ git commit --amend -m Shakespeare  # Change the commit message.
     $ git filter-branch --env-filter 'export
         GIT_AUTHOR_DATE="Fri 13 Feb 2009 15:31:30 -0800"
         GIT_AUTHOR_NAME="Alice"
         GIT_AUTHOR_EMAIL="alice@example.com"
         GIT_COMMITTER_DATE="Fri, 13 Feb 2009 15:31:30 -0800"
         GIT_COMMITTER_NAME="Bob"
         GIT_COMMITTER_EMAIL="bob@example.com"'  # Rig timestamps and authors.
     $ find .git/objects -type f
de:  $ git commit --amend -m Shakespeare  # Ändere die Bemerkung.
     $ git filter-branch --env-filter 'export
         GIT_AUTHOR_DATE="Fri 13 Feb 2009 15:31:30 -0800"
         GIT_AUTHOR_NAME="Alice"
         GIT_AUTHOR_EMAIL="alice@example.com"
         GIT_COMMITTER_DATE="Fri, 13 Feb 2009 15:31:30 -0800"
         GIT_COMMITTER_NAME="Bob"
         GIT_COMMITTER_EMAIL="bob@example.com"'  # Manipuliere Zeitstempel und Autor.
     $ find .git/objects -type f

note: type: Plain text
en: You should now see +.git/objects/49/993fe130c4b3bf24857a15d7969c396b7bc187+ which is the SHA1 hash of its contents:
de: Du solltest nun +.git/objects/49/993fe130c4b3bf24857a15d7969c396b7bc187+ finden, was dem SHA1-Hash-Wert seines Inhalts entspricht:

note: type: Plain text
en: As before, you can run zpipe or cat-file to see for yourself.
de: Wie vorhin, kannst Du 'zpipe' oder 'cat-file' benutzen um es für Dich zu überprüfen.

note: type: Plain text
en: This is the first commit, so there are no parent commits, but later commits will always contain at least one line identifying a parent commit.
de: Das ist der erste 'Commit' gewesen, deshalb gibt es keine Eltern-'Commits'. Aber spätere 'Commits' werden immer mindestens eine Zeile enthalten, die den Eltern-'Commit' identifiziert.

note: type: Plain text
en: === Indistinguishable From Magic ===
de: === Von Magie nicht zu unterscheiden ===

note: type: Plain text
en: Git's secrets seem too simple. It looks like you could mix together a few shell scripts and add a dash of C code to cook it up in a matter of hours: a melange of basic filesystem operations and SHA1 hashing, garnished with lock files and fsyncs for robustness. In fact, this accurately describes the earliest versions of Git. Nonetheless, apart from ingenious packing tricks to save space, and ingenious indexing tricks to save time, we now know how Git deftly changes a filesystem into a database perfect for version control.
de: Git's Geheimnisse scheinen zu einfach. Es sieht so aus als müsste man nur ein paar Kommandozeilenskripte zusammenmixen, einen Schuß C-Code hinzufügen und innerhalb ein paar Stunden ist man fertig: eine Mischung von grundlegenden Dateisystemoperationen und SHA1-Hash-Berechnungen, garniert mit Sperrdateien und Synchronisation für Stabilität. Tatsächlich beschreibt dies die früheste Version von Git. Nichtsdestotrotz, abgesehen von geschickten Verpackungstricks um Speicherplatz zu sparen und geschickten Indizierungstricks um Zeit zu sparen, wissen wir nun, wie Git gewandt ein Dateisystem in eine Datenbank verwandelt, das perfekt für eine Versionsverwaltung geeignet ist.

note: type: Plain text
en: For example, if any file within the object database is corrupted by a disk error, then its hash will no longer match, alerting us to the problem. By hashing hashes of other objects, we maintain integrity at all levels. Commits are atomic, that is, a commit can never only partially record changes: we can only compute the hash of a commit and store it in the database after we already have stored all relevant trees, blobs and parent commits. The object database is immune to unexpected interruptions such as power outages.
de: Angenommen, wenn irgendeine Datei in der Objektdatenbank durch einen Laufwerksfehler zerstört wird, dann wird sein SHA1-Hash-Wert nicht mehr mit seinem Inhalt übereinstimmen und uns sagen, wo das Problem liegt. Durch Bilden von SHA1-Hash-Werten aus den SHA1-Hash-Werten anderer Objekte, erreichen wir Integrität auf allen Ebenen. 'Commits' sind elementar, das heißt, ein 'Commit' kann niemals nur Teile einer Änderung speichern: wir können den SHA1-Hash-Wert eines 'Commits' erst dann berechnen und speichern, nachdem wir bereits alle relevanten 'Tree'-Objekte, 'Blob'-Objekte und Eltern-'Commits' gespeichert haben. Die Objektdatenbank ist immun gegen unerwartete Unterbrechungen wie zum Beispiel einen Stromausfall.

note: type: Plain text
en: We defeat even the most devious adversaries. Suppose somebody attempts to stealthily modify the contents of a file in an ancient version of a project. To keep the object database looking healthy, they must also change the hash of the corresponding blob object since it's now a different string of bytes. This means they'll have to change the hash of any tree object referencing the file, and in turn change the hash of all commit objects involving such a tree, in addition to the hashes of all the descendants of these commits. This implies the hash of the official head differs to that of the bad repository. By following the trail of mismatching hashes we can pinpoint the mutilated file, as well as the commit where it was first corrupted.
de: Wir können sogar den hinterhältigsten Gegnern widerstehen. Stell Dir vor, jemand will den Inhalt einer Datei ändern, die in einer älteren Version eines Projekt liegt. Um die Objektdatenbank intakt aussehen zu lassen, müssten sie außerdem den SHA1-Hash-Wert des korrespondierenden 'Blob'-Objekt ändern, da die Datei nun eine geänderte Zeichenfolge enthält. Das heißt auch, dass sie jeden SHA1-Hash-Wert der 'Tree'-Objekte ändern müssen, welche dieses Objekt referenzieren und demzufolge alle SHA1-Hash-Werte der 'Commit'-Objekte, welche diese 'Tree'-Objekte beinhalten, zusätzlich zu allen Abkömmlingen dieses 'Commits'. Das bedeutet auch, dass sich der SHA1-Hash-Wert des offiziellen HEAD von dem des manipulierten 'Repository' unterscheidet. Folgen wir dem Pfad der differierenden SHA1-Hash-Werte, finden wir die verstümmelte Datei, wie auch den 'Commit', in dem sie erstmals auftauchte.

note: type: Plain text
en: In short, so long as the 20 bytes representing the last commit are safe, it's impossible to tamper with a Git repository.
de: Kurz gesagt, so lange die 20 Byte, welche den SHA1-Hash-Wert des letzen 'Commit' repräsentieren sicher sind, ist es unmöglich ein Git 'Repository' zu fälschen.

note: type: Plain text
en: What about Git's famous features? Branching? Merging? Tags? Mere details. The current head is kept in the file +.git/HEAD+, which contains a hash of a commit object. The hash gets updated during a commit as well as many other commands. Branches are almost the same: they are files in +.git/refs/heads+. Tags too: they live in +.git/refs/tags+ but they are updated by a different set of commands.
de: Was ist mit Git's berühmten Fähigkeiten? 'Branching'? 'Merging'? 'Tags'? Nur Kleinigkeiten. Der aktuelle HEAD wird in der Datei +.git/HEAD+ gehalten, welche den SHA1-Hash-Wert eines 'Commit'-Objekts enthält. Der SHA1-Hash-Wert wird während eines 'Commit' aktualisiert, genauso bei vielen anderen Anweisungen. 'Branches' sind fast das selbe: sie sind Dateien in +.git/refs/heads+. 'Tags' ebenso: sie stehen in +.git/refs/tags+ aber sie werden durch einen Satz anderer Anweisungen aktualisiert.
