objective-c - add pods to gitignore

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

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 de Kiwi a mi Podfile, ejecuté el pod install CocoaPodsTest.xcodeproj y, voila , funcionó muy bien.

Lo único que me pregunto es: ¿qué debo comprobar y qué debo ignorar para el control de versiones? Parece obvio que quiero verificar el archivo Pod, y probablemente también el archivo .xcworkspace; ¿Pero ignoro el directorio Pods /? ¿Hay otros archivos que se generarán en el futuro (cuando agregué otras dependencias) que también debería agregar a mi .gitignore?

archivo .gitignore

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

Comprobación en el directorio de Pods ( Benefits )

Compatible con Xcode / iOS 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/

Ignorando el directorio de Pods ( Benefits )

.gitignore: (anexar a la lista anterior)

# Cocoapods Pods/

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

Si los Pods no están registrados, su Podfile probablemente debería solicitar números de versión explícitos para cada Cocoapod. Cocoapods.org debate here .

Al final depende de ti el enfoque que tomes.

Esto es lo que piensa el equipo de Cocoapods:

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

Personalmente me gustaría mantener a Pods fuera, como node_modules si estuviera usando Node o bower_components si estuviera usando Bower . Esto se aplica a casi cualquier Gerente de dependencia, 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 sobre el estado del arte de una determinada dependencia, de esa manera usted es dueño 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 los Cocoapods, sino que también se aplican a cualquier Gerente de dependencia.

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

here

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 compilaciones sean reproducibles es tener el control de todas las dependencias; Verificar todas las dependencias es por lo tanto un deber.
Un nuevo desarrollador que comience desde cero podrá revisar su proyecto y comenzar a trabajar.

¿Por qué?

CocoaPods o cualquier otra biblioteca externa puede cambiar y romper cosas. O podrían moverse, cambiarse de nombre o eliminarse por completo. No puedes confiar en internet para almacenar cosas para ti. Su computadora portátil podría haber muerto y hay un error crítico en la producción que necesita ser arreglado. El desarrollador principal puede ser golpeado por un autobús y su reemplazo tiene que arrancar a toda prisa. Y desearía que el último fuera un ejemplo teórico, pero en realidad sucedió en una startup con la que estuve. DEP.

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

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

Confirmo mi directorio de Pods. No estoy de acuerdo con que el directorio de Pods sea un artefacto de construcción. De hecho, diría que definitivamente no lo es. Es parte de su fuente de aplicación: ¡no se construirá 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 CocoaPods instalado para poder simplemente construir su proyecto.

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

No cometer su directorio Pods también crea un dolor de cabeza masivo si cambia de rama con frecuencia. Ahora debe ejecutar la instalación del pod cada vez que cambie de sucursal para asegurarse de que sus dependencias sean correctas. Esto podría ser menos problemático ya que sus dependencias se estabilizan, pero al principio de un proyecto, este es un sumidero masivo de tiempo.

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

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

Mi razonamiento para ser un fan de agregar Pods al repositorio es por una razón fundamental que nadie parece estar captando, ¿qué sucede si una biblioteca de la que depende tanto nuestro proyecto se retira 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 (como 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. Di si eres un desarrollador como yo que hace mucha codificación en un vuelo entre países. Hago un tirón rápido de 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. Consigo 3 horas en mi vuelo y me doy cuenta de que necesito cambiar a otra rama ... ''DOH'': falta la 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 un ejemplo, obviamente las ramas ''maestras'' en los sistemas de control de versiones, deben mantenerse limpias e implementables en cualquier momento

Creo que a partir de estas, las instantáneas en tus repositorios de código son ciertamente mejores que ser estrictas en el 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 Pod.

Al final del día, si tiene una fecha límite urgente, 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 debemos aprovechar un conjunto de herramientas para trabajar juntos - Para hacer nuestras vidas más fáciles y eficientes.

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

Beneficios de registrarse en el directorio Pods

Después de clonar el repositorio, el proyecto puede construirse y ejecutarse inmediatamente, incluso sin tener CocoaPods instalado en la máquina. No es necesario ejecutar la instalación del pod, y no se necesita conexión a Internet.
Los artefactos del Pod (código / bibliotecas) siempre están disponibles, incluso si la fuente de un Pod (por ejemplo, GitHub) fuera a caer.
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 Pods

El repositorio de control de fuente será más pequeño y ocupará menos espacio. Siempre y cuando 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 la instalación del pod ejecutable vaya a buscar y recrear artefactos idénticos cuando no se use un SHA de confirmación en el Podfile . Esto es especialmente cierto cuando se usan archivos zip en el Podfile.)
No habrá ningún conflicto con el que lidiar al realizar operaciones de control de origen, como la combinación de sucursales con diferentes versiones de Pod. Ya sea que verifique o no en el directorio de Pods, Podfile y Podfile.lock siempre deben mantenerse bajo el control de versión.

Depende, personalmente:

¿Por qué los pods deben formar parte del repositorio (bajo control de código fuente) y no deben ignorarse?

La fuente es identica
Puede construirlo de inmediato tal como está (incluso sin los cocoápodos)
Incluso si se elimina un pod, todavía tenemos su copia (Sí, esto puede suceder y sucedió. En un proyecto anterior en el que solo desea un pequeño cambio, necesitará implementar una nueva biblioteca para poder incluso construir).
pods.xcodeproj ajustes de pods.xcodeproj forman parte del control de origen. Esto significa, por ejemplo, si tiene el proyecto en swift 4 , pero algunos pods deben estar en swift 3.2 porque aún no están actualizados, se guardarán estas configuraciones. De lo contrario, el que clonó el repositorio terminaría con errores.
Siempre puede eliminar pods del proyecto y ejecutar 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 miembros del equipo), potencialmente más conflictos.

En teoría, deberías revisar 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 tanto, si está utilizando github, tendrá problemas para revisar el directorio de Pods.

Estoy en el campamento de desarrolladores que no ingresan en las bibliotecas, asumiendo que tenemos 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 que tengamos 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 las compilaciones. Si usa un servidor CI para sus compilaciones (como Jenkins), puede archivar permanentemente las compilaciones que sean importantes para usted. Si realiza todas las compilaciones de producción en su Xcode local, adquiera el hábito de tomar un archivo de su proyecto para cualquier compilación que necesite conservar. Algo como: 1. Producto -> Archivo

Distribuir ... Enviar a la tienda de aplicaciones iOS / Guardar para la implementación empresarial o Ad-hoc / ¿Qué tiene usted?
Revela tu carpeta de proyectos en Finder
Haz clic derecho y comprime "WhateverProject"

Esto proporciona una imagen según la construcción del proyecto completo, incluida la configuración completa del proyecto y del área de trabajo utilizada para compilar 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 al respecto y ahora Podfile.lock el Podfile.lock en el control de origen. Sin embargo, sigo creyendo que los pods en sí mismos son artefactos de compilación y deben administrarse como tales fuera del control de código fuente, a través de otro método como su servidor de CI o un proceso de archivo como el descrito anteriormente.

Generalmente trabajo en aplicaciones de clientes. En ese caso, también agrego el directorio de Pods al repositorio, para garantizar que en cualquier momento cualquier desarrollador pueda realizar un proceso de pago y creación y ejecución.

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

En realidad, debo concluir que podría no ser la mejor persona para responder tu pregunta, en lugar de las opiniones de los usuarios puros :) Enviaré tweets sobre esta pregunta desde https://twitter.com/CocoaPodsOrg .

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 "

Depende de usted si controla o no su carpeta Pods, ya que los flujos de trabajo varían de un proyecto a otro. Le recomendamos que mantenga el directorio de Pods bajo el control de código fuente y no lo agregue a su .gitignore. Pero en última instancia esta decisión depende de ti:
Beneficios de registrarse en el directorio Pods
Después de clonar el repositorio, el proyecto puede construirse y ejecutarse inmediatamente, incluso sin tener CocoaPods instalado en la máquina. No es necesario ejecutar la instalación del pod, y no se necesita conexión a Internet.
Los artefactos del Pod (código / bibliotecas) siempre están disponibles, incluso si la fuente de un Pod (por ejemplo, GitHub) fuera a caer.
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 Pods
El repositorio de control de fuente será más pequeño y ocupará menos espacio.
Mientras 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 la ejecución de la instalación del pod pueda recuperar y recrear artefactos idénticos cuando no se usa un SHA de confirmación en el Podfile. Esto es especialmente cierto cuando se usan archivos zip en el Podfile).
No habrá ningún conflicto con el que lidiar al realizar operaciones de control de origen, como la combinación de sucursales con diferentes versiones de Pod.
Ya sea que verifique o no en el directorio de Pods, Podfile y Podfile.lock siempre deben mantenerse bajo el control de versión.

Me registro en todo. ( Pods/ y Podfile.lock .)

Quiero poder clonar el repositorio y saber que todo funcionará igual que la última vez que usé la aplicación.

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

Para mí, la mayor preocupación es la prueba futura de su fuente. Si planea que su proyecto dure por un tiempo y CocoaPods desaparezca o la fuente de uno de los pods desaparezca, no tiene suerte si trata de construir desde un archivo.

Esto podría ser mitigado con archivos de fuente completos periódicos.

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

Al trabajar con varios desarrolladores, los pods cuando se trabaja con varios desarrolladores pueden causar DIFERENTES diferencias en las solicitudes de extracción en las que es casi imposible ver el trabajo real que ha cambiado la gente (piense que se han cambiado varios cientos a miles de archivos para bibliotecas, y solo un pocos modificados en el proyecto actual).
Veo el problema de no cometer nada con git, ya que la persona que posee la biblioteca podría eliminarlo en cualquier momento y usted es esencialmente SOL, esto también lo resuelve.

Personalmente no verifico en el directorio de Pods y contenidos. No puedo decir que pasé largas edades considerando 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, por lo que los Pods en sí pueden generarse desde el podfile, por lo que se parecen más a un producto de compilación intermedia que a una fuente y, por lo tanto, no necesitan control de versión en mi proyecto.

Prefiero comprometer el directorio de Pods junto con Podfile y Podfile.lock para asegurarme de que cualquier persona de mi equipo pueda verificar la fuente en cualquier momento y no tenga que preocuparse por nada o hacer cosas adicionales para que funcione.

Esto también ayuda en un escenario donde se corrigió un error dentro de uno de los pods o se modificó 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/

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

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

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 desea mantenerla bajo control de código fuente:

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 origen, no es necesario instalar CocoaPods para ejecutar el proyecto, ya que la verificación sería suficiente.
CocoaPods todavía está en progreso y hay opciones que no siempre conducen al mismo resultado (por ejemplo, las opciones :head y :git actualmente no están utilizando las confirmaciones almacenadas en 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.