Arbeiten mit einem Versionsverwaltungssystem
In dieser Lerneinheit erfährst du, wie du ein Repository als zentrale Komponente eines Versionsverwaltungssystems einrichtest und konfigurierst. Du lernst die grundlegenden Schritte kennen, um deine Projektdateien zu initialisieren und für die Versionsverwaltung vorzubereiten. Diese Kenntnisse sind essentiell für den Start jedes versionskontrollierten Projekts und bilden die Basis für die professionelle Verwaltung deines Quellcodes.
Einführung
Du hast ein neues Projekt gestartet. Die ersten Dateien sind geschrieben, der Code funktioniert. Dann passiert es: Eine Änderung bricht alles, und du weißt nicht mehr, was vorher funktioniert hat. Ohne Versionskontrolle gibt es keinen Weg zurück.
Wie können Entwickler sicherstellen, dass jede Änderung nachvollziehbar bleibt und Fehler schnell rückgängig gemacht werden können?
Die Antwort: Ein Versionsverwaltungssystem. Es dokumentiert jede Änderung, ermöglicht Rollbacks und schafft die Basis für professionelle Zusammenarbeit.
In dieser Lerneinheit lernst du, wie du mit einem Repository arbeitest, Änderungen nachverfolgst und die Versionsgeschichte nutzt, um deine Projekte unter Kontrolle zu halten.
Lernziele
Nach dieser Lerneinheit kannst du:
- Ein Repository einrichten und konfigurieren
- Mit
git statusden aktuellen Zustand deines Projekts prüfen - Änderungen zur Staging Area hinzufügen und committen
- Die Versionsgeschichte mit
git loganalysieren - Unterschiede zwischen Versionen mit
git diffvergleichen - Änderungen mit
git restore,git revertundgit resetrückgängig machen
Überleitung
Versionsverwaltung beginnt mit dem Repository - dem zentralen Speicher für deine Projektdateien und deren Historie. Nachdem du in der Lerneinheit Grundlegende Konzepte und Begriffe die theoretischen Grundlagen kennengelernt hast, wendest du diese jetzt praktisch an.
Danach lernst du, wie du mit git status jederzeit den Überblick behältst und Änderungen gezielt zur Versionskontrolle hinzufügst.
Repository einrichten - Kurzreferenz
Wie in der Lerneinheit Grundlegende Konzepte und Begriffe gelernt hast, ist das Repository der zentrale Speicher für dein Projekt. Um mit der praktischen Arbeit zu beginnen, richtest du zunächst ein Repository ein.
Zwei Wege zum Start:
- Neues Projekt:
git initerstellt ein Repository im aktuellen Verzeichnis - Bestehendes Projekt:
git clone <URL>kopiert ein Repository von einem Server
Wichtig: Nach der Einrichtung solltest du Git konfigurieren (Name und E-Mail für Commits). Die Details dazu findest du in der vorherigen Lerneinheit.
Jetzt schauen wir uns an, wie du mit diesem Repository arbeitest.
Git Status - Der wichtigste Befehl
Bevor du irgendwelche Änderungen vornimmst, ist es essentiell zu wissen, in welchem Zustand sich dein Projekt befindet. Der Befehl git status ist dein wichtigstes Werkzeug.
Was zeigt git status?
git status zeigt dir drei Kategorien von Dateien:
- Modified (geändert): Dateien, die du bearbeitet hast, aber noch nicht zur Staging Area hinzugefügt hast
- Staged (vorgemerkt): Dateien, die zum nächsten Commit hinzugefügt werden
- Untracked (nicht verfolgt): Neue Dateien, die Git noch nicht kennt
Beispielausgabe:
On branch main
Changes not staged for commit:
modified: index.html
Untracked files:
style.css
Faustregel: Führe
git statusvor jedem Workflow-Schritt aus. So behältst du jederzeit den Überblick und vermeidest Fehler.
Die Staging Area verstehen
Git nutzt ein Drei-Ebenen-Modell für Änderungen:
- Working Directory (Arbeitsverzeichnis): Hier bearbeitest du deine Dateien
- Staging Area (Zwischenablage): Hier sammelst du Änderungen für den nächsten Commit
- Repository: Hier werden Commits dauerhaft gespeichert
Warum eine Staging Area?
Die Staging Area gibt dir Kontrolle darüber, welche Änderungen in einen Commit aufgenommen werden. Du kannst gezielt einzelne Dateien oder sogar einzelne Zeilen auswählen.
Best Practice: Erstelle atomare Commits, die jeweils eine logische Änderung enthalten. So bleibt deine Projektgeschichte nachvollziehbar.
Der Commit-Workflow
Jetzt kombinieren wir alles zu einem vollständigen Workflow. So arbeitest du mit Git im Alltag:
# 1. Status prüfen
git status
# 2. Geänderte Datei zur Staging Area hinzufügen
git add beispiel.txt
# 3. Erneut Status prüfen (Datei jetzt "staged")
git status
# 4. Commit mit aussagekräftiger Nachricht erstellen
git commit -m "Feature X implementiert"Best Practices für Commit-Nachrichten
- Kurz und präzise: Erste Zeile unter 50 Zeichen
- Imperativ: “Implementiere Feature” statt “Feature implementiert”
- Aussagekräftig: “Bugfix” ist zu vage, “Nullpointer-Exception in Login behoben” ist besser
Die Versionsgeschichte anzeigen
Mit git log siehst du die komplette Historie deines Projekts. Das ist mächtig für Code-Analyse und Fehlersuche.
Wichtige git log Optionen
git log- Vollständige Historie mit allen Detailsgit log --oneline- Kompakte Ansicht (eine Zeile pro Commit)git log --graph- Zeigt Branch-Struktur als ASCII-Graphgit log --author="Name"- Filtert nach einem bestimmten Autorgit log --since="2024-01-01"- Filtert nach Datum
Beispiel-Output von git log --oneline:
a1b2c3d Feature X implementiert
4e5f6g7 Bugfix in Login
8i9j0k1 Initial commit
Jeder Commit hat eine eindeutige ID (Hash), mit der du ihn referenzieren kannst.
Änderungen vergleichen mit git diff
Oft möchtest du wissen, was genau sich geändert hat, bevor du einen Commit erstellst. Der Befehl git diff zeigt dir diese Unterschiede.
Die drei wichtigsten diff-Varianten:
1. Working Directory vs Staging Area:
git diffZeigt Änderungen, die noch nicht zur Staging Area hinzugefügt wurden.
2. Staging Area vs letzter Commit:
git diff --stagedZeigt Änderungen, die zum nächsten Commit hinzugefügt werden.
3. Zwei Commits vergleichen:
git diff commit1 commit2Vergleicht zwei beliebige Commits miteinander.
git diff in der Praxis
Praktische Anwendungsfälle
Spezifische Datei prüfen:
git diff beispiel.txtÄnderungen zwischen Branches:
git diff main feature-branchWort-basierte Unterschiede (bei kleinen Änderungen):
git diff --word-diffTipp: GUI-Tools nutzen
Die Terminal-Ausgabe von git diff kann bei vielen Änderungen unübersichtlich werden. Tools wie GitKraken, SourceTree oder die Diff-Ansicht in VS Code zeigen Unterschiede visuell deutlicher.
Pro-Tipp: Nutze
git diffvorgit add, um zu prüfen, was du wirklich zur Staging Area hinzufügen möchtest.
Änderungen rückgängig machen
Manchmal möchtest du Änderungen verwerfen oder rückgängig machen. Git bietet verschiedene Befehle je nach Situation.
Die wichtigsten Befehle:
Datei im Working Directory wiederherstellen:
git restore datei.txtVerwirft lokale Änderungen. Die Datei wird auf den Stand des letzten Commits zurückgesetzt.
Datei aus Staging entfernen:
git restore --staged datei.txtBehält Änderungen, entfernt sie aber aus der Staging Area.
Wichtig:
git restoreist der moderne Ersatz für das veraltetegit checkout --.
Remote Repositories - Die Basics
Bisher haben wir nur lokal gearbeitet. Um deine Änderungen mit anderen zu teilen oder auf einem Server zu sichern, brauchst du ein Remote Repository.
Remote hinzufügen
git remote add origin https://github.com/user/project.gitVerbindet dein lokales Repository mit einem entfernten Server.
Änderungen hochladen (Push)
git push -u origin mainSendet deine Commits zum Remote Repository. -u setzt das Remote als Standard.
Änderungen herunterladen (Pull)
git pullHolt Änderungen vom Remote und merged sie in deinen aktuellen Branch.
Abgrenzung: Hier lernst du die Basics. In der Lerneinheit Kollaboration und verteilte Workflows erfährst du, wie Teams diese Befehle in komplexen Projekten nutzen.
git revert und git reset
Für größere Rückgängig-Operationen gibt es zwei mächtige Befehle:
git revert - Sichere Methode
git revert HEADErstellt einen neuen Commit, der die Änderungen eines vorherigen Commits umkehrt. Die Historie bleibt erhalten.
Wann nutzen? Wenn der Commit bereits gepusht wurde (öffentlich).
git reset - Vorsichtig einsetzen
git reset --soft HEAD~1 # Commit löschen, Änderungen behalten
git reset --mixed HEAD~1 # Commit + Staging löschen, Dateien behalten
git reset --hard HEAD~1 # Alles verwerfen (UNWIDERRUFLICH)Wann nutzen? Nur für lokale Commits, die noch nicht gepusht wurden.
Warnung:
git reset --hardlöscht Änderungen unwiederbringlich. Nutze es nur, wenn du sicher bist.
Zusammenfassung und Ausblick
Zusammenfassung
Du hast die grundlegenden Workflows der Versionsverwaltung kennengelernt:
- Repository einrichten: Mit
git initodergit clonestartest du die Versionskontrolle für dein Projekt - Status prüfen:
git statuszeigt dir Modified/Staged/Untracked Dateien - dein wichtigstes Werkzeug - Änderungen dokumentieren: Mit
git addfügst du Änderungen zur Staging Area hinzu,git commiterstellt atomare Commits - Historie analysieren:
git logzeigt die vollständige Versionsgeschichte mit allen Commits - Unterschiede vergleichen:
git diffvergleicht Working Directory, Staging Area oder beliebige Commits - Änderungen rückgängig machen:
git restoreverwirft lokale Änderungen,git reverterstellt umkehrende Commits,git resetändert die Historie - Remote Repositories:
git pushsendet Commits zum Server,git pullholt Änderungen ab
Die Staging Area ist dabei dein zentrales Werkzeug für kontrollierte Commits. Sie gibt dir die Kontrolle darüber, welche Änderungen in einen Commit aufgenommen werden. Atomare Commits mit aussagekräftigen Nachrichten (Imperativ, unter 50 Zeichen) halten deine Projektgeschichte nachvollziehbar.
Wichtigste Faustregel: Führe git status vor jedem Workflow-Schritt aus, um den Überblick zu behalten.
Ausblick
In der nächsten Lerneinheit Branching und Merging lernst du, wie du mit Branches parallel an verschiedenen Features arbeiten kannst, ohne den Hauptcode zu beeinflussen. Branches sind essentiell für professionelle Entwicklungsworkflows und ermöglichen es Teams, gleichzeitig an verschiedenen Features zu arbeiten.