Start › Git-Begriffe

Git-Begriffe

Kurzerklärung der Fachwörter, die beim Arbeiten mit diesem Repository ständig auftauchen – nicht als Prüfungsstoff, sondern als Nachschlagehilfe für unseren eigenen Arbeitsablauf.

Commit

Ein Commit ist ein gespeicherter Zwischenstand des Projekts – ein Schnappschuss aller Dateien zu einem bestimmten Zeitpunkt, zusammen mit einer kurzen Beschreibung, was sich geändert hat. Jeder Commit verweist auf seinen Vorgänger, dadurch entsteht die Historie: eine Kette von Zuständen, zu denen man jederzeit zurückkehren kann. In diesem Projekt gilt „ein Commit pro Änderung" (siehe CLAUDE.md) – lieber viele kleine, klar benannte Commits als ein großer mit vermischten Themen.

Branch

Ein Branch (Zweig) ist eine eigene, parallele Entwicklungslinie innerhalb desselben Repositorys. Er zweigt von einem bestehenden Commit ab und sammelt von dort an eigene Commits, ohne den Hauptbranch zu verändern. So lässt sich an einer Änderung arbeiten, ohne den aktuell laufenden Stand zu gefährden. Der Hauptbranch heißt hier main; Claude entwickelt auf einem eigenen Arbeitsbranch (aktuell claude/new-session-7dnnjb) und lässt diesen erst per Pull Request in main übernehmen.

Push & Pull

Push schickt eigene, lokal erstellte Commits zum entfernten Repository (hier: GitHub) hoch – erst danach sind sie dort sichtbar. Pull ist die Gegenrichtung: Commits, die auf GitHub liegen, aber lokal noch fehlen, werden heruntergeladen und eingefügt. Nach einem Merge zieht sich Peter den aktuellen Stand von main per git pull auf seinen eigenen Rechner (siehe Warnkasten unten).

Pull Request (PR)

Ein Pull Request ist der Antrag, die Commits eines Branches in einen anderen Branch (meist main) zu übernehmen. Er zeigt alle Änderungen gesammelt an einer Stelle, bevor sie endgültig übernommen werden – so bleibt main ein Stand, den Peter jederzeit einsehen und freigeben kann, statt dass Änderungen unbemerkt direkt hineinlaufen.

Merge

Merge (Zusammenführen) übernimmt die Commits eines Branches in einen anderen – üblicherweise das Ergebnis eines angenommenen Pull Requests. Beide Entwicklungslinien laufen danach wieder in einem gemeinsamen Stand zusammen. Ändern beide Branches dieselbe Stelle unterschiedlich, entsteht ein Konflikt, den man von Hand auflösen muss; ändern sie unterschiedliche Stellen, geschieht das automatisch.

Der gesamte Ablauf in diesem Projekt

Die folgende Grafik zeigt, wie die sechs Begriffe hier tatsächlich zusammenspielen – vom Bearbeiten einer Datei bis zur sichtbaren Änderung auf der NAS. Wichtig dabei: „lokal" ist in den Schritten 1–5 nicht Peters eigener Rechner, sondern der Cloud-Container dieser Claude-Code-Sitzung. Peters Rechner kommt erst in Schritt 6 ins Spiel, wenn er sich main nach dem Merge selbst herunterlädt – und die NAS hat gar kein eigenes Git, sie bekommt die Dateien in Schritt 7 manuell kopiert.

Ablaufdiagramm mit sieben nummerierten Schritten: In der Claude-Sitzung wird 1. das Arbeitsverzeichnis bearbeitet und 2. committet, der Commit landet auf einem Branch, der 3. zu GitHub gepusht wird, dort 4. ein Pull Request geöffnet und 5. in main gemergt wird. Danach zieht sich 6. Peters eigener Rechner main per Pull, und Peter kopiert die Dateien 7. manuell auf die NAS, die kein eigenes Git-Repository hat. — Schritte 1–5 laufen in der Claude-Sitzung, Schritte 6–7 macht Peter selbst.
Grafik in voller Größe öffnen ↗

Bekannter Fallstrick (aus CLAUDE.md): Die NAS hat kein eigenes Git-Repository. Solange Peter einen gemergten Stand nicht per git pull auf seinen Rechner geholt und manuell auf die NAS kopiert hat, ist dort weder ein offener Pull Request noch ein frisch gemergter Stand sichtbar – auch wenn der Branch längst gepusht oder main längst aktuell ist.