Git-Workflow für Java-Entwickler: Wie man bei Pull-Requests nicht verrückt wird

Git-Workflow für Java-Entwickler: Wenn "einfach committen" nicht mehr funktioniert

Seien wir ehrlich: Jeder Java-Entwickler war mindestens einmal in der Situation, dass sein Projekt nach einem fehlgeschlagenen Merge nicht mehr kompilierte und Kollegen im Chat schrieben: "Wer hat die pom.xml angefasst?". Wenn Sie sich wiedererkennen – dieser Artikel ist für Sie.

Git ist nicht nur ein Versionskontrollsystem. In der Java-Welt, in der Projekte jahrelang leben und Abhängigkeiten über Maven oder Gradle verwaltet werden, wird ein korrekter Git-Workflow zur Überlebensfrage. Heute schauen wir uns an, wie man die Arbeit mit Git so organisiert, dass Code-Reviews schnell ablaufen und Konflikte nicht zum Kopfzerbrechen werden.

Wir werden Ihnen nicht die Befehle git init oder git commit beibringen. Stattdessen konzentrieren wir uns darauf, wie genau Java-Teams ihre Prozesse aufbauen: von der Wahl des Branching-Modells bis zur Einrichtung von CI/CD-Pipelines.

Warum Java-Projekte einen besonderen Ansatz für Git erfordern?

Java ist eine Sprache mit einem reichhaltigen Ökosystem. In einem typischen Enterprise-Projekt finden Sie:

• Mehrschichtige Architektur (Controller → Service → Repository);
• Build über Maven oder Gradle mit Dutzenden von Abhängigkeiten;
• Lange Tests (Integrationstests, Modultests, E2E-Tests);
• Strenge Anforderungen an die Versionskompatibilität.

Das bedeutet, dass der Git-Workflow für Java-Entwickler nicht nur den Code, sondern auch die Build-Infrastruktur berücksichtigen muss. Ein Fehler in der pom.xml kann das gesamte Projekt zerstören, und ein Konflikt in der application.properties kann den Deployment stoppen.

Grundlegende Branching-Modelle: Was soll das Java-Team wählen?

GitFlow – der Klassiker für Enterprise Java

GitFlow ist der De-facto-Standard für große Java-Projekte. Es bietet eine strenge Branch-Struktur:

• main – nur production-ready Code;
• develop – Integrationsbranch für die Entwicklung;
• feature/ – für neue Features;
• release/ – zur Vorbereitung eines Releases;
• hotfix/ – für dringende Fehlerbehebungen.

Beispiel: Sie schreiben einen neuen REST-Endpunkt mit Spring Boot. Sie erstellen den Branch feature/add-user-endpoint von develop, arbeiten daran und mergen ihn dann zurück. Wenn genügend Features für ein Release zusammenkommen, wird release/v2.1.0 erstellt, in dem Bugs ohne Hinzufügen neuer Funktionalität behoben werden.

Vorteile: klare Isolierung, verständliche Historie, geeignet für Versionierung.
Nachteile: Komplexität, viele Merges, unpraktisch für CI/CD.

GitHub Flow – für schnelle Iterationen

Wenn Ihr Java-Team Microservices verwendet oder agil arbeitet, ist GitHub Flow möglicherweise einfacher. Hier gibt es nur einen Hauptbranch – main. Alle Änderungen erfolgen über Pull Requests.

So funktioniert es:

1. Erstellen Sie einen Branch von main;
2. Schreiben Sie Code und Tests;
3. Eröffnen Sie einen PR, durchlaufen Sie ein Code-Review;
4. CI/CD führt den Build und die Tests durch;
5. Nach dem Merge wird der Branch gelöscht.

Für ein Java-Projekt bedeutet dies, dass jeder PR klein genug sein sollte, damit CI alle Tests in angemessener Zeit ausführen kann.

Trunk-based Development – für die Mutigen

Hierbei arbeiten alle Entwickler in einem Branch (Trunk), und Features werden hinter Feature-Flags versteckt. Geeignet für reife Teams mit hervorragender Testabdeckung. In Java wird dies oft zusammen mit Spring Cloud Config verwendet, um Features dynamisch ein- und auszuschalten.

Merge vs. Rebase: Die ewige Debatte der Java-Entwickler

In der Java-Welt haben merge und rebase unterschiedliche Philosophien. Lassen Sie es uns anhand eines Beispiels betrachten.

Merge – Historie bewahren

Wenn Sie an einem großen Modul mit mehreren Entwicklern arbeiten, erzeugt Merge einen Merge-Commit, der visuell zeigt, woher die Änderungen kamen. Dies ist praktisch zum Verständnis