Git und GitLab lernen: sauber versionieren

„final.zip“, „final_final_neu.zip“, „wirklich_final_jetzt.zip“: Wenn deine Projektordner so aussehen, fehlt dir eine saubere Versionskontrolle. Git und GitLab lösen genau dieses Problem, und zwar nicht nur für riesige Open-Source-Projekte, sondern für jedes ernst gemeinte Softwareprojekt.

Warum Versionskontrolle Pflicht ist

Versionskontrolle ist keine Kür, sondern Grundausstattung. Ohne Git verlierst du schnell den Überblick:

• Du weißt nicht mehr, welche Version beim Kunden läuft.
• Bugfixes lassen sich nicht sauber nachvollziehen.
• Parallele Arbeiten im Team treten sich gegenseitig auf die Füße.
• Rollbacks sind Glückssache und kosten im Zweifel Stunden.

Mit Git und einer Plattform wie GitLab bekommst du:

• eine lückenlose Historie aller Änderungen,
• reproduzierbare Stände, jederzeit wiederherstellbar,
• saubere Zusammenarbeit über Branches und Merge Requests,
• automatisierte Tests und Builds direkt aus dem Repository.

Selbst wenn du in einem kleinen Team in München an einer internen Anwendung schraubst: Ohne Versionskontrolle wirst du bei der ersten größeren Änderung ins Stolpern kommen.

Git-Grundlagen: Commits als kleinste Einheit

Die Basis von Git sind Commits. Ein Commit ist ein Schnappschuss deines Projekts zu einem bestimmten Zeitpunkt, inklusive Kommentar.

Typischer Ablauf:

git add src/service.js
git commit -m "Fügt Validierung für E-Mail-Adressen hinzu"

Worauf es ankommt:

• Kleine, sinnvolle Schritte Ein Commit sollte eine zusammenhängende Änderung enthalten, zum Beispiel „Login-Validierung ergänzt“ oder „Logging überarbeitet“. Kein „alles von heute“.

• Aussagekräftige Commit-Messages Schreib so, dass du in drei Monaten noch verstehst, was passiert ist. Besser: „Behebt NullPointerException in UserService bei leerer Session“ Schlechter: „Fix“, „Änderung“, „Update“.

• Ein Thema pro Commit Kein Refactoring, Bugfix und neue Funktion in einem Commit. Trenne das, sonst ist Debugging später ein Graus.

• Regelmäßig committen Wenn du abends vor einem Berg nicht committeter Änderungen stehst, ist das ein Warnsignal. Lieber häufiger kleine Commits als seltene Monster.

Branches: parallele Welten für Features und Fixes

Branches sind parallele Entwicklungsstränge. Der Standard-Branch heißt meist „main“ oder „master“. Du erstellst Branches für neue Features, Bugfixes oder Experimente:

git checkout -b feature/user-profile

Typische Branch-Typen in Projekten:

• Feature-Branches: feature/login-2fa
• Bugfix-Branches: bugfix/order-overflow
• Release-Branches: release/1.4.0
• Hotfix-Branches: hotfix/critical-logging

Vorteile:

• Du hältst den Hauptbranch stabil und deploybar.
• Du kannst Experimente fahren, ohne das Team zu blockieren.
• Merge Requests in GitLab lassen sich Branch-basiert sauber aufsetzen.

Praxis-Tipp: Lass Branch-Namen die Aufgabe beschreiben und ggf. eine Ticketnummer enthalten, zum Beispiel feature/1234-report-export. Das erleichtert die Zuordnung zu Ticketsystemen wie Jira oder YouTrack.

Merge und Rebase: Änderungen zusammenführen

Früher oder später müssen Branches wieder zusammenkommen. Dafür gibt es in Git zwei zentrale Werkzeuge: Merge und Rebase.

Merge: Historie bleibt verzweigt

Merge erstellt einen neuen Commit, der zwei Entwicklungsstränge zusammenführt.

Beispiel:

git checkout main
git merge feature/user-profile

Ergebnis: Die Historie zeigt einen Merge-Commit, die Verzweigung bleibt sichtbar. Das ist robust und besonders im Teambetrieb oft die sicherste Variante.

Vorteile:

• Historie bleibt nachvollziehbar, du siehst, wann welcher Branch gemergt wurde.
• Konflikte sind klar einem Merge zugeordnet.
• Geeignet für gemeinsame Branches, an denen mehrere Personen arbeiten.

Rebase: Historie wird umgeschrieben

Rebase setzt deine Commits auf einen neuen Stand, als hättest du auf diesem Stand entwickelt:

git checkout feature/user-profile
git rebase main

Git „spult“ deine Commits auf den aktuellen Stand von „main“ vor. Das ergibt eine lineare Historie, kann aber Konflikte über mehrere Commits hinweg erzeugen.

Wichtige Regeln:

• Rebase nur auf eigenen, noch nicht gepushten Branches.
• Niemals öffentlich geteilte Branches rebaseden, sonst bekommen Kolleginnen und Kollegen Probleme beim Pullen.

Viele Teams nutzen eine Kombination:

• Auf Feature-Branches: Rebase auf den aktuellen „main“, um eine saubere Historie zu behalten.
• Beim Zusammenführen in „main“: Merge über einen Merge Request in GitLab.

Remotes: Lokal entwickeln, zentral teilen

Git unterscheidet zwischen lokalem Repository und Remotes. GitLab ist ein typischer Remote, auf den du dein Repository hochlädst.

Einbindung eines GitLab-Repos:

git remote add origin git@gitlab.com:dein-namespace/dein-projekt.git
git push -u origin main

Wichtige Befehle:

• git push: Lokale Commits zum Remote senden.
• git pull: Änderungen vom Remote holen und mit deinem Stand kombinieren.
• git fetch: Nur neue Commits holen, ohne sie direkt zu mergen.

Gute Praxis:

• Vor dem Start in den Tag: git pull auf deinem Branch.
• Vor einem Push: Sicherstellen, dass du den aktuellen Stand des Remote-Branches hast, um Konflikte früh zu sehen.

GitLab im Alltag: Repos, Merge Requests, Rechte

GitLab ist mehr als nur ein Git-Server. Zentral sind für dich:

• Repository-Verwaltung Projekte anlegen, Zugriffsrechte setzen, Protected Branches definieren (zum Beispiel: „main“ nur via Merge Request veränderbar).

• Merge Requests (MRs) GitLabs Variante der Code-Reviews. Du stellst deinen Branch zur Diskussion, bevor er in „main“ landet.

• Issue-Tracking Aufgaben, Bugs, Features direkt im Projekt verwalten und mit Commits/MRs verknüpfen.

• CI/CD Automatisierte Pipelines für Tests, Builds und Deployments.

In vielen Unternehmen, auch in München, ist GitLab inzwischen das zentrale Entwicklungswerkzeug. Wer Git und GitLab beherrscht, kann sich in praktisch jedes moderne Dev-Team einfügen. Aktuelle Termine und passende Kurse findest du bei cmt.de.

Merge Requests: Code-Review statt „mal schnell pushen“

Ein Merge Request bildet den Workflow vom Feature-Branch zurück in den Hauptbranch ab.

Typischer Ablauf:

1. Du erstellst einen Branch, z. B. feature/invoice-pdf.
2. Du arbeitest in sinnvollen Commits.
3. Du pushst den Branch nach GitLab.
4. Du erstellst einen Merge Request in GitLab.
5. Kolleginnen und Kollegen reviewen deinen Code, kommentieren, fordern Anpassungen.
6. Nach Freigabe wird gemergt, oft automatisch via GitLab.

Worauf du bei MRs achten solltest:

• Kleiner Umfang 50 Zeilen Änderung lassen sich gut reviewen, 1500 Zeilen nicht. Lieber mehrere kleine MRs.
• Gute Beschreibung Was ist das Ziel, welche Tickets sind betroffen, was wurde nicht gemacht?
• Verlinkung zu Issues Zum Beispiel „Closes #1234“, damit GitLab das Issue beim Merge automatisch schließt.
• Checks nutzen GitLab kann Tests und Linting automatisch ausführen und das Ergebnis im MR anzeigen.

So wird der Code-Review-Prozess zu einem ganz normalen Teil des Arbeitstages und nicht zu einem lästigen Extra.

CI in GitLab: Automatisieren, was nervt und Fehler verursacht

CI (Continuous Integration) bedeutet: Änderungen werden automatisch gebaut und getestet, sobald sie im Repository landen. In GitLab steuerst du das über eine Datei .gitlab-ci.yml im Projekt.

Ein sehr einfaches Beispiel für ein Node.js-Projekt:

stages:
 - test

test:
 stage: test
 image: node:20
 script:
 - npm ci
 - npm test

Was passiert:

• Bei jedem Push schaut GitLab in .gitlab-ci.yml.
• Es startet einen Job im Stage „test“.
• Der Job führt npm ci und npm test in einem Container mit Node 20 aus.
• Das Ergebnis (grün/rot) siehst du im MR und im Projekt.

Typische CI-Aufgaben:

• Unit-Tests und Integrationstests ausführen.
• Linter und Formatter laufen lassen.
• Artefakte bauen, z. B. Docker-Images, JARs, Frontend-Bundles.
• Sicherheits-Scans und Dependency-Checks.

Viele Teams gehen noch weiter und nutzen GitLab auch für CD (Continuous Delivery/Deployment), etwa um nach einem Merge in „main“ automatisch auf eine Staging-Umgebung zu deployen. Wichtig ist: CI fängt Fehler früh ab, bevor sie in Produktion landen. Du bekommst direktes Feedback, ob deine Änderung die Build-Pipeline bricht.

Typische Stolperfallen und wie du sie vermeidest

Gerade am Anfang stolpert man mit Git und GitLab über ähnliche Probleme. Ein paar Klassiker:

• „Ich habe auf main entwickelt“ Lösung: Sofort einen Branch erstellen, Änderungen dorthin verschieben, „main“ wieder in einen sauberen Zustand bringen. Gewöhne dir an, vor jeder Änderung zu prüfen, auf welchem Branch du bist.

• Monster-Commits und Monster-MRs Lösung: Disziplin. Kleinere Aufgaben schneiden, häufiger committen, früher Merge Requests erstellen.

• Merge-Konflikte im letzten Moment Lösung: Feature-Branch regelmäßig mit „main“ abgleichen, etwa via git fetch und git rebase oder git merge. Konflikte früh lösen, nicht am Release-Tag.

• „Ich habe aus Versehen harte Änderungen gepusht“ Lösung: git revert statt git reset --hard, wenn der Commit schon im Remote ist. Revert erzeugt einen neuen Commit, der Änderungen rückgängig macht, ohne die Historie zu zerstören.

• CI ist rot, aber „läuft bei mir“ Lösung: CI-Umgebung nachbilden: gleiche Node-/Java-/Python-Version, gleiche Build-Skripte wie in .gitlab-ci.yml. Keine Magie, nur reproduzierbare Umgebungen.

Wie du Git und GitLab sinnvoll lernst

Du musst nicht jede Git-Option auswendig können, wichtig ist ein sicherer Umgang mit den Kernkonzepten:

1. Täglich nutzen Auch für kleine Nebenprojekte oder Skripte. Versionskontrolle wird Routine, wenn du sie ständig verwendest.

2. CLI verstehen, GUI ergänzend nutzen Tools wie GitKraken oder die Git-Integration in IDEs sind hilfreich. Aber die grundlegenden Befehle auf der Kommandozeile zu kennen, macht dich unabhängiger.

3. Konflikte bewusst üben Klingt unattraktiv, hilft aber: Erzeuge in einem Testrepo bewusst Konflikte und löse sie. Dann bist du im Ernstfall entspannter.

4. GitLab-Features nach und nach entdecken Starte mit Repository und Merge Requests. Baue dann CI ein. Später kannst du Issues, Boards oder Packages ausprobieren.

Wenn du diese Schritte gehst, wird Git von einem „muss ich halt benutzen“ zu einem Werkzeug, das dir aktiv Arbeit abnimmt und dein Team produktiver macht. Sauberes Versionieren ist dann keine lästige Pflicht mehr, sondern die Basis für entspannte, nachvollziehbare Softwareentwicklung.