¿Qué entra en tu .gitignore si estás usando CocoaPods?

He estado haciendo desarrollo de iOS por un par de meses y acabo de enterarme de la prometedora librería CocoaPods para gestión de dependencies.

Lo probé en un proyecto personal: agregué una dependencia de Kiwi a mi file Podfile, ejecuté la pod install CocoaPodsTest.xcodeproj , y listo , funcionó muy bien.

Lo único que me pregunto es: ¿qué controlo y qué ignoro para el control de la versión? Parece obvio que quiero verificar el file Podfile mismo, y probablemente también el file .xcworkspace; pero ignoro el directory Pods /? ¿Hay otros files que se generarán en el futuro (cuando agregue otras dependencies) que también debería agregar a mi .gitignore?

Personalmente no verifico en el directory y contenido de Pods. No puedo decir que pasé largas edades teniendo en count las implicaciones, pero mi razonamiento es algo así como:

El Podfile se refiere a una label específica o compromiso de cada dependencia para que los Pods mismos puedan generarse desde el file podfile, ergo son más como un producto de construcción intermedio que una fuente y, por lo tanto, no necesitan control de versión en mi proyecto.

Confirmo mi directory de Pods. No estoy de acuerdo con que el directory de Pods sea un artefacto de construcción. De hecho, diría que definitivamente no lo es. Es parte de la fuente de su aplicación: ¡no se comstackrá sin ella!

Es más fácil pensar en CocoaPods como una herramienta de desarrollo en lugar de una herramienta de construcción. No construye su proyecto, simplemente clona e instala sus dependencies por usted. No debería ser necesario tener CocoaPods instalado para poder simplemente build su proyecto.

Al hacer que CocoaPods sea una dependencia de su compilation, ahora necesita asegurarse de que esté disponible en todos los lugares que pueda necesitar para build su proyecto … un administrador del equipo lo necesita, su server de CI lo necesita. Como regla general, siempre debe poder clonar su repository de origen y comstackr sin ningún esfuerzo adicional.

No comprometer su directory de Pods también crea un gran dolor de cabeza si con frecuencia cambia de sucursales. Ahora necesita ejecutar la installation de pod cada vez que cambia de bifurcación para asegurarse de que sus dependencies son correctas. Esto podría ser less complicado ya que sus dependencies se estabilizan, pero al principio de un proyecto, este es un sumidero de time masivo.

Entonces, ¿qué ignoro? Nada. Podfile, el file de locking y el directory de Pods se comprometen. Confía en mí, te ahorrará muchas molestias. ¿Cuáles son los contras? ¿Un repo un poco más grande? No es el fin del mundo.

Recomiendo usar GitHub Objective-C gitignore . En detalle, las mejores prácticas son:

  • El Podfile siempre debe estar bajo control de fuente.
  • El Podfile.lock siempre debe estar bajo control de fuente.
  • El espacio de trabajo generado por CocoaPods debe mantenerse bajo control de fuente.
  • Cualquier Pod referencedo con la opción :path debe mantenerse bajo control de fuente.
  • La carpeta ./Pods se puede mantener bajo control de fuente.

Para get más información, puede consultar la guía oficial .

fuente: soy miembro del equipo central de CocoaPods, como @alloy


Aunque la carpeta Pods es un artefacto de construcción, hay razones que puede considerar al decidir si desea mantenerlo bajo control de fuente:

  • CocoaPods no es un administrador de packages, por lo que el autor podría eliminar la fuente original de la biblioteca en el futuro.
  • Si la carpeta Pods está incluida en el control de código fuente, no es necesario instalar CocoaPods para ejecutar el proyecto, ya que el process de pago sería suficiente.
  • CocoaPods todavía está en process y hay opciones que no siempre conducen al mismo resultado (por ejemplo, las opciones :head y the :git actualmente no están usando las confirmaciones almacenadas en el Podfile.lock ).
  • Hay less puntos de falla si puede reanudar el trabajo en un proyecto después de un time medio / largo.

Generalmente trabajo en aplicaciones de clientes. En ese caso agrego el directory de Pods al repository también, para asegurarme de que en cualquier momento dado cualquier desarrollador pueda hacer un checkout y comstackr y ejecutar.

Si fuera una aplicación nuestra, probablemente excluiría el directory de Pods hasta que no lo haga por un time.

En realidad, debo concluir que quizás no sea la mejor persona para responder a su pregunta, en comparación con las opiniones de usuarios puros 🙂 Voy a twittear sobre esta pregunta en https://twitter.com/CocoaPodsOrg .

file .gitignore

Ninguna respuesta en realidad ofrece un .gitignore , así que aquí hay dos sabores.


Verificación en el directory de Pods ( Beneficios )

Xcode / iOS friendly git ignora, omitiendo files del sistema Mac OS, Xcode, comstackciones, otros repositorys y copys de security.

.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/ 

Ignorando el directory de Pods ( Beneficios )

.gitignore: (anexar a la list anterior)

 # Cocoapods Pods/ 

Ya sea que revise o no en el directory de Pods, el file Podfile y Podfile.lock siempre deben mantenerse bajo control de versión.

Si los Pods no están registrados, Podfile probable que tu Podfile solicite numbers de versión explícitos para cada Cocoapod. Discusión de Cocoapods.org aquí .

Reviso todo. ( Pods/ y Podfile.lock .)

Quiero ser capaz de clonar el repository y saber que todo funcionará como lo hizo la última vez que utilicé la aplicación.

Preferiría vender cosas que arriesgarme a tener resultados diferentes que podrían ser causados ​​por una versión diferente de la gem, o alguien reescribiendo el historial en el repository del Pod, etc.

Estoy en el campo de desarrolladores que no revisan las bibliotecas, suponiendo que tenemos una buena copy disponible en otra location. Entonces, en mi .gitignore, incluyo las siguientes líneas específicas para CocoaPods:

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

Luego me aseguro de tener una copy de las bibliotecas en un lugar seguro. En lugar de (mal) utilizar el repository de código de un proyecto para almacenar dependencies (comstackdas o no), creo que la mejor manera de hacerlo es archivar las comstackciones. Si usa un server de CI para sus comstackciones (como Jenkins), puede archivar de forma permanente cualquier compilation que sea importante para usted. Si realiza todas las comstackciones de producción en su Xcode local, hágase un hábito de tomar un file de su proyecto para cualquier compilation que necesite conservar. Algo como: 1. Producto -> Archivo

  1. Distribuir … Enviar a iOS App Store / Guardar para Enterprise o Ad-hoc Deployment / ¿qué tienes?

  2. Revela la carpeta de tu proyecto en Finder

  3. Haga clic derecho y compruebe "WhateverProject"

Esto proporciona una image tal como está construida de todo el proyecto, incluidos los ajustes completos del proyecto y del espacio de trabajo utilizados para build la aplicación, así como las distribuciones binarias (como Sparkle, SDK propietarios como TestFlight, etc.) ya sea que utilicen CocoaPods o no.

Actualización: he cambiado de opinión sobre esto y ahora comprometo el Podfile.lock al control de fuente. Sin embargo, sigo creyendo que los pods en sí mismos son artefactos de construcción y deberían gestionarse como tales fuera del control de fuente, a través de otro método como el server de CI o un process de file como el descrito anteriormente.

Prefiero Podfile directory de Pods junto con Podfile y Podfile.lock para asegurarme de que cualquier Podfile.lock de mi equipo pueda consultar la fuente en cualquier momento y no tengan que preocuparse por nada ni hacer otras cosas para que funcione.

Esto también ayuda en un escenario en el que haya corregido un error dentro de uno de los pods o modificado algún comportamiento según sus necesidades, pero estos cambios no estarán disponibles en otras máquinas si no están comprometidos.

Y para ignorar directorys innecesarios:

 xcuserdata/ 

La respuesta para esto se da directamente en los documentos de Cocoapod. Puede consultar " http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control "

Ya sea que revise o no su carpeta Pods depende de usted, ya que los flujos de trabajo varían de un proyecto a otro. Le recomendamos que mantenga el directory de Pods bajo control de fuente y no lo agregue a su .gitignore. Pero en última instancia, esta decisión depende de usted:

Beneficios de consultar en el directory Pods

  • Después de clonar el repository, el proyecto puede crearse y ejecutarse inmediatamente, incluso sin tener CocoaPods instalado en la máquina. No es necesario ejecutar la installation del pod, y no se necesita connection a Internet.
  • Los artefactos Pod (código / bibliotecas) están siempre disponibles, incluso si la fuente de un Pod (por ejemplo, GitHub) bajara.
  • Los artefactos de Pod están garantizados para ser idénticos a los de la installation original después de clonar el repository.

Beneficios de ignorar el directory de Pods

  • El repository de control de origen será más pequeño y ocupará less espacio.

  • Siempre que las fonts (por ejemplo, GitHub) para todos los Pods estén disponibles, CocoaPods generalmente puede recrear la misma installation. (Técnicamente, no hay garantía de que la installation del pod en ejecución busque y vuelva a crear artefactos idénticos cuando no se use un SHA de confirmación en el file Podfile. Esto es especialmente cierto cuando se usan files zip en el Podfile).

  • No habrá ningún conflicto al tratar de realizar operaciones de control de origen, como fusionar sucursales con diferentes versiones de Pod.

Ya sea que revise o no en el directory de Pods, el file Podfile y Podfile.lock siempre deben mantenerse bajo control de versión.

Debo decir que soy fanático de enviar Pods al repository. Seguir un enlace ya mencionado le dará un buen file .gitignore para get sus proyectos de Xcode para iOS para permitir Pods, pero también para que pueda excluirlos fácilmente si lo desea: https://github.com/github/gitignore/ blob / master / Objective-C.gitignore

Mi razonamiento para ser un fan de agregar Pods al repository es por una razón fundamental que nadie parece estar retomando, ¿qué sucede si una biblioteca de la que nuestro proyecto es tan dependiente se retira de repente de la web?

  • Quizás el anfitrión decida que ya no quiere mantener abierta su count de GitHub. Lo que sucede si la biblioteca tiene varios años (por ejemplo, más de 5 años), existe un alto riesgo de que el proyecto ya no esté disponible en la fuente
  • También otro punto, ¿qué sucede si la URL del repository cambia? Digamos que la persona que sirve el Pod desde su count de GitHub, decide representarse a sí misma bajo un mango diferente: sus URL de Pods se van a romper.
  • Finalmente otro punto. Di si eres un desarrollador como yo que hace mucha encoding cuando estás en un vuelo entre países. Hago una extracción rápida de la twig 'maestra', hago una installation de pod en esa twig, mientras estoy sentado en el aeropuerto y tengo todo listo para el próximo vuelo de 8 horas. Tengo 3 horas en mi vuelo, y me doy count de que necesito cambiar a otra sucursal …. 'DOH' – información faltante de Pod que solo está disponible en la twig 'principal'.

NB … tenga en count que la twig 'maestra' para el desarrollo es solo por ejemplos, obviamente las twigs 'maestras' en los sistemas de control de versiones, deben mantenerse limpias y desplegables / edificables en cualquier momento

Creo que a partir de estos, las instantáneas en los repositorys de código son ciertamente mejores que ser estrictos en el tamaño del repository. Y como ya se mencionó, el file podfile.lock – mientras la versión está controlada le dará un buen historial de sus versiones de Pod.

Al final del día, si tiene un ploop apremiante, un presupuesto ajustado, el time es esencial: necesitamos ser lo más ingeniosos posible y no perder el time en ideologías estrictas, y en su lugar aprovechar un set de herramientas para trabajar juntas – para hacer nuestras vidas más fáciles y más eficientes.

Al final depende de usted el enfoque que tome.

Esto es lo que piensa el equipo de Cocoapods al respecto:

Ya sea que revise o no su carpeta Pods depende de usted, ya que los flujos de trabajo varían de un proyecto a otro. Le recomendamos que mantenga el directory de Pods bajo control de fuente y no lo agregue a su .gitignore. Pero en última instancia, esta decisión depende de usted.

Personalmente, me gustaría mantener los Pods fuera, como node_modules si estuviera usando Node o bower_components si estuviera usando Bower . Esto se aplica a casi cualquier administrador de dependencies, y también es la filosofía detrás de los submodules de git .

Sin embargo, a veces es posible que desee estar realmente seguro sobre el estado del arte de una cierta dependencia, de esa manera usted es dueño de la dependencia dentro de su proyecto. Por supuesto, existen varias desventajas que se aplican si lo hace, pero las inquietudes no solo se aplican a Cocoapods, sino que también se aplican a cualquier administrador de dependencies.

A continuación hay una buena list de pros y contras hecha por el equipo de Cocoapods, y el text completo de la cita mencionada anteriormente.

Equipo de Cocoapods: ¿Debería verificar el directory de Pods en el control de la fuente?

Para mí, la mayor preocupación es la testing de futuro de su fuente. Si planeas que tu proyecto dure por un time y CocoaPods se va o la fuente de uno de los pods se cae, estás completamente fuera de suerte si intentas crear contenido nuevo a partir de un file.

Esto podría mitigarse con archivados periódicos de fuente completa.

Compruebe en las vainas.

Creo que esto debería ser un principio del desarrollo de software

  • Todas las construcciones deben ser reproducibles
  • La única forma de garantizar que las comstackciones sean reproducibles es controlar todas las dependencies; verificar todas las dependencies es por lo tanto una necesidad.
  • Un nuevo desarrollador que empiece desde cero podrá verificar su proyecto y comenzar a trabajar.

¿Por qué?

CocoaPods o cualquier otra biblioteca externa puede cambiar lo que puede romper cosas. O pueden moverse, o ser renombrados, o pueden ser eliminados por completo. No puede confiar en Internet para almacenar cosas para usted. Su computadora portátil podría haber muerto y hay un error crítico en la producción que necesita ser reparado. El desarrollador principal puede ser golpeado por un autobús y su reemploop debe comenzar con prisa. Y desearía que el último fuera un ejemplo teórico, pero realmente sucedió en una startup con la que estaba. Q.E.P.D.

Ahora, de manera realist, no se puede verificar en TODAS las dependencies. No puede registrar una image de la máquina que usó para crear comstackciones; no puede verificar la versión exacta del comstackdor. Y así. Hay límites realists. Pero revisa todo lo que puedas, no hacerlo solo te hace la vida más difícil. Y no queremos eso.

Palabra final: las vainas no son artefactos de construcción. Los artefactos de construcción son los que se generan a partir de tus comstackciones. Tu compilation usa Pods, no los genera. Ni siquiera estoy seguro de por qué esto debe debatirse.

Parece que una buena forma de estructurar esto sería tener el directory "Pods" como un submodule de git / proyecto separado, aquí está el por qué.

  • Tener vainas en el repository del proyecto, cuando se trabaja con varios desarrolladores, puede causar diferencias MUY GRANDES en las requestes de extracción donde es casi imposible ver el trabajo real que fue modificado por las personas (piense que cientos de miles de files han cambiado para bibliotecas, y solo pocos cambios en el proyecto real).

  • Veo el problema de no comprometer nada con git, ya que la persona propietaria de la biblioteca podría eliminarlo en cualquier momento y usted es esencialmente SOL, esto también lo resuelve.

Ya sea que revise o no su carpeta Pods depende de usted, ya que los flujos de trabajo varían de un proyecto a otro. Le recomendamos que mantenga el directory de Pods bajo control de fuente y no lo agregue a su .gitignore. Pero en última instancia, esta decisión depende de usted:

Beneficios de consultar en el directory Pods

  1. Después de clonar el repository, el proyecto puede crearse y ejecutarse inmediatamente, incluso sin tener CocoaPods instalado en la máquina. No es necesario ejecutar la installation del pod, y no se necesita connection a Internet.
  2. Los artefactos Pod (código / bibliotecas) están siempre disponibles, incluso si la fuente de un Pod (por ejemplo, GitHub) bajara.
  3. Los artefactos de Pod están garantizados para ser idénticos a los de la installation original después de clonar el repository.

Beneficios de ignorar el directory de Pods

  1. El repository de control de origen será más pequeño y ocupará less espacio. Siempre que las fonts (por ejemplo, GitHub) para todos los Pods estén disponibles, CocoaPods generalmente puede recrear la misma installation. (Técnicamente no hay garantía de que la installation del pod en ejecución busque y vuelva a crear artefactos idénticos cuando no se use un SHA de confirmación en el file Podfile Esto es especialmente cierto cuando se usan files zip en el Podfile.
  2. No habrá ningún conflicto al tratar de realizar operaciones de control de origen, como fusionar sucursales con diferentes versiones de Pod. Ya sea que revise o no en el directory de Pods, el file Podfile y Podfile.lock siempre deben mantenerse bajo control de versión.

En teoría, debes verificar en el directory Pods. En la práctica, no siempre va a funcionar. Muchos pods superan con creces el límite de tamaño de los files github, por lo que si está utilizando github, tendrá problemas para verificarlos en el directory de Pods.

Depende, personalmente:

Por qué las cápsulas deben ser parte del repository (bajo el control de la fuente) y no deben ignorarse

  • La fuente es idéntica
  • Puedes buildlo de inmediato tal como está (incluso sin los cocoapods)
  • Incluso cuando se elimina un pod, todavía tenemos su copy (sí, esto puede suceder y lo hizo. En un proyecto antiguo en el que solo desea un pequeño cambio, debería implementar una nueva biblioteca para poder incluso build).
  • pods.xcodeproj ajustes de pods.xcodeproj forman parte del control de origen. Esto significa, por ejemplo, si tienes el proyecto en swift 4 , pero algunos pods deben estar en swift 3.2 porque aún no están actualizados, estas configuraciones se saveán. De lo contrario, el que clonó el repos podría terminar con errores.
  • Siempre puede eliminar pods del proyecto y ejecutar la pod install , no se puede hacer lo contrario.
  • Incluso los autores de los Cocoapods lo recomiendan.

Algunas desventajas: repository más grande, diferencias difusas (principalmente para los miembros del equipo), potencialmente más conflictos.