web-dev-qa-db-fra.com

Que contient votre .gitignore si vous utilisez CocoaPods?

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

Je l'ai essayé sur un projet personnel: j'ai ajouté une dépendance à Kiwi à mon fichier Podfile, lancé pod install CocoaPodsTest.xcodeproj et voila, cela 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 veuille vérifier le fichier podfile lui-même et probablement aussi le fichier .xcworkspace; 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'ajoute d'autres dépendances) que je devrais également ajouter à mon fichier .gitignore?

objective-cgitcocoapods
353
Dan Tao

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 ressemble à quelque chose comme:

Le fichier podfile fait référence à une balise spécifique ou à une validation de chaque dépendance afin que les pods eux-mêmes puissent être générés à partir du fichier podfile, car ils ressemblent davantage à un produit de construction intermédiaire qu'à une source et ne nécessitent donc pas de contrôle de version dans mon projet.

232
Matt Mower

Je commets 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 elle!

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 simplement et installe vos dépendances à votre place. 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 en aurez besoin pour construire votre projet ... un administrateur d'équipe en a besoin, votre serveur de CI en a besoin. En règle générale, vous devriez toujours pouvoir cloner votre référentiel source et le construire sans aucun effort supplémentaire. 

Ne pas valider votre répertoire Pods crée également un énorme mal de tête si vous changez souvent de branche. Maintenant, vous devez exécuter l'installation du pod à chaque changement de branche pour vous assurer que vos dépendances sont correctes. Cela peut être moins fastidieux à mesure que vos dépendances se stabilisent, mais au début d'un projet, il s'agit d'une perte de temps considérable. 

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 repo légèrement plus grand? Pas la fin du monde. 

348
Luke Redpath

Je recommande d’utiliser le gitHub de Objective-C gitignore . En détail, les meilleures pratiques sont:

  • La Podfiledoit toujours être sous contrôle de source.
  • Le Podfile.lockdoit toujours être sous contrôle de source.
  • L'espace de travail généré par CocoaPods devrait être maintenu sous contrôle de source.
  • Tout pod référencé avec l'option :pathdevrait être conservé sous contrôle de source.
  • Le dossier ./Podspeut être conservé 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 construction, vous pouvez prendre en considération certaines raisons avant de décider de le garder sous contrôle de source:

  • CocoaPods n'est pas un gestionnaire de paquets, donc la source originale de la bibliothèque pourrait être supprimée à l'avenir par l'auteur.
  • Si le dossier Pods est inclus dans le contrôle de source, il n'est pas nécessaire d'installer CocoaPods pour exécuter le projet, car l'extraction suffirait.
  • CocoaPods est toujours en cours d’exécution et certaines options ne donnent pas toujours le même résultat (par exemple, les options :head et :git n’utilisent pas actuellement les validations stockées dans Podfile.lock).
  • Il y a moins de points d'échec si vous pouvez reprendre le travail sur un projet après une période moyenne/longue.
132
Fabio

Je travaille généralement sur les applications des clients. Dans ce cas, j’ajoute également le répertoire Pods au référentiel, afin de garantir qu’à tout moment un développeur puisse effectuer une extraction, créer et exécuter.

Si c’était une application de notre choix, j’exclurais probablement le répertoire Pods jusqu’à ce que je n’y travaille plus pendant un moment.

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

38
alloy

fichier .gitignore

Pas de réponse en fait offre un .gitignore, voici donc deux variantes.

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

Compatible avec Xcode/iOS, ignorer, ignorer les fichiers système Mac OS, Xcode, les versions, les autres référentiels et les 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 vérifiiez ou non le répertoire Pods, les fichiers Podfile et Podfile.lock doivent toujours être conservés sous contrôle de version.

Si Pods ne sont pas archivés, votre Podfile devrait probablement demander des numéros de version explicites pour chaque Cocoapod. Cocoapods.org discussion ici .

31
SwiftArchitect

Je vérifie tout. (Pods/ et Podfile.lock.) 

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

Je préférerais vendre des objets 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'historique dans le référentiel du Pod, etc.

16
funroll

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

Que vous vérifiiez ou non dans votre dossier Pods dépend de vous, comme les flux de travail varient d'un projet à l'autre. Nous vous recommandons de conserver le Répertoire Pods sous contrôle de code source, et ne l'ajoutez pas à votre fichier .gitignore. Mais en fin de compte, cette décision vous appartient:

Avantages de l'enregistrement dans le répertoire Pods

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

Avantages d'ignorer le répertoire Pods

  • Le référentiel 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, rien ne garantit que l'installation du pod en cours va récupérer Et recréer des artefacts identiques lorsque vous n'utilisez pas un commit SHA dans le Podfile. Cela est particulièrement vrai lorsque vous utilisez des fichiers Zip dans le Podfile.)

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

Que vous vérifiiez ou non le répertoire Pods, le fichier Podfile et le fichier Podfile.lock doit toujours être conservé sous contrôle de version.

15
shah1988

Je suis dans le camp des développeurs qui ne vérifient pas les bibliothèques, en supposant que nous en ayons un bon exemplaire disponible ailleurs. Ainsi, dans mon .gitignore, j'inclus les lignes suivantes spécifiques à CocoaPods:

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

Ensuite, je m'assure que nous avons un exemplaire des bibliothèques dans un endroit sûr. Plutôt que d'utiliser (incorrectement) le référentiel de code d'un projet pour stocker des dépendances (compilées ou non), je pense que le meilleur moyen de le faire est d'archiver les générations. Si vous utilisez un serveur de CI pour vos générations (telle que Jenkins), vous pouvez archiver de manière permanente toutes les générations qui sont importantes pour vous. Si vous effectuez toutes vos versions de production dans votre Xcode local, prenez l’habitude de créer une archive de votre projet pour toutes les versions que vous souhaitez conserver. Quelque chose comme: 1. Produit -> Archive

  1. Distribuer ... Soumettre vers iOS App Store/Enregistrer pour l'entreprise ou Déploiement ad-hoc/et encore

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

  3. Faites un clic droit et compressez "WhateverProject"

Cela fournit une image as-build de l'ensemble du projet, y compris l'ensemble des paramètres de projet et d'espace de travail utilisés pour créer l'application, ainsi que des distributions binaires (telles que Sparkle, des kits de développement propriétaires tels que TestFlight, etc.) qu'ils utilisent ou non CocoaPod.

Mise à jour: J'ai changé d'avis à ce sujet et engage maintenant le Podfile.lock dans le contrôle de code source. Cependant, je continue de croire que les pods eux-mêmes sont des artefacts de construction et qu'ils doivent être gérés comme tels en dehors du contrôle des sources, via une autre méthode, telle que votre serveur CI ou un processus d'archivage tel que décrit ci-dessus.

12
Alex Nauda

Je préfère valider le répertoire Pods avec Podfile et Podfile.lock pour m'assurer que tous les membres de mon équipe puissent vérifier la source à tout moment et qu'ils n'ont pas à s'inquiéter de rien ni à faire des opérations supplémentaires pour que cela fonctionne.

Cela aide également dans un scénario où vous avez corrigé un bogue dans l'un des pods ou modifié certains comportements selon vos besoins, mais ces modifications ne seront pas disponibles sur d'autres machines si elles ne sont pas validées.

Et pour ignorer les répertoires inutiles:

xcuserdata/
11
nomann

Je dois dire que je suis un partisan de la création de pods dans le référentiel. En suivant un lien déjà mentionné, vous obtiendrez un bon fichier .gitignore pour obtenir vos projets Xcode pour iOS afin de permettre les pods, mais également pour vous permettre de les exclure facilement si vous le souhaitez: https://github.com/github/ gitignore/blob/master/Objective-C.gitignore

Si je suis un fan d’ajout de pods au référentiel, c’est pour une raison fondamentale que personne ne semble comprendre, que se passe-t-il si une bibliothèque dont notre projet est si dépendant s’est soudainement retirée du Web? 

  • Peut-être que l’hôte décide qu’il ne veut plus garder son compte GitHub Ouvert. Que se passe-t-il si la bibliothèque a plusieurs années (Comme plus de 5 ans par exemple), le projet Présente un risque élevé ne plus être disponible à la source
  • Autre point également, que se passe-t-il si l’URL du référentiel Change? Disons que la personne qui sert le pod à partir de son compte GitHub Décide de se représenter elle-même sous un autre descripteur, les URL de vos pods ne fonctionnant plus.
  • Enfin un autre point. Dites si vous êtes un développeur comme moi qui codifie beaucoup lors d’un vol entre pays. Je tire rapidement sur la branche 'master', puis installe un pod sur cette branche tout en restant assis à l’aéroport. Je me prépare pour le prochain vol de 8 heures Après 3 heures de vol, je réalise que je dois passer à Une autre branche ... 'DOH' - informations manquantes relatives aux pods, disponibles uniquement sur la branche 'principale'.

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

À partir de cela, je pense que les instantanés dans vos référentiels de code sont certainement meilleurs que d'être stricts sur la taille du référentiel. Et comme déjà mentionné, le fichier podfile.lock - sous contrôle de version, vous donnera un bon historique des versions de votre pod.

En fin de compte, si les délais, le budget et le budget sont serrés, il est primordial - nous devons faire preuve de la plus grande ingéniosité possible et ne pas perdre de temps sur des idéologies strictes, mais plutôt exploiter un ensemble d’outils pour travailler ensemble. - rendre nos vies plus faciles plus efficaces. 

10
leewilson86

À la fin, c’est à vous de choisir votre approche.

Voici ce qu'en pense l'équipe de Cocoapods:

Que vous vérifiiez ou non dans votre dossier Pods dépend de vous, comme les flux de travail varient d'un projet à l'autre. Nous vous recommandons de conserver le Répertoire Pods sous contrôle de code source, et ne l'ajoutez pas à votre fichier .gitignore. Mais finalement, cette décision est à vous.

Personnellement, j'aimerais garder Pods, comme node_modules si j’utilisais Node ou bower_components si j’utilisais Bower. Ceci s’applique à presque tous les gestionnaires de dépendances et constitue la philosophie de git submodules aswell.

Cependant, il peut arriver que vous souhaitiez être vraiment sûr du state-of-art de certaines dépendances, de cette façon, vous êtes responsable de la dépendance dans votre projet. Bien sûr, vous rencontrez plusieurs inconvénients, mais les préoccupations ne concernent pas uniquement les Cocoapods, elles s’appliquent à tous les gestionnaires de dépendances.

Vous trouverez ci-dessous une bonne liste de avantages/inconvénients établie par l’équipe de Cocoapods, ainsi que le texte intégral de la citation mentionnée précédemment.

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

8
zevarito

Cela dépend, personnellement:

Pourquoi les pods doivent faire partie du repo (sous contrôle de source) et ne doivent 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 ce qui s'est passé. Dans un ancien projet où vous souhaitiez juste une petite modification, vous auriez besoin d'implémenter une nouvelle bibliothèque pour pouvoir même construire .
  • Les paramètres pods.xcodeproj font également partie du contrôle de source. Cela signifie par exemple Si vous avez le projet dans Swift 4, mais que certains pods doivent l'être dans Swift 3.2 car ils ne sont pas encore mis à jour, ces paramètres seront enregistrés. Sinon, celui qui clonait le référentiel se retrouverait avec des erreurs.
  • Vous pouvez toujours supprimer des modules du projet et exécuter pod install, l'inverse ne peut pas être effectué.
  • Même les auteurs des Cocoapod le recommandent.

Quelques inconvénients: référentiel plus grand, diffs déroutants (principalement pour les membres de l’équipe), potentiellement plus de conflits.

7
Jakub Truhlář

Pour moi, la plus grande préoccupation est de sécuriser votre source à l’avenir. Si vous envisagez de faire durer votre projet pendant un certain temps et que CocoaPods disparaisse un jour ou que la source de l'un des pods disparaisse, vous ne pouvez absolument pas tenter votre chance si vous essayez de créer de nouvelles archives.

Cela pourrait être atténué par des archives périodiques complètes.

2
Shawn

Vérifiez dans les pods.

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

  • Toutes les constructions doivent être reproductibles 
  • Le seul moyen de s’assurer que les versions sont reproductibles est de contrôler toutes les dépendances; il est donc indispensable de vérifier toutes les dépendances
  • Un nouveau développeur partant de zéro doit pouvoir vérifier votre projet et commencer à travailler. 

Pourquoi?

CocoaPods ou toute autre bibliothèque externe peut changer, ce qui pourrait casser des choses. Ils peuvent aussi être déplacés, renommés ou supprimés. Vous ne pouvez pas compter sur Internet pour stocker des choses pour vous. Votre ordinateur portable est peut-être mort et un bogue critique de la production doit être corrigé. Le développeur principal pourrait être heurté par un bus et son remplaçant doit démarrer rapidement. Et j'aimerais que ce dernier soit un exemple théorique, mais c'est ce qui s'est passé lors d'un démarrage avec lequel j'étais. DÉCHIRURE.

De manière réaliste, vous ne pouvez pas vraiment vérifier TOUTES les dépendances. Vous ne pouvez pas enregistrer une image de la machine que vous avez utilisée pour créer des versions; vous ne pouvez pas vérifier la version exacte du compilateur. Etc. Il y a des limites réalistes. Mais enregistrez tout ce que vous pouvez - ne pas le faire vous rend la vie plus difficile. Et nous ne voulons pas ça.

Mot final: Les pods ne sont pas des artefacts de construction. Les artefacts de génération sont générés à partir de vos versions. Votre construction utilise des pods, pas les générer. Je ne sais même pas pourquoi cela doit être débattu.

2
n13

Que vous vérifiiez ou non votre dossier Pods vous appartient, car les flux de travail varient d'un projet à l'autre. Nous vous recommandons de conserver 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 construire et s'exécuter, même sans avoir CocoaPods installé sur la machine. Il n'est pas nécessaire de lancer l'installation du pod et aucune connexion Internet n'est nécessaire.
  2. Les artefacts de pod (code/bibliothèques) sont toujours disponibles, même si la source d’un pod (par exemple, GitHub) devait s’éteindre.
  3. Les artefacts de pod sont garantis identiques à ceux de l'installation d'origine après le clonage du référentiel.

Avantages d'ignorer le répertoire Pods

  1. Le référentiel de contrôle des sources 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, rien ne garantit que install récupérera et recréera des artefacts identiques lorsque vous n'utiliserez pas de validation SHA dans le fichier podfile. Cela est particulièrement vrai lorsque vous utilisez des fichiers Zip dans le fichier podfile.)
  2. Lors de l'exécution d'opérations de contrôle de source, il n'y aura pas de conflits, par exemple lors de la fusion de branches avec différentes versions de Pod Que vous archiviez ou non dans le répertoire Pods, les fichiers Podfile et Podfile.lock doivent toujours être conservés sous la version. contrôle.
0
Sourabh Mahna

En théorie, vous devriez vérifier dans le répertoire Pods. En pratique, ça ne va pas toujours marcher. De nombreux pods dépassent bien la taille limite des fichiers github, donc si vous utilisez github, vous aurez des problèmes pour vérifier le répertoire Pods. 

0
Matt

Il semble qu'un bon moyen de structurer cela serait de faire du répertoire "Pods" un sous-module git/projet séparé, voici pourquoi.

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

  • Je vois le problème de ne rien commettre à cracher, car le propriétaire de la bibliothèque pourrait le supprimer à tout moment et que vous êtes essentiellement SOL, cela résout également ce problème.

0
jaredpetker

Avantages de pas archiver Pods/ dans le contrôle de version (par ordre d'importance subjectif):

  1. Beaucoup plus facile à fusionner les commits, et réviser les diffs de code. La fusion est une source commune 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 les dépendances elles-mêmes et de vérifier les modifications, ce qu’ils ne devraient jamais faire (et il serait difficile d’identifier si le diff est énorme). Éditer les dépendances est une très mauvaise pratique car un futur pod install pourrait masquer les modifications.
  3. Les différences entre les répertoires Podfile et Pods/ sont plus rapides parmi les coéquipiers. Si vous archivez Pods/ et, par exemple, mettez à jour une version dans Podfile, mais oubliez d'exécuter pod install ou archivez les modifications apportées à Pods/, vous aurez beaucoup plus de mal à remarquer la source de la différence. Si Pods/ n'est pas archivé, vous devez toujours exécuter pod install de toute façon.
  4. Plus petite taille de repo. Nice a une empreinte en octets plus petite, mais cela n’a pas beaucoup d’importance dans le schéma général. Plus important encore: avoir plus de choses dans le repo augmente également votre charge cognitive. Il n'y a aucune raison d'avoir des choses dans le repo que vous ne devriez pas regarder. Reportez-vous à la documentation (l'abstraction) pour savoir comment quelque chose fonctionne, pas au code (l'implémentation).
  5. Plus facile de discerner combien une personne contribue (étant donné que leurs lignes de code ne comprennent pas de dépendances non écrites)
  6. Les fichiers JAR, .venv/ (environnements virtuels) et node_modules/ ne sont jamais inclus dans le contrôle de version. Si nous étions complètement agnostiques à propos de la question, pas archiver Pods serait la valeur par défaut basée sur précédent.

Inconvénients de pas archiver le Pods/

  1. Vous devez exécuter pod install lors du changement de branche ou de l'annulation des 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 exécuter pod install et la source des pods doit être disponible.
  4. Si le propriétaire d'une dépendance supprime son package, vous êtes en difficulté.

En résumé, non compris le répertoire Pods est un garde-fou contre d'autres mauvaises pratiques. Inclus le répertoire Pods facilite l'exécution du projet. Je préfère le premier au second. Vous n’avez pas besoin de faire un compte rendu à chaque nouvelle personne participant à un projet sur «que faire {pas» »_ s'il n’est pas possible de faire certaines erreurs au départ. J'aime aussi l’idée d’avoir un contrôle de version séparé pour Pods qui atténue les inconvénients.

0
efthimio