FR
RU
EN
ES
ZH
DE
PT
AR
HI
Git workflow pour les développeurs Swift : comment ne pas perdre la tête et ne pas casser la production
Avoue honnêtement : combien de fois as-tu vu un commit avec le message « fix » ou « corrections » dans la branche commune ? Et combien de fois un conflit de merge a-t-il pris une heure de ta vie parce que quelqu'un a oublié de faire un pull avant le commit ? Si tu es développeur Swift travaillant en équipe — d'un projet hobby à une application majeure de type « Tinkoff » ou « Yandex.Maps » — tôt ou tard, tu feras face au chaos dans Git.
Bonne nouvelle : un git workflow pour les développeurs Swift correct transforme le dépôt d'un champ de bataille en un système structuré. Dans cet article, nous allons voir quelles approches fonctionnent réellement pour les projets iOS et macOS, comment configurer une code review sans douleur et pourquoi le CI/CD doit être intégré à ton processus dès le premier jour.
C'est parti !
1. Pourquoi le git workflow standard se casse souvent avec Swift
Les projets Swift ont leurs spécificités : projets Xcode, storyboards (ou SwiftUI), dépendances Podfile / SPM, ainsi que des assets binaires (images, polices). Si dans un projet web classique un conflit de merge se résout en 30 secondes, dans iOS il peut prendre une demi-heure à cause de .xcodeproj ou .xcworkspace.
Les principaux problèmes qu'un git workflow pour les développeurs Swift bien conçu résout :
- Conflits dans .xcodeproj — lors de l'ajout de fichiers par deux développeurs simultanément ;
- Historique de commits sale — « WIP », « corrections », « encore des corrections » ;
- Absence de code review — des bugs qui arrivent dans main et cassent la build ;
- CI cassé — les tests échouent, mais personne ne le remarque avant la release.
2. Git Flow vs GitHub Flow : que choisir pour un projet Swift ?
Le classique Git Flow (branches develop, release, hotfix, feature) est une approche puissante mais lourde. Il est idéal pour les grands projets avec des cycles de release clairs, par exemple lorsque tu développes une application bancaire avec des versions 1.0, 1.1, 2.0 et une QA stricte.
D'un autre côté, GitHub Flow (tous les changements via des feature branches et des Pull Request vers main) est une option légère pour les startups et les équipes qui déploient chaque jour. Pour les projets Swift, cela fonctionne aussi, mais avec des réserves : si tu as des storyboards ou des XIB, le merge dans main doit être le plus propre possible.
Quand utiliser Git Flow dans Swift
- Grands projets enterprise avec des cycles de release longs (ex. : banque, télémédecine) ;
- Plusieurs versions parallèles (v1.0 en support, v2.0 en développement) ;
- Exigences strictes de stabilité de la branche main.
Quand utiliser GitHub Flow dans Swift
- Startups et projets moyens avec un déploiement rapide ;
- Équipes jusqu'à 10 personnes ;
- Projets en SwiftUI (moins de conflits dans les références).
Personnellement, je recommande un hybride : Git Flow avec une branche develop simplifiée — c'est l'équilibre idéal pour les projets Swift de complexité moyenne.
3. Configuration d'une feature branch : des règles qui sauveront tes nerfs
Chaque nouvelle fonctionnalité est une branche séparée à partir de develop (ou main, si tu utilises GitHub Flow). Voici un modèle simple que j'utilise dans mes projets :
git checkout developgit pull --rebase origin developgit checkout -b feature/SPT-123-login-screenImportant : fais toujours un rebase avant de créer une branche, pour ne pas traîner de vieux commits. Et n'oublie pas les préfixes : feature/, bugfix/, hotfix/, release/. Cela simplifie la recherche dans l'historique.
À quelle fréquence se synchroniser avec develop
Fais un rebase une fois par jour ou avant un commit. Cela minimise les conflits. La commande :
git checkout feature/SPT-123-login-screengit rebase developSi les conflits sont inévitables (par exemple, à cause de .xcodeproj), utilise git mergetool
Blogs
Book Recommendations
Lire aussi
