Was ist Git?

Commits: Schnappschüsse der Zeit

Ein Commit ist ein gespeicherter Stand des Projekts mit einer Beschreibung. Die Kette aller Commits ist die Historie — man kann jederzeit zurückspringen und sehen, wer wann was geändert hat.

git status              # Was hat sich geändert?
git add .               # Änderungen vormerken
git commit -m "Kontaktformular hinzugefügt"
git push                # Zum Remote hochladen

Branches: parallel arbeiten

Ein Branch ist ein abgezweigter Entwicklungsstrang. Neue Features entstehen in eigenen Branches und werden per Merge zurück in den Hauptzweig geführt — so bleibt der Hauptcode stabil.

Git arbeitet verteilt

Ein wichtiger Unterschied zu älteren Systemen: Git ist verteilt. Jeder Entwickler hat nicht nur die aktuelle Version, sondern die komplette Historie des Projekts lokal auf seinem Rechner. Man kann committen, Branches anlegen und die Geschichte durchsuchen, ohne online zu sein. Erst beim Teilen synchronisiert man über einen Remote-Server. Das macht Git schnell, ausfallsicher und unabhängig — selbst wenn der zentrale Server ausfällt, ist keine Arbeit verloren.

Die Staging-Area: bewusst auswählen

Zwischen deinen Änderungen und dem fertigen Commit liegt in Git eine Zwischenstufe: die Staging-Area. Mit „git add“ wählst du gezielt aus, welche Änderungen in den nächsten Commit sollen — nicht zwangsläufig alle auf einmal. So lassen sich zwei unabhängige Änderungen in zwei saubere, thematisch getrennte Commits packen. Diese bewusste Auswahl ist der Schlüssel zu einer Historie, die man später noch versteht.

Zusammenführen und Konflikte

Wenn zwei Menschen dieselbe Datei bearbeiten, führt Git ihre Änderungen beim Merge automatisch zusammen — solange sie unterschiedliche Stellen betreffen. Ändern beide dieselbe Zeile, entsteht ein Merge-Konflikt: Git kann nicht entscheiden, welche Version gilt, und markiert die Stelle, damit ein Mensch sie auflöst. Konflikte klingen bedrohlich, sind aber normaler Alltag und meist in Minuten gelöst. Kleine, häufige Commits und regelmäßiges Zusammenführen halten sie klein.

Wie Git intern arbeitet

Git denkt nicht in Unterschieden, sondern in Schnappschüssen. Jeder Commit hält den Zustand des Projekts fest und verweist auf seinen Vorgänger — so entsteht eine Kette. Identifiziert wird ein Commit nicht durch eine laufende Nummer, sondern durch eine Prüfsumme, die sich aus seinem Inhalt ergibt. Ändert sich auch nur ein Zeichen, ergibt sich eine andere Prüfsumme; nachträgliche Manipulationen fallen dadurch sofort auf. Ein Branch wiederum ist nichts weiter als ein beweglicher Zeiger auf einen dieser Commits. Genau deshalb kostet das Anlegen eines Branches praktisch nichts — Git kopiert keine Dateien, es setzt nur einen Zeiger.

Tags markieren Versionsstände

Während Branches wandern, bleiben Tags stehen. Ein Tag ist eine feste Markierung an einem bestimmten Commit und dient dazu, veröffentlichte Versionen wiederauffindbar zu machen. Üblich ist eine Nummerierung nach dem Schema Hauptversion.Nebenversion.Korrektur — die erste Stelle steigt bei Änderungen, die bestehende Nutzung brechen, die zweite bei neuen Funktionen, die dritte bei Fehlerkorrekturen. Wer später wissen will, welcher Code an einem Kunden ausgeliefert wurde, springt einfach zum entsprechenden Tag. In der Praxis stoßen Tags außerdem häufig automatisierte Abläufe an, etwa das Bauen und Veröffentlichen einer neuen Version.

Über die reine Codeverwaltung hinaus ist Git heute der Auslöser für fast alle automatisierten Abläufe. Ein Push stößt die Pipeline an, die testet, baut und ausliefert; Konfigurationen für Server und Infrastruktur liegen als Dateien im selben Repository und werden damit ebenso versioniert wie der Code. Auch Dokumentation und Textbausteine wandern zunehmend dorthin, weil sich Änderungen dann genauso nachvollziehen und freigeben lassen. Das ist der eigentliche Grund, warum sich der Einstieg lohnt: Wer Git beherrscht, hat den Zugang zu praktisch allen Werkzeugen moderner Softwareentwicklung.