Mit Google fortfahren
Versionsverwaltung: Git, Branches und Teamarbeit
Eine Versionsverwaltung hält Änderungen an Dateien nachvollziehbar fest. Dadurch kannst du frühere Stände vergleichen und wiederherstellen, parallele Arbeiten trennen und Beiträge kontrolliert zusammenführen.
Auf dieser Seite lernst du den grundlegenden Git-Arbeitsablauf kennen und entscheidest, wie ein Team Änderungen ohne Verlust in einen gemeinsamen Projektstand integriert.
Hake ab, was du schon kannst — und komm am Ende hierher zurück!
Warum Dateinamen nicht reichen
Stell dir vor, drei Personen bearbeiten einen Vertragsentwurf. Nach kurzer Zeit gibt es Dateien wie Vertrag_final, Vertrag_final_neu und Vertrag_final_neu2. Die Namen verraten nicht zuverlässig, welche Fassung aktuell ist, wer etwas geändert hat oder welche Änderungen zusammengehören.
Versionsverwaltung
Eine Versionsverwaltung, kurz VCS, erfasst Änderungen an Dateien oder Dokumenten. Sie bewahrt frühere Stände in einer Historie auf und ordnet Änderungen unter anderem einer Person und einem Zeitpunkt zu.
Eine Versionsverwaltung hilft dir dabei,
- frühere Projektstände wiederherzustellen,
- Änderungen zwischen Ständen zu vergleichen,
- die Entstehung eines Fehlers nachzuvollziehen,
- parallele Beiträge zu koordinieren und
- ausgewählte Änderungen zusammenzuführen.
Dabei entstehen nicht einfach viele unabhängig benannte Dateien. Die Versionen gehören zu einer gemeinsamen, geordneten Projekthistorie.
Lea überarbeitet eine Webseite und entfernt versehentlich einen funktionierenden Abschnitt. In einer Versionsverwaltung kann sie den aktuellen Stand mit einer früheren Version vergleichen. Anschließend stellt sie gezielt den benötigten Inhalt wieder her, statt eine vermutlich passende Sicherungskopie zu suchen.
Wie aus einer Änderung ein Commit wird
Bei Git durchläuft eine Änderung mehrere Bereiche. Erst diese Trennung macht es möglich, bewusst auszuwählen, was in die Historie aufgenommen wird.
Repository
Ein Repository, kurz Repo, enthält die versionierten Projektdaten und ihre Änderungshistorie.
Die drei wichtigsten Bereiche eines lokalen Git-Projekts sind:
- Arbeitsverzeichnis: Hier öffnest und bearbeitest du die normalen Projektdateien.
- Staging Area: Hier stellst du die Änderungen zusammen, die zum nächsten Commit gehören sollen.
- Lokales Repository: Hier speichert Git die erstellten Commits als nachvollziehbare Historie.
Commit
Ein Commit ist ein festgehaltener Projektstand mit einer kurzen Beschreibung. Er bündelt die zuvor ausgewählten Änderungen zu einer nachvollziehbaren Einheit.
Speichern und Committen sind deshalb nicht dasselbe. Wenn du eine Datei im Editor speicherst, liegt die Änderung zunächst nur im Arbeitsverzeichnis. Erst nach der Auswahl für die Staging Area und dem Commit gehört sie zur Git-Historie.
Noah ergänzt eine Suchfunktion und korrigiert gleichzeitig einen Tippfehler in einer unabhängigen Hilfeseite.
- Er prüft zunächst die veränderten Dateien, zum Beispiel mit
git status. - Er wählt nur die Dateien der Suchfunktion für die Staging Area aus.
- Er erstellt einen Commit mit einer Nachricht wie
Suchfeld mit Ergebnisliste ergänzen. - Den unabhängigen Tippfehler nimmt er später in einen eigenen Commit auf.
So lässt sich aus der Historie erkennen, welche Änderungen sachlich zusammengehören.
Ein guter Commit ist klein genug, um verständlich zu bleiben, aber vollständig genug, um eine sachlich zusammengehörige Änderung abzubilden.
Wie lokale und entfernte Repositorys zusammenarbeiten
Ein lokales Repository liegt auf deinem Rechner. Ein Remote-Repository ist ein anderes verbundenes Repository, das ein Team häufig als gemeinsamen Austauschpunkt verwendet.
Wichtige Vorgänge sind:
- Clone: Ein vorhandenes Remote-Repository wird einschließlich seiner Repository-Historie auf den eigenen Rechner kopiert.
- Commit: Eine Änderung wird zunächst im lokalen Repository festgehalten. Dafür ist keine Serververbindung nötig.
- Push: Lokale Commits werden an ein Remote-Repository übertragen.
- Pull: Spätere Änderungen aus einem Remote werden in das bereits verbundene lokale Repository übernommen.
Ein Remote ist nicht der Ort, an dem jede Änderung sofort entsteht. Der normale Git-Ablauf beginnt lokal. Erst ein Push veröffentlicht die betreffenden Commits im verbundenen Remote-Repository.
Ein vollständiger Klon enthält die versionierte Repository-Historie. Nicht festgehaltene Dateien aus fremden Arbeitsverzeichnissen gehören jedoch nicht dazu. Deshalb ersetzt ein Klon nicht jede denkbare Datensicherung.
Mina klont zu Beginn das gemeinsame Projekt. Danach kann sie lokal Dateien bearbeiten und Commits erstellen. Vor der Integration ihres Beitrags übernimmt sie die aktuellen Teamänderungen. Anschließend überträgt sie ihre eigenen Commits zum gemeinsamen Remote.
Wie Branches parallele Arbeit ermöglichen
Ein Team möchte neue Funktionen entwickeln, ohne den gemeinsamen Hauptstand bei jedem Zwischenschritt zu verändern. Dafür kann es Branches verwenden.
Branch
Ein Branch ist ein Entwicklungszweig innerhalb der Projekthistorie. Auf ihm können eigene Commits entstehen, während andere Zweige unabhängig weiterlaufen.
Der Hauptzweig heißt heute häufig main. Ein Team kann für eine neue Funktion einen Feature-Branch anlegen, die Funktion dort schrittweise entwickeln und testen und sie anschließend in den Hauptzweig übernehmen.
Merge
Ein Merge führt die Entwicklungsverläufe zweier Branches zusammen.
Git kann viele Änderungen automatisch zusammenführen. Haben zwei Branches jedoch dieselbe Stelle unterschiedlich verändert, kann ein Mergekonflikt entstehen. Das ist kein Datenverlust, sondern eine Entscheidung, die das Team bewusst treffen muss.
Aylin entwickelt im Branch suche eine Suchleiste. Ben ändert gleichzeitig im Hauptzweig die Navigation. Beide bearbeiten dieselbe Menüzeile unterschiedlich.
Beim Zusammenführen meldet Git einen Konflikt. Aylin vergleicht beide Fassungen, erstellt eine gemeinsame Zeile mit Navigation und Suchleiste, testet das Ergebnis und hält die Lösung in einem neuen Commit fest. Erst danach wird der Beitrag integriert.
Ein Mergekonflikt bedeutet: Git kann die beabsichtigte gemeinsame Fassung nicht eindeutig bestimmen. Menschen müssen den Inhalt prüfen, entscheiden und das Ergebnis testen.
Welche Architektur passt zur Zusammenarbeit
Versionsverwaltung kann lokal, zentral oder verteilt organisiert sein. Die Modelle unterscheiden sich vor allem darin, wo die vollständige Historie liegt und wie Beteiligte zusammenarbeiten.
| Modell | Ablage der Historie | Stärke | Grenze |
|---|---|---|---|
| lokal | auf einem Rechner | einfache persönliche Versionierung | Verlust oder Ausfall dieses Rechners gefährdet die Historie |
| zentral | in einem gemeinsamen Server-Repository | gemeinsamer Überblick und zentrale Rechteverwaltung | Server und Netzwerk werden zur zentralen Abhängigkeit |
| verteilt | in den vollständigen Repository-Klonen der Beteiligten | lokale Commits und flexible Synchronisierung | Beiträge müssen weiterhin abgestimmt und integriert werden |
Git ist ein verteiltes Versionskontrollsystem. Trotzdem verwendet ein Team in der Praxis häufig ein offizielles Remote-Repository als gemeinsamen Bezugspunkt. Technisch vorhandene Verteilung und organisatorisch vereinbarte Zuständigkeit widersprechen sich nicht.
Bei parallelen Textänderungen wird häufig nach dem Prinzip Copy–Modify–Merge gearbeitet: Beteiligte bearbeiten eigene Arbeitskopien und führen die Ergebnisse danach zusammen. Bei schwer automatisch zusammenführbaren Binärdateien kann dagegen ein Sperrverfahren sinnvoll sein, bei dem nur eine Person die Datei zur gleichen Zeit bearbeitet.
Wie ein Team Beiträge kontrolliert integriert
Eine nachvollziehbare Historie entsteht nicht allein durch die Software. Das Team braucht einen vereinbarten Arbeitsablauf.
Ein möglicher Ablauf für eine neue Funktion ist:
- Einen eigenen Feature-Branch anlegen.
- Die Funktion in kleinen, sachlich begrenzten Commits entwickeln.
- Aussagekräftige Commit-Nachrichten schreiben.
- Den aktuellen Hauptstand berücksichtigen und Konflikte im Feature-Branch lösen.
- Die Funktion testen.
- Den Beitrag über eine Merge Request zur Prüfung bereitstellen.
- Rückmeldungen einarbeiten und den geprüften Beitrag integrieren.
Eine Merge Request macht den gewünschten Zusammenschluss sichtbar. Andere Teammitglieder können die Änderung prüfen und freigeben. Review und Tests ergänzen die Versionsverwaltung: Die Historie zeigt, was geändert wurde; die Prüfung bewertet, ob die Änderung fachlich richtig und funktionsfähig ist.
Ein Team ergänzt eine Passwortanzeige. Der Commit Dateien geändert ist kaum hilfreich. Die Nachricht Schalter zum Einblenden des Passworts ergänzen beschreibt die Änderung deutlich genauer.
Vor der Integration prüft das Team:
- Erfüllt die Funktion die vereinbarte Anforderung?
- Funktioniert der bisherige Programmteil weiterhin?
- Ist die Änderung verständlich und auf das Feature begrenzt?
- Wurden Konflikte inhaltlich richtig gelöst?
Karteikasten
Überlege zuerst selbst und drehe die Karte anschließend zum Prüfen um.
Alles auf einen Blick
- Versionsverwaltung
- Historie
- Änderungen nachvollziehen
- frühere Stände wiederherstellen
- lokaler Git-Ablauf
- Arbeitsverzeichnis
- Staging Area
- Commit
- Zusammenarbeit
- Remote austauschen
- Branches trennen
- Merges integrieren
- Qualität
- kleine verständliche Commits
- Review und Tests
- Historie
Abschluss-Check
Du beherrschst den Kern der Versionsverwaltung, wenn du nicht nur Begriffe nennen kannst, sondern einen Beitrag vom Arbeitsverzeichnis über Commit und Branch bis zur geprüften Integration nachvollziehbar planst.