Git im Gruppenprojekt: Ständig Merge-Konflikte – wie arbeitet man mit Branches eigentlich richtig?

Klassiker. 😄 Die gute Nachricht: Mit einem einfachen Feature-Branch-Workflow sind 90 % eurer Probleme weg.

1. main ist heilig: Da committet niemand direkt. In GitHub/GitLab kann man den Branch schützen, dann geht es technisch gar nicht mehr.
2. Pro Aufgabe ein Branch, nicht pro Person: z. B. feature/login, feature/warenkorb. Der Branch lebt nur so lange, bis die Aufgabe fertig ist – idealerweise ein paar Tage, nicht Wochen.
3. Vor dem Start immer den aktuellen Stand holen, also main pullen und davon abzweigen.
4. Fertig → Pull Request / Merge Request. Einer aus dem Team schaut drüber, dann wird in main gemergt.
5. Kleine Commits, oft integrieren. Je länger ein Branch weg ist, desto größer werden die Konflikte. Das ist der eigentliche Hebel.

Zu dem „einfach meine Version genommen“: Das passiert, wenn man einen Konflikt nicht liest, sondern wegklickt. Git überschreibt nicht von selbst, es zeigt dir beide Versionen an der Konfliktstelle markiert an. Der Konflikt muss inhaltlich gelöst werden – im Zweifel mit der Person zusammen, die die andere Änderung gemacht hat.

Gute Nachricht übrigens: Die überschriebene Arbeit ist sehr wahrscheinlich nicht weg. Solange die Commits existierten, findet ihr sie über git reflog bzw. in der History und könnt sie zurückholen.

Zu Merge vs. Rebase, weil das im Skript meistens verwirrend erklärt ist:

• Merge führt zwei Entwicklungsstränge zusammen und erzeugt dafür einen eigenen Merge-Commit. Die History zeigt ehrlich, dass parallel gearbeitet wurde. Nichts wird umgeschrieben.
• Rebase nimmt deine Commits und setzt sie so auf den aktuellen Stand von main, als hättest du erst jetzt angefangen. Ergebnis: eine lineare, aufgeräumte History. Dafür werden deine Commits neu geschrieben (neue Hashes).

Daraus folgt die eine Regel, die man sich merken muss: Niemals Commits rebasen, die andere schon gepullt haben. Also: Rebase nur auf deinem eigenen, noch privaten Feature-Branch, um ihn vor dem Pull Request auf den neuesten main-Stand zu bringen. Alles, was geteilt ist → Merge.

Für euer Uniprojekt würde ich ehrlich sagen: Nehmt einfach Merge, das ist fehlertoleranter. Rebase ist Kosmetik für die History, kein Muss.

Und noch ein unterschätzter Konfliktgrund in gemischten Teams: Zeilenenden und Autoformatierung. Wenn einer auf Windows (CRLF) und einer auf Mac/Linux (LF) arbeitet oder jeder einen anderen Formatter nutzt, ändert sich scheinbar jede Zeile einer Datei – und schon kollidiert alles. Legt eine .gitattributes und eine gemeinsame Formatter-Konfiguration ins Repo, dann ist Ruhe.

Aus meinem eigenen Gruppenprojekt letztes Semester noch der organisatorische Teil, der bei uns mehr gebracht hat als jeder Git-Befehl:

• Aufgaben so schneiden, dass sich Dateien wenig überschneiden. Wenn zwei Leute gleichzeitig dieselbe zentrale Datei umbauen, hilft auch der beste Workflow nicht. Kurze Absprache im Board („ich fasse gerade die Routing-Datei an“) spart viel Ärger.
• Ein kleines Kanban-Board (reicht schon das in GitHub/GitLab eingebaute) mit einer Karte pro Branch. Dann sieht jeder, was gerade offen ist.
• Eine .gitignore von Anfang an, damit keine IDE-Ordner, Build-Ergebnisse oder lokale Konfigdateien im Repo landen – die erzeugen sonst ständig sinnlose Konflikte.
• Kurz vor der Abgabe keine großen Umbauten mehr, nur noch Bugfixes.

Und falls ihr das in der Dokumentation beschreiben müsst: Genau diese Begründungen („warum Feature-Branches, warum geschützter main, warum Review“) wollen die Prüfer meistens lesen, nicht die Befehle. 👍