Git

Kennst du Dateinamen wie hausarbeit_final.doc, hausarbeit_final_wirklich_fertig.doc, hausarbeit_NEU.doc? Das ist Chaos. Git ist die Zeitmaschine für Code. Es speichert jeden Zustand deiner Arbeit. Du kannst jederzeit sagen: "Geh zurück zum Stand von gestern Mittag, bevor ich alles kaputt gemacht habe." Und: Mehrere Leute können gleichzeitig an derselben Datei arbeiten, ohne sich zu überschreiben.

Merksatz: Ein verteiltes Versionsverwaltungssystem, das Änderungen an Dateien protokolliert und die Zusammenarbeit im Team koordiniert.

Lernbruecke für Anfänger

Wenn du bei Git ganz neu startest, denke zuerst nicht an Fachwörter, sondern an die Alltagssituation: Codeversionen nachvollziehbar verwalten. Der Begriff beschreibt einen klaren Baustein im größeren Ablauf. Frage dich immer: Was ist der Eingang, was passiert in der Mitte, und woran erkenne ich am Ende, dass es funktioniert hat?

Ein guter Einstieg ist, den Begriff in einem Satz zu erklären, danach ein reales Beispiel zu nennen und erst dann die Technikdetails zu lernen. So entsteht kein reines Auswendiglernen, sondern ein mentales Modell.

Das wichtigste Tool für Programmierer. Begriffe:

Repository (Repo): Der Projektordner.
Commit: Ein Speicherpunkt ("Foto" der Dateien machen).
Push: Code ins Internet hochladen (z. B. nach GitHub).
Pull: Code von anderen herunterladen.

Erfunden von Linus Torvalds (dem Erfinder von Linux), weil er wütend über schlechte Tools war.

Praxisroutine

In der Praxis lernst du Git, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. Branching & Merging

Das Killer-Feature. Du arbeitest nicht am Haupt-Code ("Main"), sondern machst eine Kopie ("Branch"). Dort kannst du experimentieren. Wenn es klappt, führst du es zurück ("Merge"). Wenn es Konflikte gibt ("Kollege A und B haben beide Zeile 10 geändert"), hilft Git, das zu lösen.

2. Verteiltheit (Distributed)

Git braucht keinen Server. Jeder Entwickler hat die gesamte Geschichte des Projekts auf seinem Laptop. Wenn GitHub offline geht, könnt ihr trotzdem weiterarbeiten und Daten per USB-Stick austauschen.

Technische Einordnung im System

Technisch ist Git nicht isoliert. Es wirkt mit Nachbarbegriffen zusammen, hat Voraussetzungen und erzeugt Folgen. Für ein robustes Verständnis prüfst du drei Fragen: Welche Daten oder Bedingungen braucht dieser Schritt? Welche Ausgabe oder Wirkung entsteht? Was passiert bei falschen, fehlenden oder zu großen Eingaben?

Diese Sicht ist wichtig, weil echte Systeme selten am Hauptpfad scheitern. Sie scheitern an Randfällen, Berechtigungen, Zeitpunkten, Formaten, Reihenfolgen oder stillen Annahmen.

1. Der `.git/objects` Graph (DAG)

Git speichert keine Datei-Änderungen (Deltas) pro Version. Git ist ein Key-Value Data Store. Jeder Commit, jeder Ordner (Tree) und jede Datei (Blob) wird komplett mittels SHA-1 Hash auf 40 Zeichen gehasht und gepackt (.git/objects/f9/a8b7...). Wenn du eine 1GB Video-Datei commitst, danach ein Zeichen änderst und neu commitst, frisst Git 2GB SSD-Platz. Dieser Directed Acyclic Graph (DAG) macht Git blitzschnell: Der Branch main ist keine Kopie deiner Festplatte, sondern nur ein mikroskopisch kleiner 40-Zeichen String-Pointer in einem Textfile (.git/refs/heads/main), der auf den neuesten Commit Node zeigt.

2. Rebasing vs. Merging

Die größte Architektur-Glaubensfrage im DevOps.

Merge: Nimm Branch A und Branch B und schnüre sie mit einem hässlichen "Merge-Knoten" (M) zusammen. Historie bleibt 100% erhalten (Wahrheit), sieht aber aus wie ein U-Bahn-Plan aus Tokio.
Rebase: Du sägst Branch B an der Wurzel ab und pflanzt ihn "an die Spitze" von Branch A (git rebase main). Die Historie wird umgeschrieben (!). Sie ist nun eine absolut perfekte, gerade Linie. Schön für den Code-Reviewer. Fatal, wenn du eine Historie umschreibst, die Kollegen schon gepulled haben (Zusammenbruch aller Pointers).

3. Reflog und der Garbage Collector

Viele haben Angst, Commits zu verlieren ("Ich habe versehentlich Reset --hard gedrückt!"). Git löscht Commits nie sofort. Selbst wenn ein Branch gelöscht wird, schwebt der Commit-Blob als "Dangling Object" unsichtbar in der .git Datenbank weiter. Mit git reflog (Reference Logs) kannst du Wochen in die Vergangenheit schauen. HEAD@{4} zeigt, welches Hash-Objekt noch vor vier Operationen aktiv war. Erst wenn Gits interner Garbage Collector (git gc) tief in der Nacht läuft und periodisch Reste zusammenfegt, werden abgetrennte (dangling) Graphen physikalisch von der SSD gelöscht.