![\"xkcd](\"https://imgs.xkcd.com/comics/git.png\")
Versionskontrollsysteme (VCSs) sind Werkzeuge, die verwendet werden, um Änderungen an Quellcode (oder anderen Sammlungen von Dateien und Ordnern) zu verfolgen. Wie der Name schon sagt, helfen diese Werkzeuge dabei, eine Historie von Änderungen zu pflegen; darüber hinaus erleichtern sie die Zusammenarbeit. VCSs verfolgen Änderungen an einem Ordner und seinem Inhalt in einer Reihe von Snapshots, wobei jeder Snapshot den gesamten Zustand von Dateien/Ordnern innerhalb eines Top-Level-Verzeichnisses kapselt. VCSs pflegen auch Metadaten wie wer jeden Snapshot erstellt hat, Nachrichten, die mit jedem Snapshot verbunden sind, und so weiter.
\n\nWarum ist Versionskontrolle nützlich? Selbst wenn Sie alleine arbeiten, können Sie sich alte Snapshots eines Projekts ansehen, ein Protokoll darüber führen, warum bestimmte Änderungen vorgenommen wurden, an parallelen Entwicklungszweigen arbeiten und vieles mehr. Bei der Arbeit mit anderen ist es ein unschätzbares Werkzeug, um zu sehen, was andere Personen geändert haben, sowie um Konflikte in der gleichzeitigen Entwicklung zu lösen.
\n\nModerne VCSs ermöglichen es Ihnen auch, Fragen wie diese einfach (und oft automatisch) zu beantworten:
\n\nObwohl andere VCSs existieren, ist Git der De-facto-Standard für Versionskontrolle. Dieser XKCD-Comic erfasst Gits Ruf:
\n\n
Da Gits Schnittstelle eine undichte Abstraktion ist, kann das Erlernen von Git von oben nach unten (beginnend mit seiner Schnittstelle / Befehlszeilenschnittstelle) zu viel Verwirrung führen. Es ist möglich, eine Handvoll Befehle auswendig zu lernen und sie als magische Beschwörungen zu betrachten und dem Ansatz im obigen Comic zu folgen, wann immer etwas schief geht.
\n\nObwohl Git zugegebenermaßen eine hässliche Schnittstelle hat, sind sein zugrunde liegendes Design und seine Ideen schön. Während eine hässliche Schnittstelle auswendig gelernt werden muss, kann ein schönes Design verstanden werden. Aus diesem Grund geben wir eine Bottom-up-Erklärung von Git, beginnend mit seinem Datenmodell und später mit der Befehlszeilenschnittstelle. Sobald das Datenmodell verstanden ist, können die Befehle besser verstanden werden, wie sie das zugrunde liegende Datenmodell manipulieren.
\n\nEs gibt viele Ad-hoc-Ansätze, die Sie für die Versionskontrolle verwenden könnten. Git hat ein gut durchdachtes Modell, das alle schönen Funktionen der Versionskontrolle ermöglicht, wie das Pflegen der Historie, das Unterstützen von Branches und das Ermöglichen der Zusammenarbeit.
\n\nGit modelliert die Historie einer Sammlung von Dateien und Ordnern innerhalb eines Top-Level-Verzeichnisses als eine Reihe von Snapshots. In der Git-Terminologie wird eine Datei als \"blob\" bezeichnet, und es ist einfach eine Menge von Bytes. Ein Verzeichnis wird als \"tree\" bezeichnet, und es ordnet Namen Blobs oder Trees zu (sodass Verzeichnisse andere Verzeichnisse enthalten können). Ein Snapshot ist der Top-Level-Tree, der verfolgt wird. Zum Beispiel könnten wir einen Tree wie folgt haben:
\n\n<root> (tree)\n|\n+- foo (tree)\n| |\n| + bar.txt (blob, contents = \"hello world\")\n|\n+- baz.txt (blob, contents = \"git is wonderful\")\nDer Top-Level-Tree enthält zwei Elemente, einen Tree \"foo\" (der selbst ein Element enthält, einen Blob \"bar.txt\"), und einen Blob \"baz.txt\".
\n\nWie sollte ein Versionskontrollsystem Snapshots in Beziehung setzen? Ein einfaches Modell wäre eine lineare Historie. Eine Historie wäre eine Liste von Snapshots in zeitlicher Reihenfolge. Aus vielen Gründen verwendet Git kein so einfaches Modell.
\n\nIn Git ist eine Historie ein gerichteter azyklischer Graph (DAG) von Snapshots. Das mag wie ein ausgefallenes Mathematikwort klingen, aber lassen Sie sich nicht einschüchtern. Das bedeutet nur, dass jeder Snapshot in Git auf eine Menge von \"Eltern\" verweist, die Snapshots, die ihm vorausgingen. Es ist eine Menge von Eltern und nicht ein einzelner Elternteil (wie es bei einer linearen Historie der Fall wäre), weil ein Snapshot von mehreren Eltern abstammen könnte, zum Beispiel aufgrund der Kombination (Zusammenführung) zweier paralleler Entwicklungszweige.
\n\nGit nennt diese Snapshots \"Commits\". Die Visualisierung einer Commit-Historie könnte etwa so aussehen:
\n\no <-- o <-- o <-- o\n ^\n \\\n --- o <-- o\nIn der ASCII-Kunst oben entsprechen die os einzelnen Commits (Snapshots). Die Pfeile zeigen auf den Elternteil jedes Commits (es ist eine \"kommt vor\"-Beziehung, nicht \"kommt nach\"). Nach dem dritten Commit verzweigt sich die Historie in zwei separate Branches. Dies könnte zum Beispiel zwei separaten Features entsprechen, die parallel und unabhängig voneinander entwickelt werden. In der Zukunft können diese Branches zusammengeführt werden, um einen neuen Snapshot zu erstellen, der beide Features enthält, was eine neue Historie erzeugt, die so aussieht, wobei der neu erstellte Merge-Commit fett dargestellt ist:
\n\no <-- o <-- o <-- o <---- o\n ^ /\n \\ v\n --- o <-- o\n\n\n\nCommits in Git sind unveränderlich. Das bedeutet nicht, dass Fehler nicht korrigiert werden können; es bedeutet nur, dass \"Bearbeitungen\" der Commit-Historie tatsächlich völlig neue Commits erstellen, und Referenzen (siehe unten) werden aktualisiert, um auf die neuen zu zeigen.
\n\nEs kann lehrreich sein, Gits Datenmodell in Pseudocode aufgeschrieben zu sehen:
\n\n// eine Datei ist eine Menge von Bytes\ntype blob = array<byte>\n\n// ein Verzeichnis enthält benannte Dateien und Verzeichnisse\ntype tree = map<string, tree | blob>\n\n// ein Commit hat Eltern, Metadaten und den Top-Level-Tree\ntype commit = struct {\n parents: array<commit>\n author: string\n message: string\n snapshot: tree\n}\nEs ist ein sauberes, einfaches Modell der Historie.
\n\nEin \"Objekt\" ist ein Blob, Tree oder Commit:
\n\ntype object = blob | tree | commit\nIm Git-Datenspeicher werden alle Objekte durch ihren SHA-1-Hash inhaltsadressiert.
\n\nobjects = map<string, object>\n\ndef store(object):\n id = sha1(object)\n objects[id] = object\n\ndef load(id):\n return objects[id]\nBlobs, Trees und Commits sind auf diese Weise vereinheitlicht: Sie sind alle Objekte. Wenn sie auf andere Objekte verweisen, enthalten sie diese nicht tatsächlich in ihrer On-Disk-Darstellung, sondern haben eine Referenz auf sie durch ihren Hash.
\n\nZum Beispiel sieht der Tree für die Beispielverzeichnisstruktur oben (visualisiert mit git cat-file -p 698281bc680d1995c5f4caaf3359721a5a58d48d) so aus:
100644 blob 4448adbf7ecd394f42ae135bbeed9676e894af85 baz.txt\n040000 tree c68d233a33c5c06e0340e4c224f0afca87c8ce87 foo\nDer Tree selbst enthält Zeiger auf seinen Inhalt, baz.txt (ein Blob) und foo (ein Tree). Wenn wir uns den Inhalt ansehen, der durch den Hash adressiert wird, der baz.txt entspricht, mit git cat-file -p 4448adbf7ecd394f42ae135bbeed9676e894af85, erhalten wir Folgendes:
git is wonderful\nNun können alle Snapshots durch ihre SHA-1-Hashes identifiziert werden. Das ist unpraktisch, weil Menschen nicht gut darin sind, sich Zeichenfolgen von 40 Hexadezimalzeichen zu merken.
\n\nGits Lösung für dieses Problem sind menschenlesbare Namen für SHA-1-Hashes, genannt \"Referenzen\". Referenzen sind Zeiger auf Commits. Im Gegensatz zu Objekten, die unveränderlich sind, sind Referenzen veränderlich (können aktualisiert werden, um auf einen neuen Commit zu zeigen). Zum Beispiel zeigt die master-Referenz normalerweise auf den neuesten Commit im Hauptentwicklungszweig.
references = map<string, string>\n\ndef update_reference(name, id):\n references[name] = id\n\ndef read_reference(name):\n return references[name]\n\ndef load_reference(name_or_id):\n if name_or_id in references:\n return load(references[name_or_id])\n else:\n return load(name_or_id)\nDamit kann Git menschenlesbare Namen wie \"master\" verwenden, um auf einen bestimmten Snapshot in der Historie zu verweisen, anstatt auf eine lange Hexadezimalzeichenfolge.
\n\nEin Detail ist, dass wir oft eine Vorstellung davon haben wollen, \"wo wir uns gerade befinden\" in der Historie, damit wir, wenn wir einen neuen Snapshot machen, wissen, relativ zu was er ist (wie wir das parents-Feld des Commits setzen). In Git ist dieses \"wo wir uns gerade befinden\" eine spezielle Referenz namens \"HEAD\".
Schließlich können wir definieren, was (ungefähr) ein Git-Repository ist: Es sind die Daten objects und references.
Auf der Festplatte speichert Git nur Objekte und Referenzen: Das ist alles, was es zu Gits Datenmodell gibt. Alle git-Befehle bilden sich auf eine Manipulation des Commit-DAG ab, indem Objekte hinzugefügt und Referenzen hinzugefügt/aktualisiert werden.
Wann immer Sie einen Befehl eingeben, denken Sie darüber nach, welche Manipulation der Befehl an der zugrunde liegenden Graphdatenstruktur vornimmt. Umgekehrt, wenn Sie versuchen, eine bestimmte Art von Änderung am Commit-DAG vorzunehmen, z.B. \"nicht committete Änderungen verwerfen und die 'master'-Referenz auf Commit 5d83f9e zeigen lassen\", gibt es wahrscheinlich einen Befehl dafür (z.B. in diesem Fall git checkout master; git reset --hard 5d83f9e).
Dies ist ein weiteres Konzept, das orthogonal zum Datenmodell ist, aber es ist ein Teil der Schnittstelle zum Erstellen von Commits.
\n\nEine Möglichkeit, wie Sie sich das Erstellen von Snapshots wie oben beschrieben vorstellen könnten, wäre ein \"Snapshot erstellen\"-Befehl, der einen neuen Snapshot basierend auf dem aktuellen Zustand des Arbeitsverzeichnisses erstellt. Einige Versionskontrollwerkzeuge funktionieren so, aber nicht Git. Wir wollen saubere Snapshots, und es ist möglicherweise nicht immer ideal, einen Snapshot vom aktuellen Zustand zu erstellen. Stellen Sie sich zum Beispiel ein Szenario vor, in dem Sie zwei separate Features implementiert haben und zwei separate Commits erstellen möchten, wobei der erste das erste Feature einführt und der nächste das zweite Feature einführt. Oder stellen Sie sich ein Szenario vor, in dem Sie Debug-Print-Anweisungen überall in Ihrem Code hinzugefügt haben, zusammen mit einem Bugfix; Sie möchten den Bugfix committen, während Sie alle Print-Anweisungen verwerfen.
\n\nGit berücksichtigt solche Szenarien, indem es Ihnen ermöglicht, anzugeben, welche Änderungen im nächsten Snapshot enthalten sein sollen, durch einen Mechanismus namens \"Staging-Bereich\".
\n\nUm Informationen nicht zu duplizieren, werden wir die folgenden Befehle nicht im Detail erklären. Siehe das sehr empfohlene Pro Git für weitere Informationen.
\n\nDer Befehl git init initialisiert ein neues Git-Repository, wobei Repository-Metadaten im .git-Verzeichnis gespeichert werden:
$ mkdir myproject\n$ cd myproject\n$ git init\nInitialized empty Git repository in .git\n$ git status\nOn branch master\nNo commits yet\nnothing to commit (create/copy files and use \"git add\" to track)\nWie interpretieren wir diese Ausgabe? \"No commits yet\" bedeutet im Grunde, dass unsere Versionshistorie leer ist. Lassen Sie uns das beheben.
\n\n$ echo \"hello, git\" > hello.txt\n$ git add hello.txt\n$ git status\nOn branch master\nNo commits yet\nChanges to be committed:\n (use \"git rm --cached <file>...\" to unstage)\n new file: hello.txt\n$ git commit -m 'Initial commit'\n[master (root-commit) 4515d17] Initial commit\n 1 file changed, 1 insertion(+)\n create mode 100644 hello.txt\nDamit haben wir eine Datei mit git add zum Staging-Bereich hinzugefügt und dann diese Änderung mit git commit committet, wobei wir eine einfache Commit-Nachricht \"Initial commit\" hinzugefügt haben. Wenn wir keine -m-Option angegeben hätten, würde Git unseren Texteditor öffnen, damit wir eine Commit-Nachricht eingeben können.
Jetzt, da wir eine nicht-leere Versionshistorie haben, können wir die Historie visualisieren. Die Visualisierung der Historie als DAG kann besonders hilfreich sein, um den aktuellen Status des Repos zu verstehen und ihn mit Ihrem Verständnis des Git-Datenmodells zu verbinden.
\n\nDer Befehl git log visualisiert die Historie. Standardmäßig zeigt er eine abgeflachte Version, die die Graphstruktur verbirgt. Wenn Sie einen Befehl wie git log --all --graph --decorate verwenden, zeigt er Ihnen die vollständige Versionshistorie des Repositories, visualisiert in Graphform.
$ git log --all --graph --decorate\n* commit 4515d17a167bdef0a91ee7d50d75b12c9c2652aa (HEAD -> master)\n Author: Subramanya N <subramanyanagabhushan@gmail.com>\n Date: Tue Dec 21 22:18:36 2020 -0500\n Initial commit\nDas sieht nicht sehr graphartig aus, weil es nur einen einzigen Knoten enthält. Lassen Sie uns einige weitere Änderungen vornehmen, einen neuen Commit erstellen und die Historie noch einmal visualisieren.
\n\n$ echo \"another line\" >> hello.txt\n$ git status\nOn branch master\nChanges not staged for commit:\n (use \"git add <file>...\" to update what will be committed)\n (use \"git checkout -- <file>...\" to discard changes in working directory)\n modified: hello.txt\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n$ git add hello.txt\n$ git status\nOn branch master\nChanges to be committed:\n (use \"git reset HEAD <file>...\" to unstage)\n modified: hello.txt\n$ git commit -m 'Add a line'\n[master 35f60a8] Add a line\n 1 file changed, 1 insertion(+)\nWenn wir jetzt die Historie erneut visualisieren, sehen wir etwas von der Graphstruktur:
\n\n* commit 35f60a825be0106036dd2fbc7657598eb7b04c67 (HEAD -> master)\n| Author: Subramanya N <subramanyanagabhushan@gmail.com>\n| Date: Tue Dec 21 22:26:20 2020 -0500\n| Add a line\n* commit 4515d17a167bdef0a91ee7d50d75b12c9c2652aa\n Author: Subramanya N <subramanyanagabhushan@gmail.com>\n Date: Tue Dec 21 22:18:36 2020 -0500\n Initial commit\nBeachten Sie auch, dass es den aktuellen HEAD zusammen mit dem aktuellen Branch (master) zeigt.
\n\nWir können uns alte Versionen mit dem Befehl git checkout ansehen.
$ git checkout 4515d17 # vorheriger Commit-Hash; Ihrer wird anders sein\nNote: checking out '4515d17'.\nYou are in 'detached HEAD' state. You can look around, make experimental\nchanges and commit them, and you can discard any commits you make in this\nstate without impacting any branches by performing another checkout.\nIf you want to create a new branch to retain commits you create, you may\ndo so (now or later) by using -b with the checkout command again. Example:\n git checkout -b <new-branch-name>\nHEAD is now at 4515d17 Initial commit\n$ cat hello.txt\nhello, git\n$ git checkout master\nPrevious HEAD position was 4515d17 Initial commit\nSwitched to branch 'master'\n$ cat hello.txt\nhello, git\nanother line\nGit kann Ihnen zeigen, wie sich Dateien entwickelt haben (Unterschiede oder Diffs) mit dem Befehl git diff:
$ git diff 4515d17 hello.txt\ndiff --git c/hello.txt w/hello.txt\nindex 94bab17..f0013b2 100644\n--- c/hello.txt\n+++ w/hello.txt\n@@ -1 +1,2 @@\n hello, git\n +another line\ngit help <command>: Hilfe für einen Git-Befehl erhaltengit init: erstellt ein neues Git-Repo, mit Daten, die im .git-Verzeichnis gespeichert sindgit status: sagt Ihnen, was vor sich gehtgit add <filename>: fügt Dateien zum Staging-Bereich hinzugit commit: erstellt einen neuen Commit\ngit log: zeigt ein abgeflachtes Protokoll der Historiegit log --all --graph --decorate: visualisiert die Historie als DAGgit diff <filename>: zeigt Änderungen, die Sie relativ zum Staging-Bereich vorgenommen habengit diff <revision> <filename>: zeigt Unterschiede in einer Datei zwischen Snapshotsgit checkout <revision>: aktualisiert HEAD und aktuellen BranchBranching ermöglicht es Ihnen, die Versionshistorie zu \"forken\". Es kann hilfreich sein, um an unabhängigen Features oder Bugfixes parallel zu arbeiten. Der Befehl git branch kann verwendet werden, um neue Branches zu erstellen; git checkout -b <branch name> erstellt einen Branch und checkt ihn aus.
Merging ist das Gegenteil von Branching: Es ermöglicht Ihnen, geforkte Versionshistorien zu kombinieren, z.B. einen Feature-Branch zurück in master zu mergen. Der Befehl git merge wird zum Mergen verwendet.
git branch: zeigt Branchesgit branch <name>: erstellt einen Branchgit checkout -b <name>: erstellt einen Branch und wechselt zu ihm\ngit branch <name>; git checkout <name>git merge <revision>: merged in den aktuellen Branchgit mergetool: verwenden Sie ein ausgefallenes Tool, um Merge-Konflikte zu lösengit rebase: rebase eine Menge von Patches auf eine neue Basisgit remote: listet Remotes aufgit remote add <name> <url>: fügt ein Remote hinzugit push <remote> <local branch>:<remote branch>: sendet Objekte an Remote und aktualisiert Remote-Referenzgit branch --set-upstream-to=<remote>/<remote branch>: richtet Korrespondenz zwischen lokalem und Remote-Branch eingit fetch: ruft Objekte/Referenzen von einem Remote abgit pull: dasselbe wie git fetch; git mergegit clone: lädt Repository von Remote heruntergit commit --amend: bearbeitet den Inhalt/die Nachricht eines Commitsgit reset HEAD <file>: unstage eine Dateigit checkout -- <file>: verwirft Änderungengit config: Git ist hochgradig anpassbargit clone --depth=1: flacher Klon, ohne gesamte Versionshistoriegit add -p: interaktives Staginggit rebase -i: interaktives Rebasinggit blame: zeigt, wer zuletzt welche Zeile bearbeitet hatgit stash: entfernt vorübergehend Änderungen aus dem Arbeitsverzeichnisgit bisect: binäre Suche in der Historie (z.B. nach Regressionen).gitignore: spezifiziert absichtlich nicht verfolgte Dateien, die ignoriert werden sollen