DE
RU
EN
ES
ZH
FR
PT
AR
HI
Git-Workflow für Swift-Entwickler: Wie man nicht durchdreht und die Produktion nicht kaputt macht
Gib es ehrlich zu: Wie oft hast du einen Commit mit der Nachricht „fix“ oder „Änderungen“ in einem gemeinsamen Branch gesehen? Und wie oft hat ein Merge-Konflikt eine Stunde deines Lebens gekostet, weil jemand vergessen hat, vor dem Commit einen Pull zu machen? Wenn du ein Swift-Entwickler bist, der im Team arbeitet – vom Hobbyprojekt bis zur großen App wie „Tinkoff“ oder „Yandex.Maps“ – wirst du früher oder später mit Chaos in Git konfrontiert.
Die gute Nachricht: Ein richtiger Git-Workflow für Swift-Entwickler verwandelt das Repository von einem Schlachtfeld in ein geordnetes System. In diesem Artikel schauen wir uns an, welche Ansätze für iOS- und macOS-Projekte wirklich funktionieren, wie man Code Review ohne Schmerz einrichtet und warum CI/CD von Anfang an in deinen Prozess integriert sein sollte.
Los geht's!
1. Warum der Standard-Git-Workflow bei Swift oft scheitert
Swift-Projekte haben ihre Eigenheiten: Xcode-Projekte, Storyboards (oder SwiftUI), Podfile/SPM-Abhängigkeiten sowie binäre Assets (Bilder, Schriftarten). Während in einem normalen Webprojekt ein Merge-Konflikt in 30 Sekunden gelöst ist, kann er in iOS aufgrund von .xcodeproj oder .xcworkspace eine halbe Stunde dauern.
Die Hauptprobleme, die ein durchdachter Git-Workflow für Swift-Entwickler löst:
- Konflikte in .xcodeproj – wenn zwei Entwickler gleichzeitig Dateien hinzufügen;
- Unaufgeräumte Commit-Historie – „WIP“, „Änderungen“, „noch mehr Änderungen“;
- Fehlendes Code Review – Bugs, die in main landen und den Build zerstören;
- Kaputtes CI – Tests laufen nicht durch, und niemand bemerkt es bis zum Release.
2. Git Flow vs. GitHub Flow: Was für ein Swift-Projekt wählen?
Der klassische Git Flow (Branches develop, release, hotfix, feature) ist ein mächtiger, aber schwerfälliger Ansatz. Er ist ideal für große Projekte mit klaren Release-Zyklen, z. B. wenn du eine Banking-App mit den Versionen 1.0, 1.1, 2.0 und strengem QA entwickelst.
Auf der anderen Seite ist GitHub Flow (alle Änderungen über Feature-Branches und Pull Requests in main) eine leichte Variante für Startups und Teams, die täglich deployen. Für Swift-Projekte funktioniert er auch, aber mit Einschränkungen: Wenn du Storyboards oder XIBs hast, muss der Merge in main so sauber wie möglich sein.
Wann Git Flow in Swift verwenden
- Große Enterprise-Projekte mit langen Release-Zyklen (z. B. Banking, Telemedizin);
- Mehrere parallele Versionen (v1.0 im Support, v2.0 in Entwicklung);
- Strenge Anforderungen an die Stabilität des main-Branches.
Wann GitHub Flow in Swift verwenden
- Startups und mittlere Projekte mit schnellem Deployment;
- Teams bis zu 10 Personen;
- Projekte mit SwiftUI (weniger Konflikte in Referenzen).
Ich persönlich empfehle einen Hybriden: Git Flow mit einem vereinfachten develop-Branch – das ist die ideale Balance für Swift-Projekte mittlerer Komplexität.
3. Einrichtung eines Feature-Branches: Regeln, die Nerven schonen
Jede neue Funktion ist ein eigener Branch von develop (oder main, wenn du GitHub Flow verwendest). Hier ist eine einfache Vorlage, die ich in meinen Projekten verwende:
git checkout developgit pull --rebase origin developgit checkout -b feature/SPT-123-login-screenWichtig: Mache immer einen Rebase, bevor du einen Branch erstellst, um keine alten Commits mitzuschleppen. Und vergiss nicht die Präfixe: feature/, bugfix/, hotfix/, release/. Das vereinfacht die Suche in der Historie.
Wie oft mit develop synchronisieren
Mache einmal täglich oder vor einem Commit einen Rebase. Das minimiert Konflikte. Der Befehl:
git checkout feature/SPT-123-login-screengit rebase developWenn Konflikte unvermeidbar sind (z. B. wegen .xcodeproj), verwende git mergetool
Blogs
Buchempfehlungen
Lesen Sie auch
