Repository, Commit und Branch

Drei Grundbegriffe für die tägliche Git-Arbeit

Fast jede Git-Aktion dreht sich um drei Begriffe:

• Repository: der verwaltete Projektbestand inklusive Geschichte
• Commit: ein dauerhaft gespeicherter, beschrifteter Projektzustand
• Branch: eine bewegliche Entwicklungslinie innerhalb eines Repositorys

Wer diese Begriffe sauber voneinander trennt, versteht viele Git-Befehle nicht mehr als einzelne Kommandos, sondern als nachvollziehbare Zustandsänderungen.

---

Das Repository: Projekt und Geschichte an einem Ort

Ein Repository ist der Bereich, den Git verwaltet. Es enthält nicht nur die aktuellen Dateien eines Projekts, sondern auch deren vollständige nachvollziehbare Entwicklung.

In einem Repository speichert Git unter anderem:

• Dateien des Projekts,
• frühere Versionen dieser Dateien,
• Commits mit Autor, Zeitpunkt und Nachricht,
• Branches und Tags,
• Einstellungen für dieses konkrete Projekt,
• Informationen über verbundene Server, etwa GitHub.

Ein lokales Git-Repository entsteht beispielsweise mit:

git init

Danach legt Git im Projektordner einen versteckten Unterordner namens .git an. Dieser Ordner ist das technische Herz des Repositorys.

mein-projekt/
├── .git/
├── src/
├── tests/
├── README.md
└── composer.json

Wichtig: Der Ordner .git enthält die Git-Datenbank mit der Historie. Wird er gelöscht, bleiben zwar die Projektdateien erhalten, aber Git „vergisst“ Commits, Branches, Einstellungen und die gesamte Versionsgeschichte.

Lokale und entfernte Repositories

Ein Repository kann ausschließlich auf dem eigenen Computer liegen. Das ist ein lokales Repository.

Später kann es mit einem Server verbunden werden, zum Beispiel mit GitHub. Das dortige Repository wird als entferntes Repository oder Remote Repository bezeichnet.

Lokaler Computer                   GitHub
────────────────                   ──────
Arbeitskopie                       Entferntes Repository
Git-Historie        ←── Sync ──→   Gemeinsame Git-Historie
Eigene Branches                    Veröffentlichte Branches

Git funktioniert aber bereits vollständig ohne GitHub und ohne Internetverbindung. GitHub erweitert Git um Zusammenarbeit, Hosting, Reviews, Issues und Automatisierung. Es ersetzt Git nicht.

---

Der Commit: ein nachvollziehbarer Projektzustand

Ein Commit ist ein gespeicherter Zustand des Projekts zu einem bestimmten Zeitpunkt. Er hält fest, welche Dateien und Inhalte zu diesem Zeitpunkt zum Projekt gehören.

Ein Commit ist daher kein bloßer Speichern-Knopf. Er ist eine bewusste Aussage über die Entwicklung des Projekts.

Beispiele für sinnvolle Commit-Aussagen:

• „Registrierung mit E-Mail-Validierung hinzugefügt“
• „Fehlerhafte Berechnung der Mehrwertsteuer korrigiert“
• „API-Dokumentation für Benutzerendpunkt ergänzt“
• „PHPUnit-Tests für Passwort-Reset hinzugefügt“

Weniger hilfreich sind Nachrichten wie:

• „Änderungen“
• „Update“
• „Fix“
• „WIP“
• „asdf“

Eine gute Commit-Nachricht beantwortet knapp die Frage:

Was wurde in diesem Schritt fachlich oder technisch verändert?

Was Git in einem Commit speichert

Ein Commit enthält mehr als den Inhalt der Dateien. Vereinfacht gehören dazu:

• ein eindeutiger Bezeichner, meist als Hash dargestellt,
• der gespeicherte Projektzustand,
• eine Commit-Nachricht,
• Autor und Zeitpunkt,
• Committer und Zeitpunkt der tatsächlichen Speicherung,
• ein oder mehrere Vorgänger-Commits.

Ein Commit könnte in einer Kurzansicht so aussehen:

Commit: 8f3c1a2
Autor:  Maria Beispiel
Datum:  2025-03-08

Validierung für Registrierungsformular hinzugefügt

Der lange technische Bezeichner ist ein Hash, zum Beispiel:

8f3c1a2d7e4b0c4af95e3b8d1e6f9a2c7b4d5e6f

Im Alltag genügt meist ein eindeutiger Anfang dieses Hashes, etwa 8f3c1a2.

Commits bilden eine Geschichte

Jeder neue Commit verweist normalerweise auf seinen Vorgänger. Dadurch entsteht eine chronologische, technisch präzise Projektgeschichte.

A ─── B ─── C

Dabei könnte gelten:

A  Projektgrundstruktur erstellt
B  Benutzeranmeldung implementiert
C  Anmeldung mit Tests abgesichert

Der aktuelle Projektstand ist dann Commit C. Git kann aber jederzeit die Zustände von A oder B untersuchen, vergleichen oder bei Bedarf wiederherstellen.

Commits sind lokale Sicherungspunkte

Ein Commit wird zunächst nur im lokalen Repository gespeichert. Er ist also noch nicht automatisch auf GitHub sichtbar und auch nicht für Kolleginnen und Kollegen verfügbar.

Dateien ändern
      ↓
Commit lokal erstellen
      ↓
Commit zu GitHub übertragen

Das Übertragen zu einem Remote erfolgt später mit git push.

Diese Trennung ist bewusst: Du kannst lokal sauber arbeiten, Commits vorbereiten, korrigieren und testen, bevor du Änderungen mit anderen teilst.

---

Ein Commit ist kein Dateiarchiv

Ein verbreitetes Denkmodell lautet: Git speichere bei jedem Commit einfach eine vollständige ZIP-Datei des Projekts. Das ist als erste Vorstellung nützlich, aber technisch nicht ganz richtig.

Git behandelt jeden Commit als vollständigen Snapshot des Projektzustands. Intern speichert Git identische Inhalte jedoch effizient nur einmal und verknüpft sie wieder.

Das entscheidende mentale Modell lautet:

Ein Commit beschreibt, wie das gesamte Projekt zu einem bestimmten Zeitpunkt aussieht.

Git speichert also nicht primär die Anweisung „Zeile 12 wurde geändert“, sondern einen neuen Projektzustand, der auf bereits bekannten Inhalten aufbaut.

Das erklärt später unter anderem, warum Git:

• Änderungen sehr zuverlässig vergleichen kann,
• Branches schnell erstellt,
• alte Zustände einfach wiederherstellen kann,
• mehrere Entwicklungswege effizient verwaltet.

---

Der Branch: eine Entwicklungslinie

Ein Branch ist eine benannte Entwicklungslinie. Er zeigt auf einen bestimmten Commit und bewegt sich weiter, wenn auf diesem Branch neue Commits entstehen.

Ein frisch initialisiertes Repository besitzt meist einen Standard-Branch namens main.

main
  ↓
A ─── B ─── C

Der Name main zeigt hier auf den neuesten Commit C.

Wenn ein weiterer Commit entsteht, verschiebt Git den Branch-Zeiger automatisch:

A ─── B ─── C ─── D
                  ↑
                main

Der Branch enthält dabei nicht selbst alle Dateien und auch keine Kopie der Commits. Er ist vielmehr ein beweglicher Verweis auf den neuesten Commit einer Entwicklungslinie.

Merksatz: Ein Branch ist kein Projektordner und keine vollständige Projektkopie. Er ist ein Name, der auf einen Commit zeigt.

---

Warum Branches wichtig sind

Branches ermöglichen es, mehrere Arbeiten parallel durchzuführen, ohne den stabilen Hauptstand direkt zu gefährden.

Angenommen, die produktive Anwendung befindet sich auf main:

A ─── B ─── C
            ↑
          main

Nun soll eine neue Passwort-Reset-Funktion entwickelt werden. Dafür wird ein Feature-Branch angelegt:

A ─── B ─── C
            ↑
          main
            ↑
   feature/password-reset

Zu Beginn zeigen beide Branches auf denselben Commit C. Danach entstehen die neuen Commits nur auf dem Feature-Branch:

A ─── B ─── C ─── D ─── E
            ↑           ↑
          main   feature/password-reset

Die neue Funktion kann entwickelt, getestet und geprüft werden, ohne den Stand auf main zu verändern.

Erst wenn die Arbeit fertig ist, wird der Feature-Branch wieder mit main zusammengeführt. Dieser Vorgang heißt Merge.

A ─── B ─── C ───────────── F
            │               ↑
            D ─── E       main
                ↑
      feature/password-reset

Die genaue Form der Historie hängt von der gewählten Merge-Strategie ab. Das Prinzip bleibt jedoch gleich: Branches erlauben isolierte Entwicklung und kontrollierte Integration.

---

HEAD: Wo arbeite ich gerade?

Git muss wissen, auf welchem Branch du gerade arbeitest. Dafür verwendet Git die Referenz HEAD.

HEAD zeigt normalerweise auf den aktuell ausgecheckten Branch:

A ─── B ─── C
            ↑
          main
            ↑
           HEAD

Wenn du den Branch wechselst, folgt HEAD diesem Branch:

A ─── B ─── C ─── D
            ↑           ↑
          main   feature/login
                        ↑
                       HEAD

Neue Commits werden dann auf feature/login erstellt. Der Branch main bleibt unverändert auf Commit C.

In der Kommandozeile zeigt dieser Befehl die vorhandenen lokalen Branches an:

git branch

Der Stern markiert den aktuell aktiven Branch:

* main
  feature/login
  feature/password-reset

Mit modernen Git-Versionen wechselst du einen Branch meist so:

git switch feature/login

Die Arbeit mit Branches wird in einem späteren Kapitel ausführlich behandelt. Für den Einstieg genügt dieses Modell:

• HEAD markiert deine aktuelle Arbeitsposition.
• Der aktive Branch bestimmt, wohin neue Commits geschrieben werden.
• Ein neuer Commit bewegt den aktiven Branch weiter.

---

Repository, Commit und Branch im Zusammenhang

Die drei Begriffe gehören zusammen, erfüllen aber unterschiedliche Aufgaben:

Begriff	Aufgabe	Beispiel
Repository	Verwaltet Projektdateien, Historie und Git-Metadaten	Das gesamte PHP-Projekt mit allen Commits
Commit	Speichert einen nachvollziehbaren Projektzustand	„Login-Validierung ergänzt“
Branch	Kennzeichnet eine Entwicklungslinie und zeigt auf ihren neuesten Commit	main, feature/login

Eine vereinfachte Darstellung:

Repository
│
├── Branch main
│   └── A ─── B ─── C
│
└── Branch feature/login
    └── A ─── B ─── C ─── D ─── E

Die Commits A, B und C werden von beiden Branches geteilt. Erst ab D entwickelt sich der Feature-Branch unabhängig weiter.

---

Praxisbeispiel: Entwicklung einer kleinen Funktion

Stell dir ein PHP-Projekt für eine Aufgabenverwaltung vor. Das Repository enthält zunächst drei Commits:

A  Projekt mit Composer eingerichtet
B  Aufgabenliste implementiert
C  PHPUnit-Grundkonfiguration ergänzt

Der Standard-Branch main zeigt auf den letzten Commit:

A ─── B ─── C
            ↑
          main

Nun soll eine Funktion zum Markieren erledigter Aufgaben entstehen.

1. Feature-Branch erstellen

git switch -c feature/complete-task

Git erstellt den Branch und wechselt sofort dorthin:

A ─── B ─── C
            ↑
          main
            ↑
feature/complete-task
            ↑
           HEAD

2. Funktion implementieren und committen

Nach der Implementierung und passenden Tests wird ein Commit erstellt:

git add src/Task.php tests/TaskTest.php
git commit -m "Erledigte Aufgaben markieren"

Die Historie sieht danach so aus:

A ─── B ─── C ─── D
            ↑       ↑
          main  feature/complete-task

3. Weiterarbeiten, ohne main zu verändern

Ein weiterer Commit ergänzt die Darstellung im Benutzerinterface:

git add templates/tasks.php
git commit -m "Erledigte Aufgaben visuell hervorheben"

A ─── B ─── C ─── D ─── E
            ↑               ↑
          main  feature/complete-task

Währenddessen bleibt main auf dem getesteten Stand C. Andere Teammitglieder können dort arbeiten, ohne unvollständige Änderungen an der neuen Funktion zu übernehmen.

---

Häufige Missverständnisse

„Ein Branch ist eine Kopie des Projekts“

Nicht im üblichen Sinn. Git kopiert nicht bei jedem neuen Branch das gesamte Projektverzeichnis. Ein Branch ist hauptsächlich ein zusätzlicher Zeiger auf einen Commit. Deshalb sind Branches in Git schnell und günstig.

„Ein Commit wird automatisch auf GitHub gespeichert“

Nein. Ein Commit entsteht zunächst lokal. Erst ein Push überträgt ihn an ein entferntes Repository.

git push

„Ich brauche für jede Änderung einen neuen Branch“

Nicht zwingend. Für kleine persönliche Experimente kann Arbeit direkt auf main sinnvoll sein. In Teamprojekten und bei größeren Änderungen sind separate Feature-Branches jedoch meist der sichere Standard.

„Ein Branch muss nach dem Zusammenführen bleiben“

Nein. Ist eine Funktion integriert, wird ihr Feature-Branch häufig gelöscht. Die enthaltenen Commits bleiben erhalten, sofern sie in die Zielhistorie übernommen wurden.

„Ein Commit muss möglichst viele Änderungen enthalten“

Das Gegenteil ist meist besser: Ein Commit sollte eine abgeschlossene, logisch zusammengehörige Änderung darstellen. Kleine, verständliche Commits erleichtern Reviews, Fehlersuche und spätere Korrekturen.

---

Praktische Leitlinien

Für den Einstieg helfen diese Regeln:

1. Ein Repository pro klar abgegrenztem Projekt
   Ein Repository sollte eine zusammenhängende Anwendung, Bibliothek oder Konfiguration verwalten.

2. Commits klein und verständlich halten
   Ein Commit sollte idealerweise eine Aufgabe, Fehlerbehebung oder fachliche Änderung beschreiben.

3. Aussagekräftige Commit-Nachrichten schreiben
   Die Nachricht soll auch Wochen später ohne erneutes Lesen des Codes verständlich sein.

4. Für neue Funktionen eigene Branches verwenden
   Namen wie feature/login, fix/tax-calculation oder docs/setup-guide machen den Zweck sichtbar.

5. Den stabilen Hauptbranch schützen
   main sollte in Teamprojekten möglichst nur getestete und überprüfte Änderungen enthalten.

6. Vor einer Änderung den aktuellen Branch prüfen
   Viele Fehler entstehen, weil versehentlich auf dem falschen Branch gearbeitet wird.

git status

Git zeigt dabei unter anderem an, auf welchem Branch du dich befindest.

---

Zusammenfassung

Ein Git-Repository ist das verwaltete Projekt mitsamt seiner vollständigen Historie. Ein Commit speichert einen bewusst gewählten, beschrifteten Projektzustand. Ein Branch benennt eine Entwicklungslinie und zeigt auf ihren aktuellsten Commit.

Das zentrale Bild lautet:

Repository
├── enthält die gesamte Historie
├── besteht aus vielen Commits
└── organisiert parallele Entwicklung über Branches

Oder noch kürzer:

Das Repository ist der Speicherort, der Commit ist der Zustand, der Branch ist die Entwicklungslinie.

Mit diesem Modell lassen sich die nächsten Git-Schritte — insbesondere Staging, Commit-Erstellung, Branch-Wechsel und Zusammenführen — systematisch verstehen.