Je fais du développement iOS depuis quelques mois maintenant et je viens d'apprendre la prometteuse bibliothèque CocoaPods pour la gestion des dépendances.

Je l'ai essayé sur un projet personnel: j'ai ajouté une dépendance à Kiwi à mon Podfile, j'ai couru pod install CocoaPodsTest.xcodeprojet le tour est joué , ça a très bien fonctionné.

La seule chose que je me demande est la suivante: que dois-je archiver et que dois-je ignorer pour le contrôle de version? Il semble évident que je souhaite archiver le Podfile lui-même, et probablement le fichier .xcworkspace également; mais est-ce que j'ignore le répertoire Pods /? Y a-t-il d'autres fichiers qui seront générés ultérieurement (lorsque j'ajouterai d'autres dépendances) que je devrais également ajouter à mon .gitignore?

Personnellement, je ne vérifie pas le répertoire et le contenu des pods. Je ne peux pas dire que j'ai passé beaucoup de temps à considérer les implications mais mon raisonnement est quelque chose comme:

Le Podfile fait référence à une balise ou à un commit spécifique de chaque dépendance afin que les Pods eux-mêmes puissent être générés à partir du podfile, ergo, ils ressemblent plus à un produit de construction intermédiaire qu'à une source et, par conséquent, n'ont pas besoin de contrôle de version dans mon projet.

Je valide mon répertoire Pods. Je ne suis pas d'accord pour dire que le répertoire Pods est un artefact de construction. En fait, je dirais que ce n'est certainement pas le cas. Cela fait partie de la source de votre application: elle ne se construira pas sans!

Il est plus facile de considérer CocoaPods comme un outil de développement plutôt que comme un outil de construction. Il ne construit pas votre projet, il clone et installe simplement vos dépendances pour vous. Il ne devrait pas être nécessaire d'installer CocoaPods pour pouvoir simplement construire votre projet.

En faisant de CocoaPods une dépendance de votre build, vous devez maintenant vous assurer qu'il est disponible partout où vous pourriez avoir besoin de construire votre projet ... un administrateur d'équipe en a besoin, votre serveur CI en a besoin. En règle générale, vous devez toujours être en mesure de cloner votre référentiel source et de le construire sans effort supplémentaire.

Ne pas engager votre répertoire Pods crée également un énorme mal de tête si vous changez fréquemment de branche. Vous devez maintenant exécuter pod install chaque fois que vous changez de branche pour vous assurer que vos dépendances sont correctes. Cela peut être moins compliqué à mesure que vos dépendances se stabilisent, mais au début d'un projet, il s'agit d'un énorme puits de temps.

Alors, qu'est-ce que j'ignore? Rien. Podfile, le fichier de verrouillage et le répertoire Pods sont tous validés. Croyez-moi, cela vous évitera beaucoup de tracas. Quels sont les inconvénients? Un dépôt légèrement plus grand? Pas la fin du monde.

Je recommande d'utiliser le gitignore Objective-C du GitHub . En détail, les meilleures pratiques sont:

• Le Podfile doit toujours être sous contrôle de source.
• Le Podfile.lock doit toujours être sous contrôle de source.
• L'espace de travail généré par CocoaPods doit être gardé sous contrôle de source.
• Tout pod référencé avec l' :pathoption doit être gardé sous contrôle de source.
• Le ./Podsdossier peut être gardé sous contrôle de source.

Pour plus d'informations, vous pouvez vous référer au guide officiel .

source: Je suis membre de l'équipe principale de CocoaPods, comme @alloy

Bien que le dossier Pods soit un artefact de génération, vous pouvez prendre en compte des raisons pour décider de le garder sous contrôle de code source:

• CocoaPods n'est pas un gestionnaire de paquets, donc la source d'origine de la bibliothèque pourrait être supprimée à l'avenir par l'auteur.
• Si le dossier Pods est inclus dans le contrôle de code source, il n'est pas nécessaire d'installer CocoaPods pour exécuter le projet car la vérification suffirait.
• CocoaPods est toujours en cours de réalisation et il existe des options qui ne mènent pas toujours au même résultat (par exemple :head, les :gitoptions et n'utilisent actuellement pas les validations stockées dans le Podfile.lock).
• Il y a moins de points d'échec si vous pouvez reprendre le travail sur un projet après une durée moyenne / longue.

Fichier .gitignore

Aucune réponse en fait n'offre un .gitignore, alors voici deux saveurs.

Vérification dans le répertoire Pods ( Avantages )

Git Xcode / iOS convivial ignorer, ignorer les fichiers système Mac OS, Xcode, les builds, d'autres référentiels et sauvegardes.

.gitignore:

# Mac OS X Finder
.DS_Store

# Private Keys
*.pem

# Xcode legacy
*.mode1
*.mode1v3
*.mode2v3
*.perspective
*.perspectivev3
*.pbxuser

# Xcode
xcuserdata/
project.xcworkspace/
DerivedData/

# build products
build/
*.[oa]

# repositories
.hg
.svn
CVS

# automatic backup files
*~.nib
*.swp
*~
*(Autosaved).rtfd/
Backup[ ]of[ ]*.pages/
Backup[ ]of[ ]*.key/
Backup[ ]of[ ]*.numbers/

Ignorer le répertoire Pods ( Avantages )

.gitignore: (ajouter à la liste précédente)

# Cocoapods
Pods/

Que vous archiviez ou non le répertoire Pods, Podfile et Podfile.lock doivent toujours être sous contrôle de version.

Si vous Podsn'êtes pas enregistré, vous Podfiledevriez probablement demander des numéros de version explicites pour chaque Cocoapod. Discussion Cocoapods.org ici .

Je travaille généralement sur des applications de clients. Dans ce cas, j'ajoute également le répertoire Pods au référentiel, pour m'assurer qu'à tout moment, n'importe quel développeur puisse effectuer une extraction, générer et exécuter.

S'il s'agissait de notre propre application, j'exclureais probablement le répertoire Pods jusqu'à ce que je ne travaille pas dessus pendant un certain temps.

En fait, je dois conclure que je ne suis peut-être pas la meilleure personne pour répondre à votre question, par rapport aux opinions des utilisateurs purs :) Je tweeterai à propos de cette question sur https://twitter.com/CocoaPodsOrg .

Je vérifie tout. ( Pods/etPodfile.lock .)

Je veux pouvoir cloner le référentiel et savoir que tout fonctionnera comme il l'a fait la dernière fois que j'ai utilisé l'application.

Je préfère vendre des choses plutôt que de risquer d'avoir des résultats différents qui pourraient être causés par une version différente de la gemme, ou par quelqu'un qui réécrit l'histoire dans le référentiel du pod, etc.

La réponse est donnée directement dans les documents Cocoapod. Vous pouvez consulter " http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control "

Que vous archiviez ou non votre dossier Pods dépend de vous, car les flux de travail varient d'un projet à l'autre. Nous vous recommandons de garder le répertoire Pods sous contrôle de source et de ne pas l'ajouter à votre .gitignore. Mais en fin de compte, cette décision vous appartient:

Avantages de la vérification dans le répertoire Pods

• Après le clonage du référentiel, le projet peut immédiatement être construit et exécuté, même sans avoir installé CocoaPods sur la machine. Il n'est pas nécessaire d'exécuter l'installation du pod et aucune connexion Internet n'est nécessaire.
• Les artefacts Pod (code / bibliothèques) sont toujours disponibles, même si la source d'un Pod (par exemple GitHub) devait baisser.
• Les artefacts Pod sont garantis identiques à ceux de l'installation d'origine après le clonage du dépôt.

Avantages d'ignorer le répertoire Pods

• Le dépôt de contrôle de source sera plus petit et prendra moins de place.

• Tant que les sources (par exemple GitHub) de tous les pods sont disponibles, CocoaPods est généralement capable de recréer la même installation. (Techniquement, il n'y a aucune garantie que l'exécution de l'installation du pod récupérera et recréera des artefacts identiques lorsque vous n'utilisez pas un SHA de validation dans le podfile. Cela est particulièrement vrai lorsque vous utilisez des fichiers zip dans le podfile.)

• Il n'y aura aucun conflit à gérer lors de l'exécution d'opérations de contrôle de source, telles que la fusion de branches avec différentes versions de pod.

Que vous archiviez ou non le répertoire Pods, Podfile et Podfile.lock doivent toujours être sous contrôle de version.

Je suis dans le camp des développeurs qui ne vérifient pas dans les bibliothèques, en supposant que nous avons une bonne copie disponible dans un autre endroit. Donc, dans mon .gitignore, j'inclus les lignes suivantes spécifiques aux CocoaPods:

Pods/
#Podfile.lock  # changed my mind on Podfile.lock

Ensuite, je m'assure que nous avons une copie des bibliothèques dans un endroit sûr. Plutôt que (mal) d'utiliser le référentiel de code d'un projet pour stocker les dépendances (compilées ou non), je pense que la meilleure façon de le faire est d'archiver les builds. Si vous utilisez un serveur CI pour vos builds (comme Jenkins), vous pouvez archiver de façon permanente toutes les builds importantes pour vous. Si vous faites toutes vos builds de production dans votre Xcode local, prenez l'habitude de prendre une archive de votre projet pour toutes les builds que vous devez conserver. Quelque chose comme: 1. Produit -> Archive

1. Distribuer ... Soumettre à l'App Store iOS / Enregistrer pour l'entreprise ou déploiement ad hoc / qu'avez-vous

2. Révélez votre dossier de projet dans le Finder

3. Clic droit et compresser "WwhatProject"

Cela fournit une image conforme à l'ensemble du projet, y compris les paramètres complets du projet et de l'espace de travail utilisés pour créer l'application ainsi que les distributions binaires (telles que Sparkle, les SDK propriétaires tels que TestFlight, etc.), qu'ils utilisent ou non CocoaPods.

Mise à jour: j'ai changé d'avis à ce sujet et maintenant je valide le Podfile.lockcontrôle de source. Cependant, je pense toujours que les pods eux-mêmes sont des artefacts de construction et doivent être gérés en tant que tels en dehors du contrôle des sources, via une autre méthode telle que votre serveur CI ou un processus d'archivage comme je le décris ci-dessus.

Je préfère engager le Podsrépertoire avec Podfileet Podfile.lockpour m'assurer que tout le monde dans mon équipe peut extraire la source à tout moment et qu'il n'a pas à s'inquiéter de quoi que ce soit ou faire des choses supplémentaires pour le faire fonctionner.

Cela aide également dans un scénario où vous avez corrigé un bogue dans l'un des pods ou modifié un comportement selon vos besoins, mais ces changements ne seront pas disponibles sur d'autres machines s'ils ne sont pas validés.

Et pour ignorer les répertoires inutiles:

xcuserdata/

Je dois dire que je suis un fan de la validation des pods dans le référentiel. Suivre un lien déjà mentionné vous donnera un bon fichier .gitignore pour récupérer vos projets Xcode pour iOS pour permettre les pods mais aussi pour vous les exclure facilement si vous le souhaitez: https://github.com/github/gitignore/ blob / master / Objective-C.gitignore

Mon raisonnement pour être un fan de l'ajout de pods au référentiel est pour une raison fondamentale que personne ne semble comprendre, que se passe-t-il si une bibliothèque dont notre projet dépend tellement est soudainement supprimée du Web?

• Peut-être que l'hôte décide qu'il ne veut plus garder son compte GitHub ouvert.
• Autre point également, que se passe-t-il si l'URL du référentiel change? Supposons que la personne qui sert le pod à partir de son compte GitHub décide de se représenter sous un autre nom - les URL de vos pods vont casser.
• Enfin un autre point. Dites si vous êtes un développeur comme moi qui fait beaucoup de codage lors d'un vol entre les pays. Je tire rapidement sur la branche «maître», fais une installation de pod sur cette branche, tout en étant assis à l'aéroport et je suis prêt pour le prochain vol de 8 heures. J'obtiens 3 heures de vol et je me rends compte que je dois passer à une autre succursale ... 'DOH' - informations Pod manquantes qui ne sont disponibles que sur la branche 'master'.

NB ... veuillez noter que la branche 'master' pour le développement est juste pour des exemples, évidemment les branches 'master' dans les systèmes de contrôle de version, doivent être maintenues propres et déployables / constructibles à tout moment

Je pense qu'à partir de ceux-ci, les instantanés dans vos référentiels de code sont certainement meilleurs que d'être strict sur la taille du référentiel. Et comme déjà mentionné, le fichier podfile.lock - bien que la version soit contrôlée vous donnera un bon historique de vos versions de pod.

À la fin de la journée, si vous avez un délai pressant, un budget serré, le temps est essentiel - nous devons être aussi ingénieux que possible et ne pas perdre de temps sur des idéologies strictes, et plutôt utiliser un ensemble d'outils pour travailler ensemble - pour rendre notre vie plus facile plus efficace.

À la fin dépend de vous l'approche que vous adoptez.

Voici ce qu'en pense Cocoapods:

Que vous archiviez ou non votre dossier Pods dépend de vous, car les flux de travail varient d'un projet à l'autre. Nous vous recommandons de garder le répertoire Pods sous contrôle de source et de ne pas l'ajouter à votre .gitignore. Mais en fin de compte, cette décision vous appartient.

Personnellement , je voudrais garder pods dehors, comme node_modules si j'utilisais Node ou bower_components si j'utilisais Bower . Cela s'applique à presque n'importe quel gestionnaire de dépendance, et c'est également la philosophie derrière les sous-modules git .

Cependant, il y a parfois que vous voudrez peut-être être vraiment sûr de l' état de l'art d'une certaine dépendance, de cette façon vous portez la dépendance au sein de votre projet. Bien sûr, il existe plusieurs inconvénients qui s'appliquent si vous le faites, mais les préoccupations ne s'appliquent pas seulement aux Cocoapods, elles s'appliquent à tout gestionnaire de dépendance là-bas.

Ci-dessous, il y a une bonne liste des avantages / inconvénients faite par l'équipe Cocoapods, et le texte complet de la citation mentionnée précédemment.

Équipe Cocoapods: Dois-je vérifier le répertoire Pods dans le contrôle de code source?

Cela dépend, personnellement:

Pourquoi les pods devraient faire partie du dépôt (sous contrôle de source) et ne devraient pas être ignorés

• La source est identique
• Vous pouvez le construire tout de suite tel quel (même sans les cocoapodes)
• Même si un pod est supprimé, nous avons toujours sa copie (Oui, cela peut arriver et c'est le cas. Dans un ancien projet où vous voulez juste un petit changement, vous auriez besoin d'implémenter une nouvelle bibliothèque pour pouvoir même construire).
• pods.xcodeprojles paramètres font également partie du contrôle de source. Cela signifie par exemple si vous avez le projet swift 4, mais que certains modules doivent êtreswift 3.2 car ils ne sont pas encore mis à jour, ces paramètres seront enregistrés. Sinon, celui qui a cloné le dépôt se retrouverait avec des erreurs.
• Vous pouvez toujours supprimer des pods du projet et l'exécuter pod install, l'inverse ne peut pas être fait.
• Même les auteurs des Cocoapods le recommandent.

Quelques inconvénients: référentiel plus grand, différences confuses (principalement pour les membres de l'équipe), potentiellement plus de conflits.

Pour moi, la plus grande préoccupation est la pérennisation de votre source. Si vous prévoyez de faire durer votre projet pendant un certain temps et que CocoaPods disparaît ou que la source de l'un des pods tombe en panne, vous n'avez pas de chance si vous essayez de construire à partir d'une archive.

Cela pourrait être atténué par des archivages périodiques complets de la source.

Vérifiez les pods.

Je pense que cela devrait être un principe de développement logiciel

• Toutes les versions doivent être reproductibles
• La seule façon de garantir la reproductibilité des builds est de contrôler toutes les dépendances; l'archivage de toutes les dépendances est donc indispensable.
• Un nouveau développeur à partir de zéro pourra vérifier votre projet et commencer à travailler.

Pourquoi?

CocoaPods ou toute autre bibliothèque externe pourrait changer, ce qui pourrait casser les choses. Ou ils pourraient se déplacer, être renommés ou être supprimés. Vous ne pouvez pas compter sur Internet pour stocker des objets pour vous. Votre ordinateur portable est peut-être mort et un bogue critique en production doit être corrigé. Le développeur principal pourrait être heurté par un bus et son remplaçant doit démarrer à la hâte. Et je souhaite que le dernier soit un exemple théorique, mais cela s'est réellement produit dans une startup avec laquelle j'étais. DÉCHIRURE.

Maintenant, de façon réaliste, vous ne pouvez pas vraiment archiver TOUTES les dépendances. Vous ne pouvez pas archiver une image de la machine que vous avez utilisée pour créer des builds; vous ne pouvez pas archiver la version exacte du compilateur. Etc. Il y a des limites réalistes. Mais vérifiez tout ce que vous pouvez - ne pas le faire vous rend la vie plus difficile. Et nous n'en voulons pas.

Dernier mot: les pods ne sont pas des artefacts de construction. Les artefacts de build sont ce qui est généré à partir de vos builds. Votre build utilise des pods, pas les générer. Je ne sais même pas pourquoi cela doit être débattu.

Avantages de ne pas se connecter au contrôle Pods/de version (par ordre d'importance subjectif):

1. Les commits sont beaucoup plus faciles à fusionner et les différences de code de révision. La fusion est une source courante de problèmes dans une base de code, ce qui vous permet de vous concentrer uniquement sur les éléments pertinents.
2. Il est impossible pour un contributeur aléatoire de modifier lui-même les dépendances et de vérifier les modifications, ce qu'il ne devrait jamais faire (et encore une fois, il serait difficile d'identifier si le diff est massif). La modification des dépendances est une très mauvaise pratique car un futurpod install pourrait masquer les modifications.
3. Les écarts entre le Podfileet le Pods/répertoire sont plus rapides chez les coéquipiers. Si vous vous enregistrez Pods/et, par exemple, mettez à jour une version dans le Podfile, mais oubliez d'exécuter pod installou d'archiver les modifications apportées à Pods/, vous aurez beaucoup plus de difficulté à remarquer la source de l'écart. S'il Pods/n'est pas enregistré, vous devez toujours exécuter de pod installtoute façon.
4. Taille de dépôt plus petite. Avoir une plus petite empreinte en octets est bien, mais cela n'a pas beaucoup d'importance dans le grand schéma. Plus important encore: avoir plus de choses dans le repo augmente également votre charge cognitive. Il n'y a aucune raison d'avoir dans le référentiel des choses que vous ne devriez pas regarder. Référez-vous à la documentation (l'abstraction) pour savoir comment quelque chose fonctionne, pas au code (l'implémentation).
5. Plus facile de discerner la contribution de quelqu'un (puisque ses lignes de code ont contribué n'incluront pas les dépendances qu'il n'a pas écrites)
6. JARfichiers, .venv/(environnements virtuels), et node_modules/ne sont jamais inclus dans le contrôle de version. Si nous étions complètement agnostiques sur la question, ne pas s'enregistrer Podsserait la valeur par défaut basée sur le précédent.

Inconvénients de ne pas enregistrer lePods/

1. Vous devez exécuter pod installlorsque vous changez de branche ou annulez les validations.
2. Vous ne pouvez pas exécuter un projet simplement en clonant le référentiel. Vous devez installer l'outil pod, puis exécuter pod install.
3. Vous devez disposer d'une connexion Internet pour fonctionner pod installet la source des modules doit être disponible.
4. Si le propriétaire d'une dépendance supprime son package, vous avez des problèmes.

En résumé, ne pas inclure le Podsrépertoire est un garde-fou contre plus de mauvaises pratiques. L'inclusion du Podsrépertoire facilite l'exécution du projet. Je préfère le premier au second. Vous n'aurez pas besoin de faire un compte rendu à chaque nouvelle personne sur un projet sur "ce qu'il ne faut pas faire" s'il n'y a pas la possibilité de commettre certaines erreurs en premier lieu. J'aime aussi l'idée d'avoir un contrôle de version séparé pour Podsqui atténue les inconvénients.

En théorie, vous devriez vérifier dans le répertoire Pods. En pratique, cela ne va pas toujours fonctionner. De nombreux pods dépassent largement la taille limite des fichiers github, donc si vous utilisez github, vous aurez des problèmes de vérification dans le répertoire Pods.

TL; DR: lorsque vous suivez le Pods/dossier, le projet est plus facile à récupérer. Lorsque vous ne le suivez pas, il est plus facile de vous améliorer lorsque vous travaillez en équipe.

Bien que l'organisation Cocoapods nous encourage à suivre le Pods/répertoire, ils disent que c'est aux développeurs de décider de le faire ou non en fonction de ces avantages et inconvénients:  http://guides.cocoapods.org/using/using-cocoapods.html # devrait-i-vérifier-le-répertoire-pods-en-contrôle-source

Personnellement, je surveille généralement le Pods/dossier uniquement pour les projets sur lesquels je ne travaillerai plus pendant un certain temps. De cette façon, n'importe quel développeur peut rapidement en tirer parti et continuer le travail en utilisant la bonne version des cocoapods.

D'un autre côté, je pense que l'historique des validations devient plus propre et il est plus facile de fusionner le code et d'examiner le code d'une autre personne lorsque vous ne suivez pas le Pods/dossier. Je règle généralement la version de la bibliothèque cocoapod lorsque je l'installe pour m'assurer que tout le monde peut installer le projet en utilisant les mêmes versions que moi.

De plus, lorsque le Pods/répertoire est suivi, tous les développeurs doivent utiliser la même version de Cocoapods pour l'empêcher de changer des dizaines de fichiers à chaque fois que nous exécutons pod installpour ajouter / supprimer un pod.

Conclusion : lorsque vous suivez le Pods/dossier, le projet est plus facile à récupérer. Lorsque vous ne le suivez pas, il est plus facile de s'améliorer.

On dirait qu'un bon moyen de structurer cela serait vraiment d'avoir le répertoire "Pods" comme un sous-module git / projet séparé, voici pourquoi.

• Le fait d'avoir des pods dans le référentiel de votre projet, lorsque vous travaillez avec plusieurs développeurs, peut entraîner des différences TRÈS LARGES dans les demandes d'extraction où il est presque impossible de voir le travail réel qui a été modifié par les gens (pensez que plusieurs centaines à des milliers de fichiers ont été modifiés pour les bibliothèques, et seulement un peu ont changé dans le projet actuel).

• Je vois le problème de ne rien engager pour git, car la personne qui possède la bibliothèque peut la retirer à tout moment et vous êtes essentiellement SOL, cela résout également cela.

Que vous archiviez ou non votre dossier Pods dépend de vous, car les flux de travail varient d'un projet à l'autre. Nous vous recommandons de garder le répertoire Pods sous contrôle de source et de ne pas l'ajouter à votre .gitignore. Mais en fin de compte, cette décision vous appartient:

Avantages de la vérification dans le répertoire Pods

1. Après le clonage du référentiel, le projet peut immédiatement être construit et exécuté, même sans avoir installé CocoaPods sur la machine. Il n'est pas nécessaire d'exécuter l'installation du pod et aucune connexion Internet n'est nécessaire.
2. Les artefacts Pod (code / bibliothèques) sont toujours disponibles, même si la source d'un Pod (par exemple GitHub) devait baisser.
3. Les artefacts Pod sont garantis identiques à ceux de l'installation d'origine après le clonage du dépôt.

Avantages d'ignorer le répertoire Pods

1. Le dépôt de contrôle de source sera plus petit et prendra moins de place. Tant que les sources (par exemple GitHub) pour tous les pods sont disponibles, CocoaPods est généralement en mesure de recréer la même installation. Cela est particulièrement vrai lors de l'utilisation de fichiers zip dans le Podfile.)
2. Il n'y aura aucun conflit à gérer lors de l'exécution d'opérations de contrôle de source, telles que la fusion de branches avec différentes versions de pod. Que vous archiviez ou non le répertoire Pods, Podfile et Podfile.lock doivent toujours être sous contrôle de version.