objective-c - framework - update cocoapods




Qu'est-ce qui se passe dans votre.gitignore si vous utilisez CocoaPods? (12)

fichier .gitignore

Aucune réponse n'offre réellement un .gitignore , ainsi voici deux saveurs.

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

Git Xcode / iOS ignorer, ignorer les fichiers système Mac OS, Xcode, builds, d'autres dépôts et des 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 ( Benefits )

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

# Cocoapods
Pods/

Si vous vérifiez dans le répertoire de Pods, le Podfile et Podfile.lock devraient toujours être gardés sous contrôle de version.

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

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

Je l'ai essayé sur un projet personnel: ajouté une dépendance à Kiwi à mon Podfile, a couru l' pod install CocoaPodsTest.xcodeproj , et voila , cela a fonctionné très bien.

La seule chose que je me demande est: qu'est-ce que je vérifie, et qu'est-ce que j'ignore pour le contrôle de version? Il semble évident que je veux vérifier dans le Podfile lui-même, et probablement le fichier .xcworkspace aussi; mais est-ce que j'ignore le répertoire Pods /? Y a-t-il d'autres fichiers qui seront générés plus tard (lorsque j'ajouterai d'autres dépendances) que je devrais ajouter à mon .gitignore?


À la fin est à vous l'approche que vous prenez.

C'est ce que pense l'équipe de Cocoapods:

Le choix de votre dossier Pods dépend de vous, car les flux de travail varient d'un projet à l'autre. Nous vous recommandons de conserver le répertoire Pods sous le contrôle de la source et de ne pas l'ajouter à votre fichier .gitignore. Mais finalement, cette décision dépend de vous.

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

Cependant, il y a des fois où vous voudrez être vraiment sûr de l' état de l'art d'une certaine dépendance, de cette façon vous êtes porteur de 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, ceux-ci s'appliquent à n'importe quel 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 intégral de la citation mentionnée précédemment.

here


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


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

Il est plus facile de considérer CocoaPods comme un outil de développement plutôt qu'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 créer 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 pour construire votre projet ... un administrateur d'équipe en a besoin, votre serveur CI en a besoin. En règle générale, vous devriez toujours être en mesure de cloner votre référentiel source et de le compiler sans effort supplémentaire.

Ne pas commettre votre répertoire Pods crée également un mal de tête massif si vous changez fréquemment de branche. Vous devez maintenant lancer l'installation de pod 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'une perte de temps massive.

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


Je préfère Podfile et Podfile.lock pour s'assurer que tous les membres de mon équipe puissent vérifier la source à tout moment et qu'ils n'aient pas à se soucier de quoi que ce soit ou à faire des choses supplémentaires pour que cela fonctionne.

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

Et pour ignorer les répertoires inutiles:

xcuserdata/

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 conservé sous le contrôle de la source.
  • Tout Pod référencé avec l'option :path doit être conservé sous le contrôle de la source.
  • Le dossier ./Pods peut être conservé sous le contrôle de la source.

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

source: je suis membre de l'équipe de base de CocoaPods, comme @alloy

Bien que le dossier Pods soit un artefact de construction, il y a des raisons que vous pourriez prendre en compte en décidant de le garder sous le contrôle de la 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 la 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 et il y a des options qui ne conduisent pas toujours au même résultat (par exemple les options :head et the :git n'utilisent pas les commits stockés dans le Podfile.lock ).
  • Il y a moins de points d'échec si vous pouvez reprendre le travail sur un projet après un temps moyen / long.

Je travaille généralement sur des applications de clients. Dans ce cas, j'ajoute aussi le répertoire Pods au repo, afin de s'assurer qu'à tout moment n'importe quel développeur puisse faire un checkout et construire et exécuter.

Si c'était une application, j'aurais probablement exclu le répertoire des Pods jusqu'à ce que je ne travaille pas dessus pendant un moment.

En fait, je dois conclure que je ne pourrais pas être la meilleure personne pour répondre à votre question, par rapport aux vues des utilisateurs purs :) Je vais tweeter à propos de cette question de https://twitter.com/CocoaPodsOrg .


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

Je veux pouvoir cloner le dépôt 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 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 dépôt du Pod, etc.


Le choix de votre dossier Pods dépend de vous, car les flux de travail varient d'un projet à l'autre. Nous vous recommandons de conserver le répertoire Pods sous le contrôle de la source et de ne pas l'ajouter à votre fichier .gitignore. Mais finalement, cette décision vous appartient:

Avantages de vérifier dans le répertoire Pods

  1. Après le clonage du repo, le projet peut immédiatement se construire et s'exécuter, même sans avoir installé CocoaPods sur la machine. Il n'est pas nécessaire d'exécuter l'installation de 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 descendre.
  3. Les artefacts du Pod sont garantis identiques à ceux de l'installation d'origine après le clonage du repo.

Avantages d'ignorer le répertoire Pods

  1. Le repo de contrôle de la source sera plus petit et occupera moins d'espace. Tant que les sources (par exemple GitHub) pour 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'installation de pod lancera et recréera des artefacts identiques sans utiliser de SHA de commit dans le Podfile Ceci est particulièrement vrai lors de l'utilisation de fichiers zip dans le fichier Podfile.)
  2. Il n'y aura pas de conflits à traiter 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. Si vous vérifiez dans le répertoire de Pods, le Podfile et Podfile.lock devraient toujours être gardés sous contrôle de version.

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

  • Avoir des pods dans votre projet repo, lorsque vous travaillez avec plusieurs développeurs, peut causer des différences TRÈS LARGE dans les requêtes pull où il est presque impossible de voir le travail réel qui a été modifié par les gens (pensez à plusieurs centaines à des milliers de fichiers peu ont changé dans le projet actuel).

  • Je vois la question de ne rien commettre à git, car la personne qui possède la bibliothèque peut l'enlever à tout moment et vous êtes essentiellement SOL, cela résout aussi cela.


Pour moi, la plus grande préoccupation est la vérification future 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 absolument pas de chance si vous essayez de créer de nouvelles archives.

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


Vérifiez dans les Pods.

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

  • Toutes les constructions doivent être reproductibles
  • La seule façon de s'assurer que les builds sont reproductibles est d'avoir le contrôle de toutes les dépendances; vérifier toutes les dépendances est donc un must.
  • Un nouveau développeur qui part de zéro doit pouvoir vérifier votre projet et commencer à travailler.

Pourquoi?

CocoaPods ou toute autre bibliothèque externe pourrait changer ce qui pourrait casser des choses. Ou ils pourraient se déplacer, ou être renommés, ou être complètement supprimés. Vous ne pouvez pas compter sur Internet pour stocker des choses pour vous. Votre ordinateur portable est peut-être mort et il y a un bug critique dans la production qui doit être corrigé. Le développeur principal pourrait être frappé par un bus et son remplaçant doit démarrer rapidement. Et je souhaite que le dernier était un exemple théorique, mais c'est arrivé à une startup avec laquelle j'étais. DÉCHIRURE.

Maintenant, de façon 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 builds; vous ne pouvez pas vérifier 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 ne fait que rendre votre vie plus difficile. Et nous ne le voulons pas.

Mot final: Les pods ne sont pas des artefacts de construction. Les artefacts de construction sont ce qui est généré à partir de vos builds. Votre build utilise des Pods, pas les générer. Je ne suis même pas sûr de savoir pourquoi cela doit être débattu.





cocoapods