Einführung in Git und GitLab

Warum arbeiten professionelle Teams nicht einfach mit geteilten Ordnern oder Datei-Kopien? Dieses Modul klärt, welches Problem Versionskontrolle löst und warum Git sich als Standard durchgesetzt hat. Sie verstehen die drei Zustände (Working Directory, Staging Area, Repository) und sehen, wie Git Änderungen als Snapshots speichert statt als Diffs. Am Ende wissen Sie, wie Git intern funktioniert und worin es sich von zentralen Systemen wie SVN unterscheidet.

Hands-on ab der ersten Minute: Sie installieren Git, konfigurieren user.name und user.email und legen mit git init Ihr erstes Repository an. Dann durchlaufen Sie den kompletten Commit-Zyklus: Dateien erstellen, mit git add stagen und mit git commit sichern. Sie richten eine .gitignore ein, um Build-Artefakte und Secrets auszuschließen, und verstehen, warum eine saubere .gitignore von Anfang an Zeit spart.

Ein Repository ohne lesbaren Verlauf ist kaum besser als ein Backup-Ordner. Sie arbeiten mit git log (und dessen Formatierungsoptionen), git diff und git show, um Änderungen zwischen Commits gezielt zu vergleichen. Mit git tag markieren Sie Releases, und git blame zeigt Ihnen zeilengenau, wer wann welche Änderung eingeführt hat. Am Ende navigieren Sie sicher durch die History und finden schnell, was Sie suchen.

Branches sind das Werkzeug, mit dem Teams parallel an Features arbeiten, ohne sich gegenseitig zu blockieren. Sie erstellen Feature-Branches mit git branch und git switch, arbeiten isoliert und führen Änderungen mit git merge zusammen. Dabei sehen Sie den Unterschied zwischen Fast-Forward und 3-Way-Merge in der Praxis. Zum Schluss provozieren Sie bewusst einen Merge-Konflikt und lösen ihn Schritt für Schritt.

Lokale Repositories allein reichen nicht, sobald Sie im Team arbeiten. Sie verbinden Ihr lokales Repository mit einem GitLab-Remote, klonen bestehende Projekte mit git clone und synchronisieren Änderungen mit git push, git pull und git fetch. Wann ist pull sinnvoll, wann besser fetch + manueller Merge? Sie sehen, wie Remote-Tracking Branches funktionieren und warum git push --force im Team gefährlich ist.

GitLab ist mehr als ein Git-Server. Sie legen Projekte und Gruppen an, verstehen die Rollenstruktur von Guest bis Owner und konfigurieren, wer was sehen und ändern darf. Für die Authentifizierung richten Sie SSH Keys und Personal Access Tokens ein. Dann aktivieren Sie signierte Commits mit SSH oder GPG, sodass GitLab verifizierte Commits mit einem grünen Badge markiert. In vielen Unternehmen ist Commit-Signierung mittlerweile Pflicht. Zum Schluss sehen Sie, wie Gruppen Berechtigungen an alle enthaltenen Projekte vererben, und setzen eine Projektstruktur auf, die für ein Team mit mehreren Repositories funktioniert.

Der Merge Request ist das Herzstück der Zusammenarbeit in GitLab. Sie erstellen einen MR von Ihrem Feature-Branch, weisen Reviewer zu und führen eine Code-Review-Diskussion direkt im Diff. Dann konfigurieren Sie Approval Rules (wie viele Approvals nötig sind) und vergleichen die Merge-Optionen: Merge Commit, Squash und Fast-Forward Merge. Sie sehen, wie ein sauberer MR-Workflow aussieht und warum er Code-Qualität messbar verbessert.

Wer darf direkt auf main pushen? Idealerweise niemand. Sie konfigurieren Protected Branches, die direkte Pushes blockieren und Merges nur nach Approval erlauben. Mit der CODEOWNERS-Datei weisen Sie automatisch Reviewer zu, sobald bestimmte Dateien oder Verzeichnisse betroffen sind. Für Teams mit hoher Merge-Frequenz richten Sie Merge Trains ein: GitLab testet Merge Requests automatisch gegen den aktuellen Stand von main und merged sie der Reihe nach, ohne dass Konflikte durchrutschen.

GitLab kann Ihr Ticketsystem ersetzen. Sie erstellen Issues mit Labels, Gewichtung und Zeitschätzung, organisieren sie auf Boards (Kanban-Stil) und gruppieren sie in Milestones für Release-Zyklen. Dann verknüpfen Sie Issues mit Merge Requests, sodass beim Merge automatisch das zugehörige Issue geschlossen wird. Sie sehen, wie Labels und Boards zusammenspielen und wo GitLab-Projektmanagement an seine Grenzen stößt.

Projektdokumentation gehört dorthin, wo der Code liegt. Sie legen ein Wiki direkt im GitLab-Projekt an, strukturieren es mit Markdown-Seiten und sehen, dass das Wiki selbst ein Git-Repository ist, das Sie lokal klonen und bearbeiten können. Mit Snippets speichern und teilen Sie wiederverwendbare Code-Fragmente. Zum Abschluss: eine Übersicht, wie Sie GitLab-Markdown mit Mermaid-Diagrammen, Task-Listen und Tabellen für technische Dokumentation nutzen.

Drei Werkzeuge, die Ihren Git-Alltag verändern. Mit git rebase integrieren Sie Änderungen aus main ohne zusätzliche Merge-Commits und halten die History linear. Interactive Rebase (git rebase -i) lässt Sie Commits nachträglich zusammenfassen, umordnen oder umbenennen, bevor Sie einen Merge Request erstellen. git cherry-pick übernimmt einzelne Commits gezielt in einen anderen Branch (z.B. Hotfixes). Und git stash parkt angefangene Arbeit, wenn Sie kurzfristig den Branch wechseln müssen.

Etwas schiefgegangen? Kein Grund zur Panik. Sie lernen git reflog kennen, das jeden HEAD-Wechsel protokolliert und Ihnen erlaubt, verlorene Commits oder versehentlich gelöschte Branches wiederherzustellen. Dann vergleichen Sie git reset in den drei Varianten (--soft, --mixed, --hard) und verstehen, wann welche Variante sicher ist. Für bereits gepushte Commits nutzen Sie git revert, das Änderungen rückgängig macht, ohne die geteilte History umzuschreiben. Am Ende haben Sie ein Repertoire, das Ihnen die Angst vor Git-Fehlern nimmt.

Welche Branching-Strategie passt zu Ihrem Team? Sie vergleichen drei verbreitete Modelle: Git Flow mit Release- und Hotfix-Branches für klassische Release-Zyklen, GitHub Flow als schlanke Alternative mit einem einzigen Main-Branch und Feature-Branches, und Trunk-Based Development für Teams mit kontinuierlichem Deployment. Für jede Strategie konfigurieren Sie die passenden Protected-Branch-Regeln in GitLab und diskutieren, bei welcher Teamgröße und welchem Release-Rhythmus welches Modell seine Stärken ausspielt.

Ein Vorgeschmack auf das, was in unserer GitLab CI/CD Schulung im Detail behandelt wird. Sie schreiben eine einfache .gitlab-ci.yml mit zwei Stages (build und test), definieren Jobs mit Scripts und beobachten live, wie GitLab die Pipeline ausführt. Sie verstehen, was ein GitLab Runner ist und wie Shared Runner auf gitlab.com funktionieren. Am Ende haben Sie eine funktionierende Pipeline und wissen, wo der Einstieg in CI/CD liegt.

Kleine Tricks mit großer Wirkung. Sie beschleunigen Ihren Alltag mit:

• Keyboard Shortcuts für schnellere Navigation und Quick Actions in Issues und Merge Requests (z.B. /assign, /label, /close)
• der GitLab CLI (glab) für Aufgaben direkt aus dem Terminal
• aktuellen GitLab-Features wie der Merge Request Homepage für effizientere Reviews und Exact Code Search für die projektübergreifende Suche

Zum Abschluss erstellen Sie eine persönliche Checkliste: welche Git-Aliase, Shell-Konfigurationen und GitLab-Einstellungen Sie am ersten Tag zurück im Projekt umsetzen.