Git

Das Git ist ein verteiltes Versionskontrollsystem, das Linus Torvalds 2005 ursprünglich für die Linux-Kernel-Entwicklung geschaffen hat. Es zeichnet jede Änderung an Dateien als Commit auf und ermöglicht so, frühere Stände wiederherzustellen, Änderungen zu vergleichen und parallel an unterschiedlichen Aufgaben zu arbeiten.

Git ist heute der De-facto-Standard für Versionskontrolle — in Software-Entwicklung, Web-Projekten, technischer Dokumentation, sogar bei einzelnen Texten und Konfigurationsdateien. Wer professionell mit Code arbeitet, kommt an Git nicht vorbei.

Grundbegriffe

Ein paar Begriffe tauchen ständig auf:

• Commit — eine Momentaufnahme der Änderungen mit Beschreibung, Autor und Zeitstempel.
• Branch — eine eigene Entwicklungslinie. Üblich: main als stabile Linie, Feature-Branches für Arbeit an Einzelthemen.
• Merge — zwei Branches werden zusammengeführt.
• Rebase — Commits werden auf einen anderen Ausgangspunkt umgesetzt; alternative Strategie zum Merge.
• Remote — eine entfernte Kopie des Repositories, üblicherweise auf einem Server.
• Pull / Push — Änderungen vom Remote holen bzw. dorthin senden.
• Tag — markierter Stand, oft für Releases.

Verteilung als Prinzip

Anders als ältere Versionskontrollsysteme (CVS, SVN) ist Git verteilt: jede Kopie des Repositories enthält die vollständige Historie. Es gibt keinen technisch bevorzugten zentralen Server — wohl aber meistens organisatorische zentrale Plattformen wie GitHub, GitLab, Bitbucket oder selbstgehostete Forgejo/Gitea-Instanzen, über die Teams zusammenarbeiten.

Workflows

In der Praxis haben sich verschiedene Workflows etabliert:

• Trunk-Based Development — kleine, kurze Branches, häufiges Mergen in main. Gut zu modernen CI/CD-Pipelines.
• GitHub Flow — Feature-Branches plus Pull Requests, schlanker Standard für viele Web-Teams.
• Git Flow — historische, formellere Variante mit develop, release, hotfix-Branches. Heute eher selten.

Welcher Workflow passt, hängt von Team-Größe, Release-Rhythmus und Risiko ab. Wichtiger als das Modell ist die Disziplin: aussagekräftige Commit-Nachrichten, kleine Commits, regelmäßiges Pushen, Reviews vor dem Merge.