Was ist Git und warum braucht man es als Entwickler?

Was ist Git? Ein Versionskontrollsystem

Git ist ein Programm, das sich die Änderungshistorie der Dateien eines Projekts merkt. Jedes Mal, wenn Sie den Stand des Codes festhalten, speichert Git einen Snapshot (Commit) mit Autor, Datum und Beschreibung. Zu jedem Snapshot können Sie zurückkehren, ihn mit dem aktuellen Stand vergleichen und herausfinden, wer eine bestimmte Zeile wann und warum geändert hat.

Wenn Sie schon einmal Ordner wie „projekt_v2“, „projekt_final“ und „projekt_final_WIRKLICH_FINAL“ angelegt haben, haben Sie bereits Versionskontrolle betrieben – nur von Hand. Git erledigt dasselbe automatisch, platzsparend und ohne Angst, etwas zu verlieren. Wenn Entwickler über Git sprechen, meinen sie deshalb nicht einfach irgendein Programm, sondern ein grundlegendes Arbeitswerkzeug, so selbstverständlich wie der Code-Editor.

Was unterscheidet Git von einem Ordner mit Kopien oder einem Cloud-Speicher?

Ein Cloud-Speicher hält die letzte Version einer Datei vor und bestenfalls ein paar automatische Kopien. Git speichert eine sinnvolle Historie: Sie entscheiden selbst, wann Sie Änderungen festhalten, und beschreiben, was genau Sie getan haben. Außerdem kann Git Dinge, die kein Cloud-Speicher beherrscht:

• mehrere Entwicklungslinien gleichzeitig führen (Branches) und zusammenführen;
• zeilengenaue Unterschiede zwischen Versionen anzeigen (git diff);
• Änderungen verschiedener Personen an denselben Dateien zusammenführen;
• den Commit finden, mit dem ein Fehler eingeschleppt wurde (git bisect);
• ohne Internet arbeiten – die gesamte Historie liegt lokal bei Ihnen.

Was bedeutet „Git“? Herkunft des Namens

Eine offizielle Auflösung gibt es nicht – Git ist keine Abkürzung. Linus Torvalds hat das Programm ganz in seinem Stil benannt: Im britischen Slang ist „git“ ein „unangenehmer, sturer Kerl“. Torvalds selbst witzelte, er benenne alle seine Projekte nach sich selbst. Wörtlich übersetzt bedeutet git ungefähr „Blödmann“ oder „Mistkerl“.

In der ersten README des Projekts schlug der Autor einige scherzhafte Lesarten vor, etwa „global information tracker“ – wenn alles funktioniert – und eine derbe Variante für den Fall, dass etwas kaputtgeht. Wenn Sie also im Vorstellungsgespräch gefragt werden, wofür Git steht, lautet die richtige Antwort: für nichts, es ist ein Wort und kein Akronym.

Ausgesprochen wird Git mit hartem „g“ wie in „Gift“, also „Git“ und nicht „Dschit“.

Wie Git entstanden ist

Bis 2005 nutzten die Entwickler des Linux-Kernels das proprietäre System BitKeeper. Als die kostenlose Lizenz für die Community zurückgezogen wurde, schrieb Torvalds innerhalb weniger Wochen ein eigenes System. Die Anforderungen waren hart: Geschwindigkeit bei einem riesigen Projekt, vollständig verteiltes Arbeiten, zuverlässiger Schutz der Historie vor Beschädigung und komfortabler Umgang mit Tausenden paralleler Branches.

Bald darauf übernahm Junio Hamano die Pflege des Projekts, er ist bis heute Maintainer von Git. Git ist Open Source unter der GPLv2, und auf seiner Basis laufen GitHub, GitLab, Bitbucket, Gitea und zahlreiche Unternehmensplattformen.

Wie Git als System funktioniert

Damit Git nicht wie eine Sammlung magischer Befehle wirkt, lohnt es sich, drei Ideen zu verstehen. Sie erklären fast das gesamte Verhalten des Systems.

1. Snapshots statt Differenzen

Viele ältere Systeme speicherten Änderungen als Folge von Patches an Dateien. Git denkt in Snapshots: Jeder Commit ist der vollständige Zustand des Projekts zum Zeitpunkt des Festhaltens. Um Platz zu sparen, werden unveränderte Dateien nicht kopiert – der Commit verweist einfach auf das bereits gespeicherte Objekt. Beim Packen des Repositorys komprimiert Git ähnliche Objekte zusätzlich, sodass selbst die Historie eines großen Projekts wenig Platz belegt.

2. Alles wird über einen Hash adressiert

Jedes Objekt in Git – Dateiinhalt (blob), Verzeichnisstruktur (tree), Commit (commit) – erhält eine aus seinem Inhalt berechnete Kennung. Historisch ist das SHA-1 (40 Hexadezimalzeichen), in neueren Versionen lässt sich ein Repository auch mit SHA-256 anlegen. Einen alten Commit unbemerkt zu verändern ist unmöglich: Sein Hash und die Hashes aller nachfolgenden Commits würden sich ändern.

$ git log --oneline -3
a3f9c21 Login-Formular hinzufügen
7b02e4d E-Mail-Validierung korrigieren
1c8d5f0 Erster Commit

Die kurzen Zeichenfolgen links sind abgekürzte Commit-Hashes. Über sie können Sie jede Version ansprechen: git show 7b02e4d.

3. Die drei Zustände von Dateien

Das ist das Fundament von Git und wird in fast jedem Vorstellungsgespräch abgefragt. Eine Datei im Projekt kann sich in einem von drei Bereichen befinden:

Der Index unterscheidet Git von vielen anderen Systemen. Mit ihm können Sie nur einen Teil der Änderungen in einen Commit packen: etwa den Bugfix separat und das Umbenennen von Variablen separat. So bleibt die Historie lesbar.

Verteilt: Warum jeder eine vollständige Kopie hat

Git ist ein verteiltes Versionskontrollsystem (DVCS). Beim Klonen erhalten Sie nicht nur die aktuellen Dateien, sondern die komplette Projekthistorie. Die meisten Operationen – Commit, History ansehen, Branch anlegen, Vergleichen – laufen lokal und sofort, ganz ohne Server.

Ein Server wie GitHub ist in diesem Modell nur eine weitere Kopie des Repositorys, auf die sich das Team als Hauptkopie geeinigt hat. Ist er nicht erreichbar, steht die Arbeit nicht still: Sie committen weiter und übertragen die Änderungen später mit git push. Geht der Server ganz verloren, lässt sich die Historie aus jedem beliebigen Klon wiederherstellen.

Git und GitHub sind nicht dasselbe

Eine häufige Verwechslung bei Einsteigern. Git ist ein Programm, das auf Ihrem Rechner läuft. GitHub ist ein Webdienst, auf dem Git-Repositorys liegen und der Werkzeuge für die Teamarbeit bietet: Pull Requests, Code-Reviews, Issues, CI. GitLab und Bitbucket sind vergleichbare Dienste.

Sie können Git auch ganz ohne GitHub nutzen – etwa für persönliche Notizen oder ein lokales Projekt. GitHub ohne Git ergibt dagegen keinen Sinn: Der Dienst ist um Git-Repositorys herum gebaut.

Git-Grundlagen: der minimale Arbeitsablauf

So sieht die tägliche Arbeit aus. Diese paar Befehle decken den Großteil dessen ab, was Entwickler jeden Tag tun.

# Repository im aktuellen Ordner anlegen
git init

# nachsehen, was sich geändert hat
git status

# Dateien zum Index hinzufügen
git add index.html style.css

# Snapshot festhalten
git commit -m "Startseite umsetzen"

# Historie ansehen
git log --oneline

# Branch anlegen und dorthin wechseln
git switch -c feature/login

# Branch in den Hauptbranch mergen
git switch main
git merge feature/login

# Änderungen zum Server übertragen
git push origin main

Der Befehl git switch kam mit Git 2.23 als verständlicherer Ersatz für einen Teil der Funktionen von git checkout. In älteren Anleitungen begegnet Ihnen git checkout -b feature/login – das bewirkt dasselbe.

Was passiert bei git commit?

Git nimmt den Inhalt des Index, speichert jede Datei als blob, baut tree-Objekte für die Verzeichnisse und erzeugt ein commit-Objekt. Im Commit stehen: ein Verweis auf den Tree, ein Verweis auf den Eltern-Commit (oder zwei – nach einem Merge), Autor, Committer und Nachricht. Danach rückt der Zeiger des aktuellen Branches auf den neuen Commit vor. Ein Branch ist in Git buchstäblich eine Datei mit dem Hash des letzten Commits, deshalb entstehen Branches in Millisekunden.

Wozu Git als Entwickler? Die praktischen Gründe

Experimente ohne Angst

Jede Änderung lässt sich rückgängig machen. Code kaputt? git restore datei holt die zuletzt festgehaltene Version zurück. Ein missglückter Commit ist schon in der Historie? git revert erzeugt einen Gegen-Commit, ohne die gemeinsame Historie umzuschreiben. Das verändert die Arbeitsweise: Sie probieren mutiger aus, weil ein Rückschritt nur Sekunden kostet.

Teamarbeit ohne Chaos

Jeder Entwickler arbeitet in seinem eigenen Branch und stört die anderen nicht. Ist eine Aufgabe fertig, durchlaufen die Änderungen ein Review und werden in den Hauptbranch gemergt. Haben zwei Personen dieselbe Stelle bearbeitet, zeigt Git einen Konflikt an und lässt Sie ihn bewusst auflösen, statt fremde Arbeit stillschweigend zu überschreiben.

Historie als Dokumentation

Gute Commit-Nachrichten beantworten die Frage, warum der Code so ist, wie er ist. git blame datei zeigt, wer jede Zeile zuletzt in welchem Commit geändert hat, und git log -p datei die gesamte Entwicklung der Datei. Ein Jahr später spart das stundenlange Detektivarbeit.

Arbeitgeber setzen es voraus

Git-Kenntnisse stehen in praktisch jeder Stellenanzeige für Entwickler, Tester, DevOps-Engineers und Data Analysts. Im Vorstellungsgespräch geht es nicht um auswendig gelernte Befehle, sondern um Verständnis: Was unterscheidet merge von rebase, was ist der Index, wie macht man einen Commit rückgängig, wie löst man einen Konflikt? Und ein GitHub-Profil mit sauberer Commit-Historie funktioniert wie ein Portfolio.

Wer braucht Git noch?

Git ist überall praktisch, wo es Textdateien gibt und die Historie zählt: für Technical Writer (Dokumentation in Markdown), Frontend-Designer, Analysten (SQL-Skripte, Notebooks), Administratoren (Serverkonfigurationen, Infrastructure as Code). Für große Binärdateien – Videos, PSD-Dateien, Datensätze – nutzt man die Erweiterung Git LFS, weil Git selbst auf Text optimiert ist.

Pro Git – das beste Buch über Git

Wenn Sie tiefer einsteigen möchten, beginnen Sie mit „Pro Git“ von Scott Chacon und Ben Straub. Das Buch ist kostenlos, steht unter einer freien Lizenz und ist auf der offiziellen Website git-scm.com im Bereich Book veröffentlicht, auch in deutscher Übersetzung. Es ist ein vollwertiges Lehrbuch von den Grundlagen bis zu den Interna.

So lesen Sie es mit Gewinn:

• Kapitel 1–3 (Einführung, Grundlagen, Branching) sind das Pflichtminimum – tippen Sie die Befehle im Terminal mit;
• das Kapitel über Remote-Repositorys und GitHub – sobald Sie im Team arbeiten;
• das Kapitel „Git Interna“ – wenn Sie wirklich verstehen wollen, wie Objekte und Referenzen aufgebaut sind.

Die zweite offizielle Stütze ist die eingebaute Hilfe: git help commit oder git commit --help öffnen die vollständige Dokumentation eines Befehls, git commit -h zeigt eine kurze Übersicht der Optionen.

Typische Irrtümer von Einsteigern

• „Git speichert Dateien automatisch.“ Nein, solange Sie keinen Commit gemacht haben, existieren die Änderungen nur im Arbeitsverzeichnis.
• „Ein Commit landet sofort auf GitHub.“ Ein Commit ist lokal. Auf den Server gelangt er erst nach git push.
• „git add ist nur für neue Dateien.“ git add nimmt auch Änderungen an bereits versionierten Dateien in den Index auf.
• „Was aus der Historie gelöscht ist, ist weg.“ Fast immer lässt es sich zurückholen: git reflog speichert die Bewegungen der Zeiger, und der „verlorene“ Commit ist über seinen Hash auffindbar.
• „Branches sind Kopien des Projekts.“ Ein Branch ist ein leichtgewichtiger Zeiger auf einen Commit, kein Duplikat der Dateien.

Git lernen: Womit fängt man an?

1. Installieren Sie Git und prüfen Sie die Version: git --version.
2. Richten Sie Name und E-Mail ein: git config --global user.name und user.email.
3. Legen Sie ein Übungs-Repository an, machen Sie 5–10 Commits und sehen Sie sich git log und git diff an.
4. Arbeiten Sie mit Branches: anlegen, mergen, absichtlich einen Konflikt provozieren und ihn auflösen.
5. Erstellen Sie ein GitHub-Konto, pushen Sie Ihr Repository dorthin und öffnen Sie Ihren ersten Pull Request.

Diese Reihenfolge bringt schneller Ergebnisse als das Durchlesen von Nachschlagewerken: Sie sehen sofort, wie jeder Befehl den Zustand des Repositorys verändert.

Fazit

Git ist ein verteiltes Versionskontrollsystem, das die Projekthistorie als Snapshots speichert, sie mit Hashes absichert und einem Team paralleles Arbeiten in Branches ermöglicht. Eine Auflösung des Namens gibt es nicht, in der Praxis ist Git schlicht das Pflichtwerkzeug jedes Entwicklers. Verinnerlichen Sie den Ablauf add – commit – push, verstehen Sie die drei Bereiche und Branches und vertiefen Sie dann Ihr Wissen mit Pro Git. All das wird im Git-Kurs Schritt für Schritt in der Praxis erarbeitet, vom ersten Commit bis zum Pull Request.