📦 Git & Versionskontrolle

1. Was ist Git?

Git ist ein verteiltes Versionskontrollsystem. Es speichert nachvollziehbare Zwischenstände eines Projekts, sodass Änderungen verglichen, gemeinsam bearbeitet und bei Bedarf gezielt zurückgenommen werden können.

Was Git nicht automatisch erledigt

• Git entscheidet nicht selbst, welche Änderungen fachlich richtig sind.
• Ein Commit entsteht erst, wenn Änderungen bewusst ausgewählt und gespeichert werden.
• Ein lokales Repository ist noch kein externes Backup.
• Große Binärdateien und Zugangsdaten gehören nicht einfach in die Versionsgeschichte.

2. Git, GitHub und GitLab – der Unterschied

Git und Hosting-Plattformen werden häufig verwechselt. Sie erfüllen jedoch verschiedene Aufgaben.

3. Die vier Arbeitsbereiche

Der Git-Ablauf wird verständlicher, wenn du die Bereiche kennst, zwischen denen Änderungen bewegt werden.

4. Installation prüfen und Git einrichten

Nach der Installation solltest du zuerst prüfen, ob Git im Terminal verfügbar ist. Anschließend werden Name und E-Mail-Adresse für neue Commits festgelegt.

git --version

git config --global user.name "Vorname Nachname"
git config --global user.email "name@example.de"

# Konfiguration kontrollieren
git config --global --list

Die Option --global gilt für alle Repositorys dieses Benutzerkontos. Ohne diese Option kann eine abweichende Einstellung nur für das aktuelle Repository gesetzt werden.

5. Repository erstellen oder klonen

Variante A: vorhandenen Projektordner initialisieren

cd mein-projekt
git init
git status
git add .
git commit -m "Projektgrundlage anlegen"
git branch -M main

git init richtet im aktuellen Ordner ein lokales Repository ein. Vor git add . sollte mit git status und git diff kontrolliert werden, welche Dateien aufgenommen werden.

Variante B: vorhandenes Repository klonen

git clone https://example.com/team/mein-projekt.git
cd mein-projekt
git status

git clone lädt Dateien, Commit-Geschichte und Remote-Verbindung. Die Beispieladresse muss durch die echte HTTPS- oder SSH-Adresse des Repositorys ersetzt werden.

6. Der tägliche Git-Arbeitsablauf

Ein sauberer Ablauf besteht aus Prüfen, Auswählen, Kontrollieren, Committen und anschließendem Austauschen mit dem Remote-Repository.

1. 1
   Status prüfengit status zeigt neue, veränderte und bereits vorgemerkte Dateien.
2. 2
   Änderungen vergleichengit diff zeigt noch nicht vorgemerkte Unterschiede.
3. 3
   Gezielt stagengit add datei.html nimmt eine passende Änderung in die Staging Area auf.
4. 4
   Staging Area kontrollierengit diff --staged zeigt genau den Inhalt des nächsten Commits.
5. 5
   Commit erstellengit commit -m "Navigation mobil optimieren" speichert den ausgewählten Stand lokal.
6. 6
   Commits austauschenErst aktuelle Remote-Änderungen integrieren und anschließend mit git push veröffentlichen.

git status
git diff
git add index.html css/style.css
git diff --staged
git commit -m "Startseite responsiv optimieren"
git pull --ff-only
git push

7. Branches und Zusammenführen

Ein Branch ist eine bewegliche Entwicklungslinie. Neue Funktionen können dort entstehen, während der Hauptbranch stabil bleibt.

Feature-Branch erstellen und zusammenführen

# Neuen Branch erstellen und direkt wechseln
git switch -c feature/kontaktformular

# Änderungen bearbeiten, prüfen und committen
git status
git add kontakt.html js/formular.js
git commit -m "Kontaktformular validieren"

# Hauptbranch aktualisieren und Feature zusammenführen
git switch main
git pull --ff-only
git merge feature/kontaktformular
git push

# Nicht mehr benötigten lokalen Branch entfernen
git branch -d feature/kontaktformular

8. Remote-Repository und Zusammenarbeit

Ein Remote ist eine benannte Verbindung zu einem entfernten Repository. Der häufig verwendete Standardname lautet origin, ist aber technisch frei wählbar.

# Verbindungen anzeigen
git remote -v

# Remote zu einem lokalen Repository hinzufügen
git remote add origin https://example.com/team/mein-projekt.git

# Hauptbranch erstmalig übertragen und verknüpfen
git push -u origin main

Fetch, Pull und Push unterscheiden

Ein einfacher Teamablauf

1. 1
   Aktuellen Stand holenVor Arbeitsbeginn den relevanten Branch aktualisieren.
2. 2
   Feature-Branch erstellenEine Aufgabe in einer getrennten Entwicklungslinie bearbeiten.
3. 3
   Kleine Commits erstellenZusammengehörige Änderungen mit verständlichen Nachrichten speichern.
4. 4
   Branch pushenDen Feature-Branch zum Remote-Repository übertragen.
5. 5
   Änderungen prüfen lassenPull beziehungsweise Merge Request erstellen und Rückmeldungen bearbeiten.

9. .gitignore und sensible Daten

Die Datei .gitignore legt fest, welche noch nicht verfolgten Dateien oder Ordner Git normalerweise ignorieren soll. Typische Beispiele sind Abhängigkeiten, temporäre Dateien, Build-Ausgaben und lokale Konfigurationen.

# Abhängigkeiten
node_modules/

# Build-Ausgaben
dist/
build/

# Lokale Umgebungsvariablen
.env
.env.local

# Protokolle und Editor-Einstellungen
*.log
.idea/
.vscode/

Bereits verfolgte Datei ignorieren

Wurde eine harmlose Datei bereits committet, reicht ein neuer Eintrag in .gitignore nicht aus. Sie kann aus der Git-Verfolgung entfernt werden, ohne die lokale Datei zu löschen:

git rm --cached pfad/zur/datei
git commit -m "Lokale Konfiguration nicht mehr versionieren"

10. Merge-Konflikte verstehen und lösen

Ein Konflikt entsteht, wenn Git verschiedene Änderungen nicht eindeutig automatisch zusammenführen kann. Das ist kein Defekt, sondern eine Aufforderung zur fachlichen Entscheidung.

So kann ein Konflikt in einer Datei aussehen

<<<<<<< HEAD
<h1>Willkommen bei Digitale Start-Hilfe</h1>
=======
<h1>Professionelle Web-Entwicklung</h1>
>>>>>>> feature/neue-headline

1. 1
   Konflikte anzeigengit status nennt die betroffenen Dateien.
2. 2
   Inhalt fachlich entscheidenKonfliktmarkierungen entfernen und die gewünschte Endfassung schreiben.
3. 3
   Ergebnis testenSeite oder Anwendung ausführen und die zusammengeführte Änderung prüfen.
4. 4
   Lösung stagenDie bereinigten Dateien mit git add als gelöst markieren.
5. 5
   Vorgang abschließenJe nach Ausgangsvorgang Merge oder Rebase fortsetzen beziehungsweise committen.

git status
git add index.html
git commit

11. Änderungen sicher rückgängig machen

Der richtige Befehl hängt davon ab, ob eine Änderung nur im Arbeitsverzeichnis liegt, bereits gestaged, lokal committet oder schon veröffentlicht wurde.

12. Stashing – Änderungen zwischenspeichern

Stashing erlaubt es, unfertige Änderungen zwischenzuspeichern, ohne sie zu committen. Das ist praktisch, wenn du schnell den Branch wechseln musst.

# Aktuelle Änderungen zwischenspeichern
git stash

# Stash-Liste anzeigen
git stash list

# Letzten Stash wieder anwenden und entfernen
git stash pop

# Letzten Stash anwenden (behalten)
git stash apply

# Stash mit Beschreibung
git stash push -m "Navigation in Arbeit"

13. Tags – Versionen markieren

Tags sind feste Markierungen für bestimmte Commits. Sie werden oft verwendet, um Release-Versionen (v1.0, v2.0) zu kennzeichnen.

# Leichten Tag erstellen (nur Name)
git tag v1.0.0

# Annotierten Tag mit Nachricht
git tag -a v1.0.0 -m "Release Version 1.0.0"

# Tags anzeigen
git tag

# Tag zu Remote übertragen
git push origin v1.0.0

# Alle Tags übertragen
git push --tags

14. Rebase vs. Merge

Beide Befehle integrieren Änderungen, aber auf unterschiedliche Weise. Merge erstellt einen Merge-Commit, während Rebase die Commit-Historie umschreibt.

# Merge (behält Historie)
git checkout main
git merge feature-branch

# Rebase (schreibt Historie um)
git checkout feature-branch
git rebase main
git checkout main
git merge feature-branch

15. Git-Hooks – Automatisierung

Git-Hooks sind Skripte, die bei bestimmten Git-Ereignissen automatisch ausgeführt werden. Sie können beispielsweise Tests vor dem Commit ausführen oder Nachrichten-Formate prüfen.

# pre-commit – Läuft vor dem Commit
#!/bin/sh
# Führt Tests aus, bevor der Commit erstellt wird
npm test

# commit-msg – Prüft Commit-Nachricht
#!/bin/sh
# Stellt sicher, dass die Commit-Nachricht ein bestimmtes Format hat
grep -q "^(feat|fix|docs|style|refactor|test|chore)" $1

16. Submodule – externe Repositories einbinden

Submodule ermöglichen es, ein anderes Git-Repository als Unterverzeichnis in dein eigenes Repository einzubinden. Das ist nützlich für gemeinsame Bibliotheken oder Tools.

# Submodule hinzufügen
git submodule add https://example.com/team/shared-library.git libs/shared

# Submodule initialisieren und aktualisieren
git submodule update --init --recursive

# Submodule auf neuesten Stand bringen
git submodule update --remote

17. Gute Commits und Best Practices

Gute und schwache Commit-Nachrichten

18. Interaktiver Git-Befehlshelfer

Wähle eine typische Aufgabe. Der Helfer zeigt dir einen passenden Ausgangspunkt und erklärt kurz die Wirkung.

19. Checkliste für dein erstes Git-Projekt

Hake die erledigten Punkte ab. Die Auswahl bleibt nur während dieses Seitenaufrufs erhalten.

0 von 10 Punkten erledigt

20. Häufige Fehler und Lösungen

21. Übungen zum Mitmachen

Lege für die Übungen am besten einen neuen Testordner ohne wichtige Dateien an.

Mini-Projekt: Webseite versionieren

1. 1
   Grundlage anlegenErstelle HTML-, CSS- und JavaScript-Datei mit einer einfachen Startseite.
2. 2
   Ersten Stand sichernPrüfe alle Dateien und erstelle einen klar benannten Anfangs-Commit.
3. 3
   Feature entwickelnBaue in einem Branch einen Über-mich-Abschnitt ein.
4. 4
   Unterschiede prüfenUntersuche die Änderung mit git diff und git log --oneline.
5. 5
   ZusammenführenMerge das getestete Feature und lösche danach den nicht mehr benötigten Branch.
6. 6
   Release-Tag setzenErstelle einen annotierten Tag für den aktuellen Stand.

22. Häufige Fragen zu Git