Fortgeschrittene Themen

In dieser Lerneinheit tauchst du tief in die Konzepte von Tagging und Releasing ein - zwei essenzielle Techniken für die strukturierte Softwareentwicklung. Du lernst, wie du wichtige Meilensteine deiner Projekte durch Tags markierst und Release-Versionen professionell erstellst und verwaltest. Diese Fähigkeiten sind besonders relevant für die Arbeit in größeren Entwicklungsteams und bei der Veröffentlichung von Software-Releases.

Einführung

Du arbeitest an einem Feature-Branch und plötzlich meldet sich dein Team-Lead: Ein kritischer Bug im Production-Branch muss sofort behoben werden.

Vorher-Nachher: Ohne fortgeschrittene Git-Techniken herrscht Panik - mit Tags, Stashing, Submodules und Hooks behältst du die Kontrolle. — Bildrechte: Ausbildung-in-der-IT.de (KI-unterstützt)

Aber deine aktuellen Änderungen sind noch nicht fertig zum Committen. Was jetzt?

Oder ein anderes Szenario: Dein Projekt erreicht einen stabilen Zustand. Die neue Version soll veröffentlicht werden. Wie markierst du diesen Meilenstein so, dass du jederzeit exakt diesen Stand wiederherstellen kannst?

In dieser Lerneinheit lernst du, wie Git-Techniken wie Tagging, Stashing, Submodules und Hooks dir helfen, solche Situationen professionell zu meistern und deine Workflows zu automatisieren.

Lernziele

Nach dieser Lerneinheit kannst du:

• Tags erstellen und zur Markierung von Release-Versionen einsetzen
• Stashing nutzen, um Änderungen temporär zu sichern und zwischen Branches zu wechseln
• Submodules verstehen und externe Repositories in dein Projekt einbinden
• Git Hooks einrichten, um Workflows zu automatisieren und Code-Qualität zu sichern

Überleitung

Um diese Workflows zu meistern, starten wir mit einer der wichtigsten Techniken der Versionsverwaltung: Tags.

Tags sind wie Lesezeichen in der Git-Historie – sie markieren wichtige Punkte wie Release-Versionen dauerhaft.

Was sind Tags und wann nutzt du sie?

Ein Tag ist eine feste Referenz auf einen bestimmten Commit in der Git-Historie. Im Gegensatz zu Branches, die sich mit jedem Commit weiterbewegen, bleibt ein Tag statisch und zeigt immer auf denselben Commit.

Typische Anwendungsfälle:

• Release-Versionen markieren: Jede veröffentlichte Version erhält einen Tag (z. B. v1.0.0, v2.1.3)
• Meilensteine dokumentieren: Wichtige Projektphasen wie “Beta-Release” oder “Feature-Freeze”
• Schneller Zugriff: Statt nach Commit-Hashes zu suchen, kannst du direkt zum Tag springen

Tag-Typen und wichtige Befehle

Git kennt zwei Tag-Arten:

Tag-Typ	Beschreibung	Verwendung
Lightweight Tag	Einfacher Zeiger auf einen Commit (nur Name)	Schnelle temporäre Markierungen
Annotated Tag	Vollständiges Git-Objekt mit Metadaten (Name, E-Mail, Datum, Nachricht)	Empfohlen für Releases

Wichtige Tag-Befehle:

Befehl	Funktion
git tag v1.0.0	Lightweight Tag erstellen
git tag -a v1.0.0 -m "Release 1.0"	Annotated Tag erstellen
git tag	Alle Tags auflisten
git show v1.0.0	Tag-Details anzeigen
git push origin v1.0.0	Tag zum Remote pushen
git push origin --tags	Alle Tags pushen

Was ist Stashing?

Stashing ermöglicht es dir, unfertige Änderungen temporär zu sichern, ohne einen Commit zu erstellen. Der Arbeitsbereich wird dadurch “sauber” und du kannst den Branch wechseln.

Stell dir vor, du arbeitest an einem Feature, aber ein dringender Bugfix im main-Branch hat Vorrang. Mit Stashing speicherst du deine Änderungen und holst sie später zurück.

Wann brauchst du Stashing?

• Branch wechseln ohne Änderungen zu committen
• Pull durchführen bei lokalen Änderungen
• Experimente temporär sichern

Stash-Befehle Übersicht

Befehl	Funktion
git stash	Änderungen stashen
git stash save "Beschreibung"	Stash mit Nachricht
git stash list	Alle Stashes anzeigen
git stash pop	Letzten Stash anwenden + löschen
git stash apply stash@{0}	Bestimmten Stash anwenden (behält ihn)
git stash drop stash@{0}	Stash löschen
git stash clear	Alle Stashes löschen

Tipp: Nutze git stash pop für den häufigsten Fall (Änderungen zurückholen + Stash entfernen).

Was sind Submodules?

Submodules ermöglichen es dir, ein Git-Repository als Unterverzeichnis in ein anderes Repository einzubinden. Das ist nützlich, wenn du externe Bibliotheken oder gemeinsam genutzte Komponenten in dein Projekt integrieren möchtest.

Typische Anwendungsfälle:

• Externe Bibliotheken einbinden, die ebenfalls unter Git-Versionierung stehen
• Gemeinsame Komponenten zwischen mehreren Projekten teilen
• Abhängigkeiten auf einem bestimmten Stand halten

Wichtig: Das Hauptprojekt speichert nur einen Verweis auf einen bestimmten Commit des Submodules. Updates müssen manuell durchgeführt werden.

Git Hooks Grundlagen

Git Hooks sind Skripte, die automatisch vor oder nach bestimmten Git-Operationen ausgeführt werden. Sie ermöglichen Automatisierung und Qualitätssicherung direkt im Git-Workflow.

Hook-Typ	Ausführungsort	Typische Beispiele
Client-seitig	Lokaler Entwickler-Rechner	pre-commit, commit-msg, pre-push
Server-seitig	Git-Server (z. B. GitHub)	pre-receive, post-receive, update

Häufige Einsatzgebiete:

• Code-Qualität: Linter vor Commit ausführen
• Tests: Automatische Tests vor Push
• Formatierung: Code automatisch formatieren
• Commit-Messages: Format erzwingen (z. B. Conventional Commits)

⏳ Lädt Dataview-Inhalt...

Praxisbeispiel: Release mit Tags erstellen

So erstellst du ein Release mit einem annotierten Tag:

# 1. Stelle sicher, dass alle Änderungen committed sind
git status
 
# 2. Erstelle einen annotierten Tag für die neue Version
git tag -a v1.0.0 -m "Release 1.0.0: Erste stabile Version"
 
# 3. Zeige Details zum Tag an
git show v1.0.0
 
# 4. Pushe den Tag zum Remote-Repository
git push origin v1.0.0
 
# Alternativ: Alle Tags auf einmal pushen
git push origin --tags

Was passiert hier?

• Der Tag v1.0.0 markiert den aktuellen Commit als Release
• Die -a Flag erstellt einen annotierten Tag mit Metadaten
• Die Nachricht beschreibt, was in diesem Release enthalten ist
• Mit git push origin v1.0.0 wird der Tag zum Server hochgeladen

Wichtig: Tags werden nicht automatisch mit git push übertragen - du musst sie explizit pushen.

Praxisbeispiel: Submodule einbinden

So bindest du eine externe Bibliothek als Submodule ein:

# 1. Submodule zum Projekt hinzufügen
git submodule add https://github.com/user/awesome-lib.git libs/awesome-lib
 
# 2. Die .gitmodules-Datei wird automatisch erstellt
git add .gitmodules libs/awesome-lib
git commit -m "Add awesome-lib as submodule"
 
# 3. Projekt mit Submodules klonen (für andere Entwickler)
git clone https://github.com/yourproject/myapp.git
cd myapp
git submodule init
git submodule update
 
# Oder in einem Befehl:
git clone --recurse-submodules https://github.com/yourproject/myapp.git

Was passiert hier?

• git submodule add bindet das externe Repository als Unterverzeichnis ein
• Die .gitmodules-Datei speichert die Konfiguration
• Beim Klonen müssen Submodules mit --recurse-submodules oder manuell mit init + update geladen werden

Wichtig: Das Hauptprojekt speichert nur einen Commit-Hash des Submodules. Updates erfordern einen neuen Commit im Hauptprojekt.

Praxisbeispiel: Stash-Workflow

Szenario: Du arbeitest an einem Feature, musst aber schnell einen Bugfix im main-Branch machen.

# 1. Du arbeitest am Feature-Branch
git switch feature-login
# ... Änderungen an login.js ...
 
# 2. Dringender Bugfix im main - Änderungen stashen
git stash save "Login-Feature: Work in Progress"
 
# 3. Zum main-Branch wechseln
git switch main
 
# 4. Bugfix durchführen
git add .
git commit -m "Fix: Kritischer Bug in der API"
 
# 5. Zurück zum Feature-Branch
git switch feature-login
 
# 6. Gestashte Änderungen wiederherstellen
git stash pop

Was passiert hier?

• git stash save speichert deine unfertigen Änderungen temporär
• Der Working Directory wird sauber und du kannst den Branch wechseln
• Nach dem Bugfix holst du deine Änderungen mit git stash pop zurück
• pop wendet den Stash an und löscht ihn

Alternativ: Mit git stash apply behältst du den Stash nach dem Anwenden.

Git LFS Grundlagen

Git Large File Storage (LFS) ist eine Erweiterung für große Binärdateien wie Videos, Grafiken oder kompilierte Assets.

Das Problem: Große Binärdateien blähen das Repository auf, da Git jede Version vollständig speichert.

Die Lösung: Git LFS speichert nur Zeiger im Repository, die eigentlichen Dateien liegen auf einem separaten Server.

# Git LFS installieren und aktivieren
git lfs install
 
# Dateitypen für LFS markieren
git lfs track "*.psd"
git lfs track "*.mp4"
 
# .gitattributes committen
git add .gitattributes
git commit -m "Add LFS tracking for PSD and MP4 files"

Tipp: Nutze LFS für Dateien über 5 MB. Textdateien und Code gehören nicht in LFS.

⏳ Lädt Dataview-Inhalt...

Zusammenfassung und Ausblick

Zusammenfassung:

Tags für Release-Management

Tags markieren wichtige Meilensteine in der Git-Historie dauerhaft.

• Lightweight Tags: Einfache Zeiger auf Commits für temporäre Markierungen
• Annotated Tags: Vollständige Git-Objekte mit Metadaten - empfohlen für Releases
• Workflow: git tag -a v1.0.0 -m "Release 1.0.0" → git push origin v1.0.0
• Best Practice: Nutze annotierte Tags für Releases, da sie Metadaten (Autor, Datum, Message) speichern

Stashing für flexible Workflows

Stashing sichert unfertige Änderungen temporär ohne Commit.

• Anwendungsfall: Branch wechseln trotz unfertiger Arbeit
• Workflow: git stash → Branch wechseln → Arbeit erledigen → zurück → git stash pop
• Wichtig: git stash pop wendet den Stash an UND löscht ihn
• Best Practice: Nutze beschreibende Nachrichten mit git stash save "Beschreibung"

Submodules für modulare Projekte

Submodules binden externe Repositories als Unterverzeichnis ein.

• Workflow: git submodule add <url> <pfad> → .gitmodules wird erstellt
• Klonen mit Submodules: git clone --recurse-submodules oder git submodule init && git submodule update
• Wichtig: Das Hauptprojekt speichert nur einen Commit-Hash des Submodules
• Best Practice: Updates müssen manuell durchgeführt und committed werden

Git Hooks für Automatisierung

Hooks sind Skripte, die automatisch bei Git-Operationen ausgeführt werden.

• Client-seitig: pre-commit, commit-msg, pre-push (lokal)
• Server-seitig: pre-receive, post-receive, update (auf Git-Server)
• Anwendungsfälle: Code-Qualität (Linter), Tests, Formatierung, Commit-Message-Format
• Aktivierung: Skript in .git/hooks/ erstellen und ausführbar machen (chmod +x)

Git LFS für große Dateien

Git LFS verwaltet große Binärdateien außerhalb des Repositories.

• Problem: Große Binärdateien blähen das Repository auf
• Lösung: Git LFS speichert nur Zeiger im Repo, Dateien auf separatem Server
• Workflow: git lfs install → git lfs track "*.psd" → .gitattributes committen
• Best Practice: Nutze LFS für Dateien > 5 MB, nicht für Textdateien/Code

Ausblick:

In der nächsten Lerneinheit Tools und Ökosystem lernst du die wichtigsten Git-Tools und Plattformen kennen. Du verstehst, wie GUI-Tools deine Arbeit ergänzen und wie Git-Hosting-Plattformen wie GitHub, GitLab und Bitbucket die Teamarbeit unterstützen.

---