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

388

He estado desarrollando iOS durante un par de meses y acabo de enterarme de la prometedora biblioteca CocoaPods para la gestión de dependencias.

Lo probé en un proyecto personal: agregué una dependencia a Kiwi a mi Podfile, corrí pod install CocoaPodsTest.xcodeprojy listo , funcionó muy bien.

Lo único que me queda por preguntarme es: ¿qué registro y qué ignoro para el control de versiones? Parece obvio que quiero revisar el Podfile mismo, y probablemente también el archivo .xcworkspace; pero ignoro el directorio Pods /? ¿Hay otros archivos que se generarán más adelante (cuando agregue otras dependencias) que también debería agregar a mi .gitignore?

Dan Tao
fuente

Respuestas:

261

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

El Podfile se refiere a una etiqueta o confirmación específica de cada dependencia, por lo que los Pods pueden generarse a partir del podfile, por lo tanto, se parecen más a un producto de compilación intermedio que a una fuente y, por lo tanto, no necesitan control de versiones en mi proyecto.

Matt Mower
fuente
70
Vale la pena mencionar que el proyecto CocoaPods ignora el directorio Pods en el ejemplo .
joshhepworth
34
Consideraría agregar el archivo Podfile.lock, porque luego registra exactamente qué versiones de bibliotecas usó para una compilación específica, y puede reproducirlo exactamente para otros miembros del equipo. Tener que preguntar "qué versión de X estás usando" puede ser muy molesto. Aquí hay una buena discusión del equivalente de Ruby Gemfile: yehudakatz.com/2010/12/16/…
Matt Connolly
12
No entiendo por qué comprometerías el Podfile.lock, ¿no deberías ser más específico en tu Podfile sobre exactamente de qué versiones dependes? ¿Qué no estoy entendiendo?
Michael Baltaks
99
Así es como lo veo: si su Podfile especifica versiones exactas de cada pod, entonces la única forma de obtener actualizaciones es saber si existen actualizaciones y especificarlas manualmente. Esto podría ser preferido para una aplicación popular o de misión crítica. Para un desarrollo anterior, es mucho más fácil obtener actualizaciones importantes si solo difunde Podfile.lock cuando se actualiza y luego decide si desea las actualizaciones, lo que probablemente hace la mayor parte del tiempo.
davidkovsky
43
Es importante mencionar Podfile.lock: Cocoapods lo llama como recomendado para estar bajo control de versión.
cbowns
383

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

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

Al hacer que CocoaPods sea una dependencia de su compilación, ahora debe asegurarse de que esté disponible en todas partes donde necesite construir su proyecto ... un administrador del equipo lo necesita, su servidor CI lo necesita. Como regla general, siempre debe poder clonar su repositorio de origen y compilar sin ningún esfuerzo adicional.

No comprometer el directorio de Pods también crea un gran dolor de cabeza si cambias de sucursal con frecuencia. Ahora debe ejecutar la instalación de pod cada vez que cambie de rama para asegurarse de que sus dependencias sean correctas. Esto puede ser menos complicado ya que sus dependencias se estabilizan, pero al principio de un proyecto, esto es un sumidero de tiempo masivo.

Entonces, ¿qué ignoro? Nada. Podfile, el archivo de bloqueo y el directorio Pods se comprometen. Confía en mí, te ahorrará muchos problemas. ¿Cuáles son las desventajas? ¿Un repositorio un poco más grande? No es el fin del mundo.

Luke Redpath
fuente
33
Esta es definitivamente la forma de usar CocoaPods. No solo es parte de su fuente porque no puede construir sin ella, sino que su "aplicación principal" también suele estar altamente acoplada al código en CocoaPods. Es muy importante para el control de versiones saber exactamente qué versión de un pod se está utilizando, y solo usar Lockfile no es suficiente.
Joshua Gross
35
Más fácil al cambiar de rama y al retroceder en el tiempo ... Este es un argumento masivo.
MonsieurDart
55
Sí, podría haber explicado esto más a fondo, pero para mí una confirmación en su repositorio representa una instantánea de su fuente a tiempo y si no confirma su directorio de Pods, falta una gran parte de esa instantánea. Puede mitigar esto al ser muy específico en sus versiones de Pod, pero también considere esto ... si actualiza uno de sus Pods, si sus Pods están en su repositorio, entonces esa actualización se capturará en un commit y será completamente difusa. Si actualizar un Pod causa un error, puede ver mucho más fácilmente por qué, ya que el cambio subyacente se captura en su propio repositorio.
Luke Redpath
55
Creo que está claro que ahora es una cuestión de gusto personal. La gente como Seamus ahora está polarizando el debate ... realmente no es justo decir que no incluir el Podsdirectorio le causará dolor, cuando registrarlo también viene con su propio conjunto de problemas. por ejemplo, un desarrollador topa una versión de una dependencia en un Podfilesin recordar revisar las fuentes actualizadas en Pods. Ley de murphy. pod installcada vez que cambia de sucursal le cuesta un valor precioso ... DEcenas de segundos, pero elimina esa clase de problemas por completo.
fatuhoku
14
It won't build without it!También podrías cometer XCode
Sourabh
155

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

  • El siempre Podfile debe estar bajo control de la fuente.
  • El siempre Podfile.lock debe estar bajo control de la fuente.
  • El espacio de trabajo generado por CocoaPods debe mantenerse bajo control de origen.
  • Cualquier Pod referenciado con la :pathopción debe mantenerse bajo control de origen.
  • La ./Podscarpeta se puede mantener bajo control de origen.

Para más información puedes consultar la guía oficial .

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


Aunque la carpeta Pods es un artefacto de compilación, hay razones que puede considerar al decidir si mantenerla bajo control de origen:

  • CocoaPods no es un administrador de paquetes, 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 pago sería suficiente.
  • CocoaPods todavía está en progreso y hay opciones que no siempre conducen al mismo resultado (por ejemplo, :headlas :gitopciones y actualmente no están utilizando los commits almacenados en el Podfile.lock).
  • Hay menos puntos de falla si puede reanudar el trabajo en un proyecto después de un período de tiempo medio / largo.
Fabio
fuente
55
¿Por qué molestarse en mantener el archivo del espacio de trabajo? Es generado por Cocoapods de todos modos.
fatuhoku
1
@fatuhoku Para los servidores de prueba de integración continua ciegos de Cocoapods, en mi experiencia. Lo reviso todo porque no tengo acceso al script de compilación para mi host de CI (regla empresarial) y trato a CocoaPods como una herramienta de desarrollador, no como un sistema de compilación o administrador de paquetes.
codepoet
1
La carpeta ./Pod NO debe mantenerse bajo control de fuente (es generada automáticamente) por CocoaPods. La carpeta Pods es un artefacto del proceso de construcción. El espacio de trabajo también se puede eliminar del control de origen a menos que tenga otros proyectos no administrados con CocoaPods.
Vlad
Creo que debería verificarse porque es difícil hacer una instalación de pod cada vez que hago una extracción.
mskw
45

archivo .gitignore

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


Comprobación en el directorio de Pods ( Beneficios )

Xcode / iOS amigable git ignore, omitiendo archivos del sistema Mac OS, Xcode, compilaciones, otros repositorios y copias de seguridad.

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

Ignorar el directorio Pods ( Beneficios )

.gitignore: (agregar a la lista anterior)

# Cocoapods
Pods/

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

Si Podsno está registrado, Podfileprobablemente debería solicitar números de versión explícitos para cada Cocoapod. Discusión de Cocoapods.org aquí .

Arquitecto Swift
fuente
38

Generalmente trabajo en aplicaciones de clientes. En ese caso, también agrego el directorio Pods al repositorio, para asegurarme de que en cualquier momento cualquier desarrollador pueda realizar un pago y compilar y ejecutar.

Si fuera una aplicación propia, probablemente excluiría el directorio Pods hasta que no esté trabajando en él por un tiempo.

En realidad, debo concluir que podría no ser la mejor persona para responder a su pregunta, en comparación con las opiniones de los usuarios puros :) Enviaré un tweet sobre esta pregunta desde https://twitter.com/CocoaPodsOrg .

aleación
fuente
Me gustaría repetir esto también. Puede usar CocoaPods sin que sus otros desarrolladores necesiten usarlo (aunque deberían hacerlo) marcando la carpeta Pods. Una vez que CocoaPods se vuelve omnipresente, las vainas serán similares a las gemas, las verificaría en los mismos casos en que "vendía" gemas de rubí.
Ben Scheirman
2
Creo que también hay que tener en cuenta que en algún momento los pods o la utilidad de pod (la buena versión) pueden no estar disponibles. Aún más, si dos usuarios con una versión de utilidad de pod diferente ejecutan la utilidad para exactamente el mismo Podspec, la salida puede diferir.
Adrian
1
Pagar, construir y ejecutar es la consideración más importante. ¿Por qué haría que su construcción y su capacidad de construcción dependan de factores externos? Reviso todas las vainas. Puede ahorrarle a otros desarrolladores (o su futuro yo) horas de búsqueda de los pods correctos. Tampoco veo inconvenientes en registrarlos.
n13
18

Reviso todo. ( Pods/y Podfile.lock)

Quiero poder clonar el repositorio y saber que todo funcionará como lo hizo la última vez que utilicé la aplicación.

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

funroll
fuente
44
La otra cosa buena de hacer esto es que después de una actualización, puede mirar el diff antes de registrarse y ver exactamente qué archivos en los pods cambiaron.
funroll
2
Además, su proyecto no requiere que todos sus desarrolladores tengan instalados CocoaPods (lo cual puede ser bueno si desea controlar quién / cómo se agregan y actualizan las dependencias).
Tony Arnold
18

La respuesta a 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 "

Depende o no de su carpeta Pods, ya que los flujos de trabajo varían de un proyecto a otro. Recomendamos que mantenga el directorio de Pods bajo control de origen y no lo agregue a su .gitignore. Pero en última instancia, esta decisión depende de usted:

Beneficios de registrarse en el directorio Pods

  • Después de clonar el repositorio, el proyecto puede construirse y ejecutarse inmediatamente, incluso sin tener CocoaPods instalados en la máquina. No es necesario ejecutar la instalación de pod, y no se necesita conexión a Internet.
  • Los artefactos Pod (código / bibliotecas) siempre están disponibles, incluso si la fuente de un Pod (por ejemplo, GitHub) se desactivara.
  • Se garantiza que los artefactos Pod serán idénticos a los de la instalación original después de clonar el repositorio.

Beneficios de ignorar el directorio Pods

  • El repositorio de control de fuente será más pequeño y ocupará menos espacio.

  • Siempre que las fuentes (por ejemplo, GitHub) para todos los Pods estén disponibles, CocoaPods generalmente puede recrear la misma instalación. (Técnicamente no hay garantía de que ejecutar la instalación del pod recupere y recree artefactos idénticos cuando no se utiliza un SHA de confirmación en el Podfile. Esto es especialmente cierto cuando se usan archivos zip en el Podfile).

  • No habrá conflictos con los que lidiar al realizar operaciones de control de código fuente, como fusionar sucursales con diferentes versiones de Pod.

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

shah1988
fuente
13

Estoy en el campo de los desarrolladores que no registran las bibliotecas, suponiendo que tengamos una buena copia disponible en otra ubicación. 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 copia de las bibliotecas en un lugar seguro. En lugar de (mal) usar el repositorio de código de un proyecto para almacenar dependencias (compiladas o no), creo que la mejor manera de hacerlo es archivar compilaciones. Si utiliza un servidor CI para sus compilaciones (como Jenkins), puede archivar permanentemente cualquier compilación que sea importante para usted. Si realiza todas sus compilaciones de producción en su Xcode local, tenga la costumbre de tomar un archivo de su proyecto para cualquier compilación que necesite conservar. Algo así como: 1. Producto -> Archivo

  1. Distribuir ... Enviar a la tienda de aplicaciones iOS / Guardar para Enterprise o Implementación Ad-hoc / ¿Qué tienes?

  2. Revela tu carpeta de proyecto en Finder

  3. Haga clic derecho y comprima "Cualquiera que sea el proyecto"

Esto proporciona una imagen del proyecto completo, incluida la configuración completa del proyecto y del espacio de trabajo utilizada para compilar la aplicación, así como las distribuciones binarias (como Sparkle, SDK patentados como TestFlight, etc.) ya sea que usen o no CocoaPods.

Actualización: he cambiado de opinión sobre esto y ahora comprometo el Podfile.lockcontrol de fuente. Sin embargo, todavía creo que los pods en sí mismos son artefactos de construcción y deben administrarse como tales fuera del control de la fuente, a través de otro método, como su servidor CI o un proceso de archivo como describí anteriormente.

Alex Nauda
fuente
23
Cocoapods recomienda específicamente registrarse en Podfile.lock: docs.cocoapods.org/guides/working_with_teams.html
cbowns
Interesante. Como se Podfile.lockhornea en los caminos hacia las cápsulas locales, no había considerado agregarlo al control de versiones. Sin embargo, ahora que lo pienso, no es diferente de los cambios locales que hago Podfilepero que nunca me comprometo. Gracias por señalar esto.
Alex Nauda
¿Ha cambiado el enlace de trabajar con equipos? No menciona nada sobre el Podfile.lockarchivo.
ingh.am
44
@ ing0 Creo que el nuevo enlace es este
phi
La ventaja de registrarse en Podfile.lock es que es obvio si alguno de sus pods o sus dependencias se han actualizado.
Tim Potter
11

Prefiero comprometer el Podsdirectorio junto con Podfiley Podfile.lockasegurarme de que cualquier persona de mi equipo pueda verificar la fuente en cualquier momento y que no tengan que preocuparse por nada o hacer cosas adicionales para que funcione.

Esto también ayuda en un escenario en el que ha solucionado 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 se confirman.

Y para ignorar directorios innecesarios:

xcuserdata/
nomann
fuente
10

Debo decir que soy fanático de enviar Pods al repositorio. Seguir un enlace ya mencionado le dará un buen archivo .gitignore para recuperar sus proyectos 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ático de agregar Pods al repositorio es por una razón fundamental que nadie parece estar aprendiendo, ¿qué sucede si una biblioteca de la que nuestro proyecto depende tanto se elimina repentinamente de la web?

  • Tal vez el anfitrión decida que ya no quiere mantener abierta su cuenta de GitHub. Qué 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 cambia la URL del repositorio? Digamos que la persona que sirve el Pod desde su cuenta de GitHub, decide representarse a sí misma bajo un identificador diferente: las URL de sus Pods se romperán.
  • Finalmente otro punto. Digamos que si eres un desarrollador como yo que codifica mucho en un vuelo entre países. Hago un tirón rápido en la rama 'maestra', hago una instalación de pod en esa rama, mientras estoy sentado en el aeropuerto y me preparo para el próximo vuelo de 8 horas. Tengo 3 horas en mi vuelo y me doy cuenta de que necesito cambiar a otra rama ... 'DOH': falta información del Pod que solo está disponible en la rama 'maestra'.

NB ... tenga en cuenta que la rama 'maestra' para el desarrollo es solo para ejemplos, obviamente las ramas 'maestras' en los sistemas de control de versiones, deben mantenerse limpias y desplegables / construibles en cualquier momento

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

Al final del día, si tiene una fecha límite apremiante, un presupuesto ajustado, el tiempo es esencial: debemos ser lo más ingeniosos posible y no perder el tiempo en ideologías estrictas, y en su lugar aprovechar un conjunto de herramientas para trabajar juntos - para hacer nuestras vidas más fáciles, más eficientes.

leewilson86
fuente
2
Esta es una de las mejores respuestas a la pregunta eterna "¿Verifico mis dependencias en el control de origen?". Primero, explica una justificación comercial concreta y real basada en el riesgo para su razonamiento. En segundo lugar, les recuerda a todos que, al final del día, la mejor solución es lo que sea que haga el trabajo y haga que las personas trabajen juntas. Eliminas la religión de la ecuación. ¡Buen trabajo!
Brandon el
8

Al final, depende de usted el enfoque que adopte.

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

Depende o no de su carpeta Pods, ya que los flujos de trabajo varían de un proyecto a otro. Recomendamos que mantenga el directorio de Pods bajo control de origen 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 Dependency Manager, y también es la filosofía detrás de los submódulos de git .

Sin embargo, a veces es posible que desee estar realmente seguro acerca de estado de la técnica de una determinada dependencia, de esa manera usted es el propietario de la dependencia dentro de su proyecto. Por supuesto, hay varios inconvenientes que se aplican si lo hace, pero las preocupaciones no solo se aplican a Cocoapods, sino también a cualquier Gerente de dependencia.

Abajo hay un buen lista de pros / contras hecha por el equipo de Cocoapods, y el texto completo de la cita mencionada anteriormente.

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

zevarito
fuente
8

Depende, personalmente:

Por qué los pods deberían ser parte del repositorio (bajo control de fuente) y no deberían ser ignorados

  • La fuente es idéntica
  • Puedes construirlo de inmediato tal como está (incluso sin los cocoapods)
  • Incluso si se elimina un pod, todavía tenemos su copia (Sí, esto puede suceder y sucedió. En un proyecto antiguo en el que desea un pequeño cambio, necesitaría implementar una nueva biblioteca para poder incluso construir).
  • pods.xcodeprojla configuración también forma parte del control de fuente. Esto significa, por ejemplo, si tiene el proyecto swift 4, pero algunos pods deben estar enswift 3.2 ya que aún no están actualizados, esta configuración se guardará. De lo contrario, el que clonó el repositorio terminaría con errores.
  • Siempre puede eliminar pods del proyecto y ejecutarlo pod install, no se puede hacer lo contrario.
  • Incluso los autores de los Cocoapods lo recomiendan.

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

Jakub Truhlář
fuente
2

Para mí, la mayor preocupación es el futuro a prueba de su fuente. Si planea que su proyecto dure un tiempo y CocoaPods desaparezca o la fuente de una de las cápsulas se caiga, no tiene suerte si intenta construir desde un archivo nuevo.

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

Shawn
fuente
2

Compruebe en las vainas.

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

  • Todas las compilaciones deben ser reproducibles
  • La única forma de garantizar que las compilaciones sean reproducibles es tener el control de todas las dependencias; Por lo tanto, el registro de todas las dependencias es imprescindible.
  • Un nuevo desarrollador que comience desde cero podrá revisar su proyecto y comenzar a trabajar.

¿Por qué?

CocoaPods o cualquier otra biblioteca externa pueden cambiar, lo que puede romper las cosas. O podrían moverse, cambiar de nombre o eliminarse 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 debe corregirse. El desarrollador principal podría ser atropellado por un autobús y su reemplazo debe comenzar rápidamente. Y desearía que el último fuera un ejemplo teórico, pero en realidad sucedió en una startup con la que estaba. Q.E.P.D.

Ahora, de manera realista, realmente no puede verificar TODAS las dependencias. No puede registrar una imagen de la máquina que utilizó para crear compilaciones; no puede verificar la versión exacta del compilador. Y así. Hay límites realistas. Pero registre todo lo que pueda, no hacerlo solo hace que su vida sea más difícil. Y no queremos eso.

Palabra final: las vainas no son artefactos de construcción. Los artefactos de compilación son los que se generan a partir de tus compilaciones. Tu construcción usa Pods, no los genera. Ni siquiera estoy seguro de por qué esto tiene que ser debatido.

n13
fuente
2

Ventajas de no registrarse en el Pods/control de versiones (en orden subjetivo de importancia):

  1. Es mucho más fácil fusionar confirmaciones y revisar diferencias de código. La fusión es una fuente común de problemas en una base de código, y esto le permite concentrarse solo en las cosas que son pertinentes.
  2. Es imposible que algún contribuyente aleatorio edite las dependencias y compruebe los cambios, lo que nunca debería hacer (y nuevamente sería difícil identificar si el diff es masivo). Editar dependencias es una muy mala práctica porque un futuropod install podría ocluir los cambios.
  3. Las discrepancias entre el Podfiley el Pods/directorio se encuentran más rápido entre los compañeros de equipo. Si se registra Pods/y, por ejemplo, actualiza una versión en el Podfile, pero se olvida de ejecutar pod installo registrar los cambios Pods/, le resultará mucho más difícil notar la fuente de la discrepancia. Si Pods/no está registrado, siempre debe ejecutar de pod installtodos modos.
  4. Tamaño de repos menor. Tener una huella de bytes más pequeña es bueno, pero eso no importa mucho en el gran esquema. Más importante aún: tener más cosas en el repositorio también aumenta su carga cognitiva. No hay razón para tener cosas en el repositorio que no deberías mirar. Consulte la documentación (la abstracción) para saber cómo funciona algo, no en el código (la implementación).
  5. Es más fácil discernir cuánto contribuye alguien (ya que sus líneas de código contribuidas no incluirán dependencias que no escribieron)
  6. JARarchivos .venv/(entornos virtuales) y node_modules/nunca se incluyen en el control de versiones. Si fuéramos completamente agnósticos acerca de la pregunta, no registrarse Podssería el predeterminado basado en el precedente.

Contras de no registrarse en elPods/

  1. Debe ejecutar pod installal cambiar de sucursal o revertir confirmaciones.
  2. No puede ejecutar un proyecto simplemente clonando el repositorio. Debe instalar la herramienta de pod, luego ejecutar pod install.
  3. Debe tener una conexión a Internet para ejecutar pod install, y la fuente de los pods debe estar disponible.
  4. Si el propietario de una dependencia elimina su paquete, está en problemas.

En resumen, no incluir el Podsdirectorio es una barrera de protección contra más malas prácticas. Incluir el Podsdirectorio facilita la ejecución del proyecto. Prefiero el primero sobre el segundo. No necesitará informar a cada nueva persona en un proyecto sobre "qué no hacer" si no existe la posibilidad de cometer ciertos errores en primer lugar. También me gusta la idea de tener un control de versión separado para el Podsque alivia las desventajas.

efthimio
fuente
1

En teoría, debería verificar en el directorio Pods. En la práctica, no siempre va a funcionar. Muchos pods superan con creces el límite de tamaño de los archivos github, por lo que si usa github tendrá problemas para verificar en el directorio Pods.

Mate
fuente
1

TL; DR: cuando realiza un seguimiento de la Pods/carpeta, el proyecto es más fácil de recoger. Cuando no lo rastrea, es más fácil mejorar cuando trabaja en equipo.

Aunque la organización Cocoapods nos anima a rastrear el Pods/directorio, dicen que depende de los desarrolladores decidir si lo hacen o no en base a estos pros y contras:  http://guides.cocoapods.org/using/using-cocoapods.html # should-i-check-the-pods-directory-into-source-control

Personalmente, suelo rastrear la Pods/carpeta solo para proyectos en los que ya no trabajaré por un tiempo. De esa manera, cualquier desarrollador puede aprender rápidamente y continuar el trabajo utilizando la versión adecuada de los cocoapods.

Por otro lado, creo que el historial de confirmación se vuelve más limpio y es más fácil fusionar el código y revisar el código de otra persona cuando no está rastreando la Pods/carpeta. Por lo general, configuro la versión de la biblioteca de cocoapod cuando la instalo para asegurarme de que cualquiera pueda instalar el proyecto usando las mismas versiones que yo.

Además, cuando Pods/se rastrea el directorio, todos los desarrolladores tienen que usar la misma versión de Cocoapods para evitar que cambie docenas de archivos cada vez que ejecutamos pod installpara agregar / eliminar un pod.

En pocas palabras : cuando realiza un seguimiento de la Pods/carpeta, el proyecto es más fácil de recoger. Cuando no lo rastreas, es más fácil mejorarlo.

marcelosalloum
fuente
0

Parece que una buena manera de estructurar esto realmente sería tener el directorio "Pods" como un submódulo git / proyecto separado, aquí está el por qué.

  • Tener vainas en el repositorio de su proyecto, cuando trabaja con varios desarrolladores, puede causar diferencias MUY GRANDES en las solicitudes de extracción donde es casi imposible ver el trabajo real que fue cambiado por las personas (piense que varios cientos de miles de archivos cambiaron para bibliotecas, y solo un pocos cambiaron 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 resuelve eso.

jaredpetker
fuente
0

Depende o no de su carpeta Pods, ya que los flujos de trabajo varían de un proyecto a otro. Recomendamos que mantenga el directorio de Pods bajo control de origen y no lo agregue a su .gitignore. Pero en última instancia, esta decisión depende de usted:

Beneficios de registrarse en el directorio Pods

  1. Después de clonar el repositorio, el proyecto puede construirse y ejecutarse inmediatamente, incluso sin tener CocoaPods instalados en la máquina. No es necesario ejecutar la instalación de pod, y no se necesita conexión a Internet.
  2. Los artefactos Pod (código / bibliotecas) siempre están disponibles, incluso si la fuente de un Pod (por ejemplo, GitHub) se desactivara.
  3. Se garantiza que los artefactos Pod serán idénticos a los de la instalación original después de clonar el repositorio.

Beneficios de ignorar el directorio Pods

  1. El repositorio de control de fuente será más pequeño y ocupará menos espacio. Mientras las fuentes (p. Ej., GitHub) estén disponibles para todos los Pods, CocoaPods generalmente puede recrear la misma instalación. Esto es especialmente cierto cuando se usan archivos zip en el Podfile).
  2. No habrá conflictos con los que lidiar al realizar operaciones de control de código fuente, como fusionar sucursales con diferentes versiones de Pod. Ya sea que ingrese o no en el directorio de Pods, Podfile y Podfile.lock siempre deben mantenerse bajo control de versión.
Sourabh Mahna
fuente
Puede usar este enlace para cualquier duda: guides.cocoapods.org/using/…
Sourabh Mahna