Grundlegende Konzepte und Begriffe

In dieser Lerneinheit verstehst du die zentralen Konzepte Repository und Working Copy, die die Grundlage jeder Versionsverwaltung bilden. Du lernst, wie ein Repository deine Projektdateien und deren Versionshistorie speichert und wie die Working Copy dir das lokale Arbeiten an den Dateien ermöglicht. Diese Grundlagen sind essentiell für deine tägliche Entwicklungsarbeit und bilden das Fundament für alle weiteren Versionskontroll-Operationen.

Einführung

Hast du dich schon mal gefragt, wie Entwickler an komplexen Projekten arbeiten, ohne dass Änderungen verloren gehen oder sich gegenseitig überschreiben?

Chaos ohne Versionsverwaltung vs. Kontrolle mit Versionsverwaltung — Bildrechte: Ausbildung-in-der-IT.de (KI-unterstützt)

Was passiert, wenn du einen Fehler machst und zu einer früheren, funktionierenden Version zurückkehren möchtest?

Die Versionsverwaltung ist das Werkzeug, das genau diese Probleme löst. Sie speichert nicht nur deinen aktuellen Code, sondern die gesamte Entwicklungsgeschichte. Du kannst Änderungen nachverfolgen, zu früheren Versionen zurückkehren und parallel mit anderen an verschiedenen Features arbeiten.

In dieser Lerneinheit lernst du die fundamentalen Konzepte kennen: Repository, Working Copy, Commits, Branches und wie Änderungen zusammengeführt werden.

Lernziele

Nach dieser Lerneinheit kannst du:

• Den Unterschied zwischen Repository und Working Copy erklären
• Das Konzept von Commits und Revisionen verstehen und anwenden
• Die Rolle der Staging-Area im Workflow beschreiben
• Branches und Tags konzeptuell unterscheiden
• Den Merge-Prozess und die Entstehung von Konflikten nachvollziehen

Überleitung

Versionsverwaltung beginnt mit zwei fundamentalen Konzepten: Repository und Working Copy.

Das Repository ist der zentrale Speicher für deine Projekthistorie. Die Working Copy ist deine persönliche Arbeitskopie, in der du Änderungen vornimmst.

Schauen wir uns diese Konzepte genauer an.

Was ist ein Repository?

Ein Repository ist das Herzstück jeder Versionsverwaltung. Es ist eine zentrale Datenstruktur, in der alle Versionen aller Dateien eines Projekts gespeichert werden.

Das Repository enthält:

• Den aktuellen Stand aller Dateien
• Die vollständige Historie aller Änderungen
• Metadaten: Wer hat wann welche Änderungen vorgenommen und warum
• Informationen über Branches (parallele Entwicklungslinien)
• Informationen über Tags (markierte Versionen)

Ein Repository ist wie ein Archiv, das nicht nur das aktuelle Dokument speichert, sondern auch alle früheren Versionen mit allen Änderungsnotizen.

Git als verteiltes Versionsverwaltungssystem

Git ist ein verteiltes Versionsverwaltungssystem (DVCS). Das bedeutet, dass jeder Entwickler eine vollständige Kopie des Repositories inklusive der gesamten Historie auf seinem Rechner hat.

Zentrale vs. verteilte Versionsverwaltung

Aspekt	Zentrale VCS (z.B. SVN)	Verteilte VCS (z.B. Git)
Repository-Kopie	Nur auf Server	Auf jedem Client vollständig
Historie	Nur auf Server	Lokal verfügbar
Offline-Arbeit	Eingeschränkt	Vollständig möglich
Geschwindigkeit	Netzwerkabhängig	Lokal, sehr schnell
Ausfallsicherheit	Single Point of Failure	Höhere Redundanz

Vorteile verteilter VCS:

• Arbeiten ohne Netzwerkverbindung möglich
• Schnellere Operationen (lokal statt über Netzwerk)
• Bessere Branching- und Merging-Möglichkeiten
• Jeder hat eine vollständige Backup-Kopie

Was ist eine Working Copy?

Die Working Copy (Arbeitskopie) ist deine persönliche Kopie der Projektdateien, an denen du Änderungen vornehmen kannst.

Die Working Copy ist:

• Eine Momentaufnahme bestimmter Dateien aus dem Repository
• Dein lokaler Arbeitsbereich zum Bearbeiten
• Unabhängig vom Repository (Änderungen beeinflussen es nicht direkt)

Der Workflow:

1. Clone: Repository → Working Copy (initiale Kopie erstellen)
2. Edit: Änderungen in der Working Copy vornehmen
3. Commit: Working Copy → Repository (Änderungen hochladen)
4. Update/Pull: Repository → Working Copy (neueste Änderungen abrufen)

Wenn du mit deinen Änderungen zufrieden bist, überträgst du sie durch einen Commit zurück ins Repository, um sie anderen Entwicklern zur Verfügung zu stellen.

Repository ↔ Working Copy Workflow

Der grundlegende Workflow zwischen Repository und Working Copy lässt sich wie folgt darstellen:

Repository und Working Copy (Bildrechte: Ausbildung in der IT)

Beschreibung des Workflows:

1. Clone: Du erstellst eine vollständige Kopie des Repositories auf deinem lokalen System. Diese Kopie enthält die gesamte Versionshistorie und alle Dateien des Projekts.

2. Commit: Nachdem du Änderungen in deiner Working Copy vorgenommen hast, überträgst du diese zurück ins Repository. Ein Commit speichert deine Änderungen dauerhaft in der Versionshistorie.

3. Update/Pull: Du holst die neuesten Änderungen aus dem Repository in deine Working Copy. So bleibst du auf dem aktuellen Stand, besonders wenn andere Entwickler ebenfalls am Projekt arbeiten.

Wichtig: Die Working Copy ist dein persönlicher Arbeitsbereich. Änderungen werden erst durch einen Commit für andere sichtbar.

Was ist ein Commit?

Ein Commit ist eine Momentaufnahme des aktuellen Zustands deiner Working Copy. Stell dir vor, du arbeitest an einem Dokument oder Code – jede wichtige Änderung, die du speichern und nachverfolgen möchtest, führst du als Commit aus.

Bestandteile eines Commits

Jeder Commit enthält:

Bestandteil	Beschreibung
Eindeutige ID	Hash-Wert (z.B. a3f5c2e), der den Commit identifiziert
Änderungen	Die tatsächlichen Dateiänderungen (Diff)
Autor	Name und E-Mail des Entwicklers
Zeitstempel	Datum und Uhrzeit des Commits
Commit-Message	Beschreibung der Änderungen
Parent-Commit	Referenz auf vorherigen Commit(s)

Commits sind unveränderlich: Sobald ein Commit erstellt wurde, kann er nicht mehr geändert werden. Dies gewährleistet die Integrität der Projektgeschichte.

Revisionen

Eine Revision bezeichnet eine spezifische Version deiner Dateien zu einem bestimmten Zeitpunkt. Jeder Commit erzeugt eine neue Revision im Repository.

Wozu dienen Revisionen?

• Rückkehr zu früheren Ständen: Du kannst zu jedem beliebigen Punkt in der Projektgeschichte zurückkehren
• Vergleichen: Unterschiede zwischen verschiedenen Versionen analysieren
• Debugging: Den Zeitpunkt identifizieren, an dem ein Fehler eingeführt wurde
• Dokumentation: Die Evolution des Projekts nachvollziehen

Beispiel: Mit git log kannst du die Historie aller Revisionen anzeigen. Jede Revision wird durch ihre eindeutige Commit-ID referenziert.

Die Staging-Area

Die Staging-Area (auch Index genannt) ist eine Zwischenstufe zwischen deiner Working Copy und dem Repository. Sie fungiert als Vorbereitung für den nächsten Commit.

Warum eine Staging-Area?

Die Staging-Area ermöglicht es dir:

1. Selektiv committen: Nicht alle Änderungen müssen in einen Commit – du entscheidest, welche Dateien bereit sind
2. Logisch gruppieren: Zusammengehörige Änderungen in einem Commit zusammenfassen
3. Überprüfen: Änderungen vor dem Commit nochmal kontrollieren

Die drei Bereiche

• Working Copy → Staging-Area: Mit git add fügst du Änderungen zur Staging-Area hinzu
• Staging-Area → Repository: Mit git commit überträgst du die vorbereiteten Änderungen ins Repository
• Rückgängig machen: Mit git restore kannst du Änderungen aus der Staging-Area oder Working Copy entfernen

Git-Workflow: Von der Änderung zum Commit

Der typische Arbeitsablauf mit Git folgt diesem Muster:

1. Änderungen vorbereiten (Staging)

Bevor du einen Commit machst, musst du entscheiden, welche Dateien einbezogen werden sollen:

# Einzelne Datei zur Staging-Area hinzufügen
git add datei.txt
 
# Alle geänderten Dateien hinzufügen
git add .
 
# Status überprüfen
git status

2. Commit erstellen

Mit git commit werden die vorbereiteten Änderungen gespeichert:

# Commit mit Nachricht
git commit -m "Neue Funktion hinzugefügt"

3. Revision aktualisieren

Nachdem der Commit ausgeführt wurde, erstellt Git eine neue Revision deines Projekts. Diese kannst du jederzeit überprüfen oder zu ihr zurückkehren.

Praktisches Beispiel

Angenommen, du arbeitest an einer Webseite und fügst eine neue Funktion hinzu:

# 1. Neue Datei erstellen
echo "function neuesFunktion() { }" > neue_funktion.js
 
# 2. Änderungen zur Staging-Area hinzufügen
git add neue_funktion.js
 
# 3. Commit erstellen
git commit -m "Neue Funktion hinzugefügt"

Erklärung des Codes

• Zeile 2: Erstellt eine neue JavaScript-Datei mit einer Funktion
• Zeile 5: Fügt die Datei zur Staging-Area hinzu (bereitet sie für den Commit vor)
• Zeile 8: Erstellt den Commit mit einer beschreibenden Nachricht

Nach diesem Commit wird eine neue Revision im Repository erstellt. Diese Revision enthält deine neueste Arbeit sowie die gesamte vorherige Geschichte deines Projekts.

Wichtige Prinzipien

Gute Commit-Nachrichten sind entscheidend

Eine gute Commit-Message hilft dir und anderen, die Projektgeschichte nachzuvollziehen:

❌ Schlecht:

"Änderungen"
"fix"
"Update"

✅ Gut:

"Füge Benutzer-Authentifizierung hinzu"
"Behebe Fehler in Datenbankabfrage"
"Aktualisiere Dokumentation für API v2"

Best Practices

• Kleine, fokussierte Commits: Ein Commit sollte eine logische Änderung enthalten
• Regelmäßig committen: Häufige Commits erleichtern das Nachvollziehen der Entwicklung
• Beschreibende Nachrichten: Erkläre das “Warum”, nicht nur das “Was”
• Vor dem Commit testen: Stelle sicher, dass dein Code funktioniert

⏳ Lädt Dataview-Inhalt...

Was sind Branches?

Ein Branch ist eine von der Hauptlinie abzweigende Entwicklungslinie. Er ermöglicht es dir, an neuen Features, Bugfixes oder Experimenten zu arbeiten, ohne die Hauptlinie des Projekts zu beeinträchtigen.

Warum Branches?

• Parallele Entwicklung: Mehrere Features können gleichzeitig entwickelt werden
• Isolierte Experimente: Neue Ideen ausprobieren ohne Risiko
• Strukturierter Workflow: Klare Trennung zwischen stabiler Hauptlinie und Entwicklung
• Code-Review: Änderungen können vor der Integration überprüft werden

Moderner Branch-Name: main

Der Standard-Branch heißt heute main (früher master). Dies ist die aktuelle Best Practice in der Softwareentwicklung.

Konzeptuelles Beispiel

Stell dir vor, du entwickelst eine Webseite. Der main-Branch enthält die stabile Version. Für ein neues Login-Feature erstellst du einen Branch feature/login. Dort kannst du arbeiten, ohne die Hauptversion zu beeinflussen.

Was sind Tags?

Ein Tag wird verwendet, um einen bestimmten Punkt in der Versionsgeschichte eines Projekts zu markieren. Tags werden häufig genutzt, um Versionen (wie z.B. v1.0, v2.0) zu kennzeichnen.

Eigenschaften von Tags

• Feste Punkte: Tags ändern sich nicht, sobald sie erstellt wurden
• Versionierung: Markieren wichtige Meilensteine (Releases, Versionen)
• Referenz: Ermöglichen schnellen Zugriff auf spezifische Projektstände

Typische Verwendung

• Release-Versionen: v1.0.0, v2.1.3
• Meilensteine: alpha, beta, release-candidate
• Wichtige Zeitpunkte: before-refactoring, stable-2024-03

Wichtig: Im Gegensatz zu Branches, die sich weiterentwickeln, sind Tags statische Markierungen in der Historie.

Branches vs. Tags

Unterschiede auf einen Blick

Aspekt	Branches	Tags
Zweck	Parallele Entwicklungslinien	Versionierungspunkte markieren
Veränderlich	Ja, neue Commits möglich	Nein, fester Punkt
Verwendung	Feature-Entwicklung, Bugfixes	Releases, Meilensteine
Lifecycle	Werden oft gelöscht nach Merge	Bleiben dauerhaft erhalten
Beispiele	main, feature/login, bugfix/auth	v1.0.0, v2.1.3, release-2024

Merke: Branches sind aktive Arbeitslinien, Tags sind historische Markierungen.

Branch-Workflow visualisiert

Branch Workflow (Bildrechte: Ausbildung in der IT)

Beschreibung des Workflows:

1. Start: Projekt beginnt auf dem main-Branch
2. Branching: Für neue Features und Bugfixes werden separate Branches erstellt
3. Entwicklung: In den Branches wird parallel gearbeitet
4. Merge: Nach Fertigstellung werden die Änderungen zurück in main integriert
5. Neuer Stand: Der main-Branch enthält nun beide Änderungen

In der nächsten Lerneinheit lernst du die praktischen Git-Befehle für Branching kennen. Hier geht es zunächst um das konzeptuelle Verständnis.

Was ist Merging?

Merging bezeichnet den Prozess, bei dem Änderungen aus zwei oder mehreren Branches zusammengeführt werden. Die Herausforderung besteht darin, die individuellen Änderungen so zu kombinieren, dass das Endprodukt konsistent und fehlerfrei ist.

Arten von Merges

Automatischer Merge:

• Tritt auf, wenn Änderungen keine überlappenden Bereiche betreffen
• Das Versionsverwaltungssystem führt die Änderungen selbstständig zusammen
• Keine menschliche Intervention erforderlich

Manueller Merge:

• Erforderlich, wenn Änderungen die gleichen Bereiche betreffen
• Das System kann nicht automatisch entscheiden
• Entwickler muss Konflikte manuell auflösen

Wichtig: Häufige Updates deines Branches mit dem Hauptbranch reduzieren die Anzahl und Komplexität von Merge-Konflikten.

⏳ Lädt Dataview-Inhalt...

Merge-Konflikte verstehen

Ein Konflikt tritt auf, wenn zwei Entwickler die gleichen Zeilen in einer Datei geändert haben und das System nicht automatisch entscheiden kann, welche Version beibehalten werden soll.

Wie entstehen Konflikte?

Typisches Szenario:

1. Entwickler A und B arbeiten beide am gleichen Projekt
2. Beide ändern die gleiche Zeile in login.js
3. Entwickler A committed und pusht seine Änderungen zuerst
4. Entwickler B hat die Änderungen von A noch nicht abgerufen (kein git pull)
5. Wenn B jetzt seine Änderungen pushen will, erkennt Git den Konflikt

Konfliktmarkierungen

Git markiert Konflikte mit speziellen Indikatoren:

<<<<<<< HEAD (deine lokale Version)
Hallo von Entwickler A!
=======
Hallo von Entwickler B!
>>>>>>> branch-b (eingehende Version)

Auflösung eines Konflikts

1. Konflikt identifizieren: Git zeigt betroffene Dateien an
2. Beide Versionen prüfen: Verstehe, was jeder Entwickler geändert hat
3. Entscheidung treffen: Welche Änderung soll bleiben? Oder beide kombinieren?
4. Anpassungen vornehmen: Datei manuell bearbeiten
5. Markierungen entfernen: <<<<<<<, =======, >>>>>>> löschen
6. Neuen Commit erstellen: Aufgelösten Stand committen

Beispiel-Auflösung

Kombination beider Änderungen:

Hallo von Entwickler A und B!

Zusammenfassung und Ausblick

Zusammenfassung:

Das Repository speichert die gesamte Projekthistorie zentral. Bei verteilten Versionsverwaltungssystemen (DVCS) wie Git hat jeder Entwickler eine vollständige Kopie des Repositories lokal – das ermöglicht Offline-Arbeit und höhere Geschwindigkeit. Die Working Copy ist deine lokale Arbeitskopie, in der du Änderungen vornimmst.

Über Commits werden Änderungen als Momentaufnahmen gespeichert – jeder Commit erzeugt eine neue Revision. Die Staging-Area ermöglicht dir, gezielt zu entscheiden, welche Änderungen in einen Commit aufgenommen werden. Gute Commit-Nachrichten sind entscheidend, um die Projektgeschichte nachvollziehbar zu machen.

Branches schaffen parallele Entwicklungslinien für Features oder Experimente. Tags markieren feste Punkte in der Historie (z.B. Release-Versionen). Beim Merging werden Branches zusammengeführt – Konflikte entstehen, wenn dieselben Zeilen unterschiedlich geändert wurden, und müssen manuell aufgelöst werden.

Ausblick

In der nächsten Lerneinheit wendest du diese Konzepte praktisch an: Du lernst die Git-Befehle kennen, mit denen du Repositories erstellst, Commits machst, Branches verwaltest und die Projekthistorie navigierst.

---