Lo que pasa en tu .gitignore si usted está usando CocoaPods?

https://stackoverflow.com/questions/9446644

12-11-2019
|

Pregunta

He estado haciendo el desarrollo de iOS para un par de meses y sólo se enteró de la prometedor CocoaPods biblioteca para la gestión de la dependencia.

He probado en un proyecto personal:añade una dependencia a Kiwi a mi Podfile, corrió pod install CocoaPodsTest.xcodeproj, y voila, funcionó muy bien.

Lo que me preguntan es:lo que hago el check-in, y lo que yo ignore para el control de versiones?Parece obvio que quiero ver en el Podfile sí mismo, y probablemente el .archivo xcworkspace así;pero hacer caso omiso de las Vainas/ directorio?Hay otros archivos que se generarán por la carretera (cuando puedo añadir otras dependencias) que también debo agregar a mi .gitignore?

Solución

Personalmente, no verifico en el directorio de la vaina y los contenidos.No puedo decir que pasé mucho tiempo teniendo en cuenta las implicaciones, pero mi razonamiento es algo así como:

El podfile se refiere a una etiqueta específica o una confirmación de cada dependencia para que las máquinas propias se puedan generar desde el podfile, Ergo son más como un producto de compilación intermedio que una fuente y, por lo tanto, no necesita control de la versión enmi proyecto.

Otros consejos

Confito mi directorio de la vaina. No estoy de acuerdo en que el directorio de PODS es un artefacto de construcción. De hecho, lo diría que definitivamente no lo es. Es parte de su fuente de solicitud: ¡no se construirá sin ella!

Es más fácil pensar en COOPODS como herramienta de desarrollador en lugar de una herramienta de compilación. No construye su proyecto, simplemente se clones e instala sus dependencias para usted. No debería ser necesario que se instalen COOPODS para poder simplemente construir su proyecto.

Al hacer que COAPODS sea una dependencia de su construcción, ahora debe asegurarse de que esté disponible en todas partes, es necesario que deba crear su proyecto ... Un administrador de equipo lo necesita, su servidor CI lo necesita. Debe, por regla general, siempre puede clonar su repositorio de origen y construir sin más esfuerzo.

No comprometer su directorio PODS también crea un dolor de cabeza masivo si con frecuencia cambia las sucursales. Ahora necesita ejecutar la instalación de POD cada vez que cambie las sucursales para asegurarse de que sus dependencias sean correctas. Esto podría ser menos molesto, ya que sus dependencias se estabilizan, pero al principio de un proyecto, este es un disfraz de tiempo masivo.

Entonces, ¿qué ignoro? Nada. Podfile, el archivo de bloqueo y el directorio de la vaina se comprometen todos. Confía en mí, te ahorrará mucha molestia. ¿Cuáles son los contras? ¿Un repo ligeramente más grande? No es el fin del mundo.

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

El Podfile debe siempre bajo control de código fuente.
El Podfile.lock debe siempre bajo control de código fuente.
El área de trabajo generados por CocoaPods debe se mantendrá bajo control de código fuente.
Cualquier Vaina que se hace referencia con el :path opción debe se mantendrá bajo control de código fuente.
El ./Pods carpeta puede se mantendrá bajo control de código fuente.

Para más información puede referirse a la guía oficial.

fuente:Yo soy un miembro de la CocoaPods equipo básico, como @aleación

A pesar de las Vainas de la carpeta es construir un artefacto que hay razones que usted podría considerar al decidir si para mantenerla bajo control de código fuente:

CocoaPods no es un gestor de paquetes para la fuente original de la biblioteca podría ser eliminado en el futuro por el autor.
Si las Vainas de la carpeta se incluye en el control de código fuente, no es necesario instalar CocoaPods para ejecutar el proyecto como la caja sería suficiente.
CocoaPods es todavía un trabajo en progreso y hay opciones que no siempre conducen al mismo resultado (por ejemplo, el :head y el :git las opciones actualmente no está utilizando el cometa almacenados en la Podfile.lock).
Hay menos puntos de falla si podría volver a trabajar en un proyecto después de un medio/largo período de tiempo.

.archivo gitignore

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

La comprobación en las Vainas de directorio (Beneficios)

Xcode/iOS amable git ignorar, omitir Mac OS archivos de sistema, Xcode, construye, 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/

Ignorando las Vainas directorio (Beneficios)

.gitignore: (anexar a la lista anterior)

# Cocoapods
Pods/

Si o no usted comprobar en las Vainas de directorio, el Podfile y Podfile.cerradura debe estar siempre bajo el control de versiones.

Si Pods no facturado, su Podfile probablemente debería petición explícita de los números de versión para cada Cocoapod.Cocoapods.org discusión aquí.

Generalmente trabajo en la aplicación de los clientes.En ese caso, también agrego el directorio de la vaina al repositorio, para asegurarse de que en un momento dado, cualquier desarrollador pueda hacer un pago y construir y ejecutar.

Si fuera una aplicación propia, probablemente excluiría el directorio de la vaina 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, frente a las vistas de los usuarios puros :) Volveré a través de esta pregunta de https://twitter.com/cocoapodsorg .

La respuesta para esto se da directamente en COAPOD DOCS. Puede ver " http://guides.cocoapods.org/using/using-cocoapods.html#should-i-igore-the-pods-directory-in-source-control "

Si usted verifica o no en su carpeta PODS depende de usted, como Los flujos de trabajo varían de un proyecto al proyecto. Le recomendamos que guarde el Directorio de vástagos bajo control de la fuente, y no lo agregue a su .gitignore. Pero en última instancia, esta decisión depende de usted:
Beneficios de verificar el directorio de la vaina

Después de clonar el repositorio, el proyecto puede construir y ejecutar de inmediato, incluso sin tener COCOAPODS instalados en la máquina. No hay Necesidad de ejecutar la instalación de la vaina, y no es necesaria ninguna conexión a Internet.
Los artefactos de la vaina (código / bibliotecas) están siempre disponibles, incluso si la fuente de un pod (por ejemplo, GitHub) debía bajar.
Se garantiza que los artefactos POD son idénticos a los de la instalación original después de clonar el repositorio.
Beneficios de ignorar el directorio de la vaina

El repo de control de origen será menor y ocupará menos espacio.

Mientras las fuentes (por ejemplo, GitHub) para todas las vainas estén disponibles, COOPODS generalmente puede recrear la misma instalación. (Técnicamente, no hay garantía de que la instalación de la POD de ejecución se recupere y recrear artefactos idénticos al no usar un comité SHA en el PODFILE. Esto es especialmente cierto cuando se utiliza archivos ZIP en el podfile.)

No habrá ningún conflicto para enfrentar al realizar las operaciones de control de la fuente, como fusionar ramas con una vaina diferente versiones.
Si lo registra o no en el directorio de la vaina, el podfile y Podfile.lock debe mantenerse siempre bajo control de la versión.

VERIFICO EN TODO.(Pods/ y Podfile.lock.)

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

Prefiero proveedor de las cosas que en el riesgo de tener resultados diferentes que podrían ser causados por una versión diferente de la GEM, o alguien que reescribe el historial en el repositorio de la POD, etc.

Estoy en el campamento de los desarrolladores que no se marque en las bibliotecas, suponiendo que tenemos una buena copia disponible en otro lugar.Así que, en mi .gitignore me incluir las siguientes líneas específicas de CocoaPods:

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

Luego de asegurarme de que tenemos una copia de las bibliotecas en un lugar seguro.En lugar de (mal)uso de un código del proyecto repositorio para almacenar las dependencias (compilado o no) creo que la mejor manera de hacer esto es compilaciones de archivos.Si utiliza un servidor CI para la construye (como Jenkins) puede permanentemente cualquier archivo crea que son importantes para usted.Si hacen todo lo que su producción se basa en su local de Xcode, hacer un hábito de tomar un archivo de su proyecto para cualquier construye usted necesita para mantener.Algo así como:1.Producto --> Archivo

Distribuir...Presentar a la App Store de iOS / Guardar para la Empresa o Ad-hoc de Implementación / ¿qué has
Revelan la carpeta del proyecto en el Finder
Haga clic derecho y Comprimir "WhateverProject"

Esto proporciona una imagen integrada de la totalidad del proyecto, incluyendo el proyecto completo y área de trabajo de la configuración utilizada para construir la aplicación, así como las distribuciones binarias (tales como Brillo, de propiedad Sdk como TestFlight, etc.) sea o no el uso de CocoaPods.

Actualización: He cambiado mi opinión sobre esto y ahora hacer el commit de la Podfile.lock control de código fuente.Sin embargo, todavía creo que las vainas de sí mismos son artefactos de compilación y deben ser manejados como tales fuera de control de código fuente, a través de otro método, como su servidor CI o un archivo de proceso como describo arriba.

Prefiero cometer el directorio Pods junto con Podfile y Podfile.lock para asegurarse de que cualquiera en mi equipo pueda pagar la fuente en cualquier momento y no tienen que preocuparse por nada o hacer cosas adicionales para que funcione.

Esto también ayuda en un escenario donde ha solucionado un error dentro de una de las vainas o modificó algún comportamiento según sus necesidades, pero estos cambios no estarán disponibles en otras máquinas si no se comprometen.

e ignorar los directorios innecesarios:

xcuserdata/

Debo decir, soy un fanático de cometer pods al repositorio. Siguiendo un enlace ya mencionado, le dará un buen archivo .gitignore para obtener sus proyectos de Xcode para que iOS permita las vainas, pero también para que lo excluya fácilmente si lo desea: https://github.com/github/gitignore/blob/master/objetive-c.gitignore

Mi razonamiento para ser un fanático de la adición de vainas al repositorio es para una razón fundamental para la cual nadie parece estar recogiendo, ¿qué sucede si una biblioteca de la que nuestro proyecto depende de la web se elimina repentinamente de la web?

Tal vez el anfitrión decide que ya no quieren mantener su GitHub Cuenta Abrir lo que sucede si la biblioteca dice varios años. (Como más de 5 años, por ejemplo) hay un alto riesgo de El proyecto ya no puede estar disponible en la fuente
también otro punto, qué sucede si la URL al repositorio ¿cambios? Digamos que la persona que sirve a la vaina de su GitHub. Cuenta, decide representarse bajo un asa diferente. Las URL de las vainas se van a romper.
finalmente otro punto. Di si eres un desarrollador como yo que hace mucho de codificación cuando está en un vuelo entre países. Hago un truco rápido La sucursal 'Master', haz un pod instalación en esa rama, mientras está sentado En el aeropuerto y me dividen todo para las próximas 8 horas. vuelo. Tengo 3 horas en mi vuelo y me doy cuenta de que necesito cambiar a Otra sucursal ... 'DOH': información que falta la información que solo está disponible en la sucursal 'Master'.
nb ... Tenga en cuenta que la sucursal 'master' para el desarrollo es solo para ejemplos, obviamente, las sucursales "maestras" en los sistemas de control de versiones, deben mantenerse limpios y desplegables / acumulables en cualquier momento
Pienso en estos, las instantáneas en los repositorios de su código son ciertamente mejores que ser estrictos en el tamaño del repositorio. Y como ya se mencionó, el archivo PODFILE.LOCK, mientras que la versión controlada le dará una buena historia de las versiones de su podación.
Al final del día, si tiene una fecha límite, un presupuesto ajustado, el tiempo es de la esencia, debemos ser lo más ingeniosos posible y no perder el tiempo en ideologías estrictas, y en su lugar aprovechamos un conjunto de herramientas Trabajar juntos, para que nuestras vidas sean más eficientes más fáciles.

Al final depende de usted el enfoque que tome.

Esto es lo que el equipo de Cocoapods piensa en ello:

Si usted verifica o no en su carpeta PODS depende de usted, como Los flujos de trabajo varían de un proyecto al proyecto. Le recomendamos que guarde el Directorio de vástagos bajo control de la fuente, y no lo agregue a su .gitignore. Pero en última instancia, esta decisión depende de usted.
Si estuviera usando Bower . Esto se aplica a casi cualquier gerente de dependencia por ahí, y es la filosofía detrás de los submódulos de Git también.
Sin embargo, a veces, es posible que desee estar realmente seguro de la estado de la técnica de cierta dependencia, de esa manera que usted tiene su propia dependencia dentro de su proyecto. Por supuesto, hay varios inconvenientes que se aplican si hace eso, pero las preocupaciones no solo se aplican a COAPODS, aquellos se aplica a ningún administrador de dependencia por ahí.
A continuación, hay una lista de Good Pros / Contras realizada por el equipo de COCOAPODS, y el texto completo de la cotización mencionada anteriormente.
Equipo de COCOAPODS: ¿Debo revisar el directorio de la vaina en el control de origen?

Depende, personalmente:

¿Por qué las vainas deben ser parte de la repo (bajo control de código fuente) y no debe ser ignorada

La fuente es idéntico
Usted puede construir de inmediato, como es (incluso sin la cocoapods)
Incluso si un pod es eliminado, todavía tiene su copia (Sí, esto puede suceder y lo hizo.En un viejo proyecto en el que desea sólo un pequeño cambio podría ser necesario implementar una nueva biblioteca para ser capaz de construir).
pods.xcodeproj los ajustes son parte de la fuente de control.Esto significa, por ejemplo,si usted tiene el proyecto en swift 4, pero algunas vainas deben ser en swift 3.2 porque no se actualizan sin embargo, estos ajustes se guardarán.De lo contrario, el que clonado de la repo acabaría con errores.
Siempre puedes eliminar las vainas del proyecto y ejecutar pod install, el contrario no puede ser hecho.
Incluso el los autores de la Cocoapods recomiendo.

Algunas desventajas:mayor repositorio, confuso diffs (principalmente para los miembros del equipo), potencialmente más conflictos.

Para mí, la mayor preocupación es la prueba futura de su fuente.Si planea que su proyecto dure un rato y los cocoapods se desaparecen.

Esto podría mitigarse con archivales de origen completo periódico.

verificar en las vainas.

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

todas las compilaciones deben ser reproducibles
La única forma de garantizar las compilaciones son reproducible es estar en control de todas las dependencias; comprobando en todos Por lo tanto, las dependencias son una necesidad.
Un nuevo desarrollador a partir de cero podrá verificar su proyecto y comenzar a trabajar.
¿Por qué?
COCOAPODS o cualquier otra biblioteca externa puede cambiar que podría romper las cosas. O pueden moverse, o ser renombrado, o ser eliminado por completo. No puedes confiar en Internet para guardar las cosas para ti. Su computadora portátil podría haber muerto y hay un error crítico en la producción que debe ser fijo. El principal desarrollador podría ser golpeado por un autobús y su reemplazo tiene que comenzar a tener prisa. Y deseo que el último fue un ejemplo teórico, pero en realidad sucedió en una startup con la que estaba. RIP.
ahora, de manera realista, realmente no puede verificar todas las dependencias. No se puede verificar una imagen de la máquina que solía crear compilaciones; No se puede verificar la versión exacta del compilador. Etcétera. Hay límites realistas. Pero compruebe 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. Los artefactos de construcción son lo que se genera de tus compilaciones. Tu compilación usa vainas, no generarlas. Ni siquiera estoy seguro de por qué esto debe ser debatido.

En teoría, debe registrarse en el directorio de la vaina.En la práctica, no siempre va a funcionar.Muchas vainas superan bien el límite de tamaño de los archivos GitHub, por lo que si está utilizando GitHub, tendrá problemas de verificación en el directorio de la vaina.

Pros de no comprobación en Pods/ para el control de versiones (en la subjetiva orden de importancia):

Mucho más fácil de combinar comete, y revisar el código diffs.La fusión es una fuente común de problemas en una base de código, y esto le permite centrarse sólo en las cosas que son pertinentes.
Es imposible para algunos al azar contribuyente para editar las dependencias de sí mismos y comprobar los cambios, algo que nunca debe hacer (y de nuevo sería difícil de identificar si la diferencia es enorme).La edición de las dependencias es muy mala práctica porque un futuro pod install podría ocluir los cambios.
Las discrepancias entre el Podfile y el Pods/ directorio se encuentran más rápido entre compañeros de equipo.Si usted llega en Pods/ y, por ejemplo, la actualización de una versión en la Podfile, pero se olvidan de ejecutar pod install o comprobar los cambios a Pods/, usted tendrá un tiempo mucho más difícil darse cuenta de la fuente de la discrepancia.Si Pods/ no facturado, siempre se necesita para ejecutar pod install de todos modos.
Menor repo tamaño.Tener un menor tamaño en bytes de la huella es agradable, pero eso no importa mucho en el gran esquema.Lo que es más importante:tener más cosas en la repo también aumenta su carga cognitiva.No hay ninguna razón para tener las cosas en la repo que no se debe mirar.Consulte la documentación (la abstracción) para saber cómo funciona algo, no en el código (la aplicación).
Más fácil de discernir cuánto contribuye a alguien (ya que sus líneas de código contribuido no incluyen las dependencias de no escribir)
JAR archivos, .venv/ (entornos virtuales), y node_modules/ nunca están incluidos en la versión de control.Si estábamos completamente agnóstico acerca de la pregunta, no comprobación en Pods sería el valor por defecto con base en los precedentes.

Contras de no la comprobación de la Pods/

Debe ejecutar pod install cuando la conmutación de las ramas, o volver comete.
No se puede ejecutar un proyecto que acabo de clonando el repositorio.Debe instalar el sensor de la herramienta, a continuación, ejecute pod install.
Usted debe tener una conexión a internet para ejecutar pod install, y la fuente de las vainas debe estar disponible.
Si el titular de una dependencia quita su paquete, usted está en problemas.

En resumen, no incluidos el Pods el directorio es una barrera de protección contra las malas prácticas. Incluyendo el Pods directorio hace que el proyecto sea más fácil.Yo prefiero los primeros sobre los segundos.Usted no tendrá que estudiar a cada persona nueva en un proyecto acerca de "lo que no para hacer" si no hay una posibilidad de hacer que ciertos errores en el primer lugar.También me gusta la idea de tener un control de versiones para el Pods que alivia a los Contras.

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

Tener cápsulas en el repositorio de su proyecto, cuando se trabaja con varios desarrolladores, puede causar diferentes diferencias en las solicitudes de tracción donde es casi imposible ver el trabajo real que cambió las personas (piense que varios cientos a miles de archivos cambiaronpara las bibliotecas, y solo unos pocos cambiaron en el proyecto real).
Veo el problema de no cometer nada para git, ya que la persona que posee la biblioteca podría derribarla en cualquier momento y esencialmente eres sol, esto también resuelve eso.

Si lo registra o no en su carpeta PODS depende de usted, ya que los flujos de trabajo varían de un proyecto al proyecto. Le recomendamos que mantenga el directorio de la vaina bajo el control de la fuente, y no lo agregue a su .gitignore. Pero en última instancia, esta decisión depende de usted:

Beneficios de verificar el directorio de la vaina

Después de clonar el repositorio, el proyecto puede construir y ejecutar de inmediato, incluso sin tener COCOAPODS instalados en la máquina. No es necesario ejecutar la instalación de POD, y no es necesaria ninguna conexión a Internet.
Los artefactos de la vaina (código / bibliotecas) están siempre disponibles, incluso si la fuente de un pod (por ejemplo, GitHub) debía bajar.
Se garantiza que los artefactos POD son idénticos a los de la instalación original después de clonar el repositorio.
Beneficios de ignorar el directorio de la vaina
1. El repo de control de origen será menor y ocupará menos espacio. Mientras se estén disponibles las fuentes (por ejemplo, GitHub) para todas las vainas, los COOPODS generalmente pueden recrear la misma instalación. (Técnicamente, no hay garantía de que la instalación de POD de ejecución recuperará y recreara artefactos idénticos al usar un SHA de confirmación en el podfile. . Esto es especialmente cierto cuando se usa archivos ZIP en el podfile).
2. No habrá ningún conflicto para tratar al realizar operaciones de control de origen, como fusionar ramas con diferentes versiones de POD. Ya sea que registre o no en el directorio de la vaina, el PODFILE y PODFILE.LOCK SIEMPRE debe mantenerse en control de la versión.

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

Aunque la Cocoapods organización nos animan a seguir el Pods/ directorio, dicen los devs para decidir si desea o no hacer sobre la base de estos pros y contras:http://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control

Personalmente, me siguen generalmente el Pods/ carpeta de proyectos que no voy a estar trabajando en más de un tiempo.De esa manera, cualquier desarrollador puede recoger rápidamente de ella y continuar con el trabajo utilizando la versión correcta de la cocoapods.

Por otro lado, creo que el cometer la historia se pone más limpio y es más fácil combinar el código y revisión de otra persona en el código cuando usted no está en el seguimiento de la Pods/ carpeta.Por lo general establecer la cocoapod de la biblioteca de la versión cuando instalo para asegurarse de que cualquier persona puede instalar el proyecto, utilizando las mismas versiones como I.

También, cuando el Pods/ directorio está realizando un seguimiento de todos los desarrolladores tienen que usar la misma versión de Cocoapods para evitar que el cambio de docenas de archivos cada vez que se ejecute pod install para agregar o quitar una vaina.

Línea de fondo:cuando realiza un seguimiento de la Pods/ carpeta, el proyecto es más fácil de recoger.Cuando no se seguir, es más fácil mejorar.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow