Conseils pour gérer beta iOS8 + dev en cours
LeChatNoir
Membre, Modérateur
Voilà , j'ai ma version en cours (en ligne) que je souhaite garder.
Mais il se peut que j'ai qques évolutions à y apporter dans l'été.
Et puis, il y a aussi l'adaptation à iOS8. Pour l'heure, mon projet compile et s'exécute sans trop de pb. J'ai juste des pb de tailles d'écran.
La question est donc la suivante... Comment je m'y prends ?
Pour gérer à la fois les évolutions sur ma version en cours et les spécificités iOS8...
Je pars direct avec Xcode 6 ? Je sais pas trop par quel bout m'y prendre....
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Oui, c'est ce que je dis. Mon appli s'adapte bien sauf qques fonctionalités. Va falloir que je m'y colle et ça serait plus facile directement dans Xcode 6 puisqu'on a un simulateur "Resizable iPhone"
T'as 2 solutions:
La solution Pro:
- Tu utilises Git avec 2 branches (1 branche Xcode 6 et 1 branche Xcode 5) et puis tu feras un merge en temps voulu.
La solution amateur dangereuse:
- Tu dupliques tes projets (1 pour Xcode 5 et 1 pour Xcode 6)
- Tu commences à bosser sur la version Xcode 6 pour les compatibilités d'écran.
- Mais si t'as des modifications mineures à faire dans la version Xcode 5, tu les fais, mais tu dois les copier au fur et à mesure dans la version Xcode 6.
Pour ma part, j'ai attaqué la version Xcode 6 car je sais que je n'aurais pas de grosse mise à jour à faire d'ici le lancement l'iOS 8 sur l'ancienne version. Mais je garde malgré tout la version Xcode 5 au chaud dès fois qu'il y ait une MAJ mineure à faire (quelques lignes de code).
Depuis le temps qu'on me parle de ce git, je vais m'y mettre...
Donc j'ai initialisé mon repo via un git init dans mon répertoire projet.
J'ai ajouté tous les fichiers/dossiers.
Et fait un commit initial.
Ca semble bien parti.
J'ai ma branche principale que je souhaite conserver intacte car elle reflète ma version online.
Mais dès que je lance Xcode 5, il détecte un changement dans le .xcworkspace (car je crois savoir que Xcode le maj à chaque lancement.
Et quand je vais lancer Xcode 6, il risque de changer aussi ce format et peut être qu'il n'y aura plus compatibilité ?
Ca signifie qu'avant d'ouvrir Xcode 6, il faut bien que je m'assure de basculer sur ma branche iOS8 ?
J'ai lu qu'il fallait ignorer certains fichiers.
J'ai donc créer un .gitignore dans mon répertoire.
Tel que :
# Xcode
.DS_Store
build/
*.pbxuser
!default.pbxuser
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3
*.xcworkspace
!default.xcworkspace
xcuserdata
profile
*.moved-aside
DerivedData
.idea/
# Pods - for those of you who use CocoaPods
Pods
Concernant l'exclusion du dossier Pods ça se discute y'a 2 écoles celles qui le commit et celles qui l'excluent. Les 2 se valent (y'a un article sur le sujet dans les Guides sur les pour et les contres)
Merci !
Si tu exclue le fichier "Pods" (et donc qu'il ne sera pas commité dans ton repo GIT)
[+] Ca fait moins de données à transiter sur le réseau quand tu fais un push ou un pull et utilise moins ton espace de stockage sur le serveur.
En même temps, si tu n'utilises GIT qu'en local et n'as pas du tout de serveur (tu ne pousses pas ton code sur GitHub ou BitBucket ou autre), tu t'en fous un peu.
[-] Par contre, à chaque fois que tu fais un "git pull" ou "git clone", il faut absolument faire un "pod install" ! (du moins surtout si le Podfile.lock a changé)
Et c'est le gros point noir, tu as vite fait d'oublier de faire ce "pod install" pour être sûr d'avoir les mêmes Pods que ceux utilisés par celui qui a fait le dernier commit.
Là encore si tu n'utilises ton repo GIT qu'en local et que sur une seule et unique machine, tu t'en fous un peu... mais si un jour tu décides de développer un peu sur ton Mac perso et un peu sur ton Mac de boulot, tu auras ton code à 2 endroits (que tu vas synchronser à coup de "git push" et "git pull" donc) et là il faudra penser au "pod install" après chaque "git pull"...
[-] Si jamais (c'est très rare, mais sur un projet long terme c'est un argument qui peut jouer) il se trouve qu'un Pod disparait (repo supprimé de GitHub par son auteur, etc), tu ne pourras donc plus faire un "pod install" pour récupérer ce pod, donc tu risques d'être bloqué
---
Si tu commit le fichier "Pods" (et donc que tu ne l'exclues pas dans .gitignore)
[-] Ca fait + de fichiers à transiter quand tu fais un git push ou un git pull
En même temps, on change pas les Pods utilisés dans un projet tous les 4 matins, donc en général la première fois qu'on fais un "pod install" et que ça les installe ça fait pas mal de fichiers à commiter... mais lors des push suivants y'a des chances qu'ils n'aient pas bougés et donc que ça n'ai rien de + à envoyer, donc bon...
[+] Mais il n'y a plus de risque de ne plus être synchro entre 2 machines/devs. Pas besoin de faire un "pod install" après chaque "git pull" pour être sûr que les Pods utilisés sont synchros entre tous les devs/machines, le "git pull" rameneant aussi le dossier "Pods".
[+] Et si un pod disparait un jour de GitHub, c'est pas grave, tu pourras toujours l'utiliser puisque tu auras commité le dossier Pods et auras donc gardé son code dans le GIT de ton projet.