Fusionando archivos de proyecto de Xcode …

A todos los IDE les gusta contaminar nuestros espacios de trabajo con su propia marca de archivos de seguimiento. Eclipse, intelliJ, xCode, appCode, etc. Todos son bastante desagradables cuando se trata de esto, sin embargo xCode realmente hizo todo lo posible para hacernos la vida miserable.

Así que mi consejo profesional … Cómo navegar por el mundo de la fusión de archivos de proyecto xCode.


Primero es lo fácil (para gitignore ver aquí )

Suponiendo que está usando vainas de cacao (realmente debería hacerlo :))
1. Use GIT (o cualquier DVCS. La fusión simplemente no se recomienda para sistemas VCS)
2. Agregue el directorio * .xcworkspace a su archivo gitignore
3. Agregue el * .xcodeproj / xcuserdata directorio a su archivo gitignore
4. Agregue todos los demás archivos a GIT
5. Marque todos los esquemas que no se generan localmente como “compartidos” (si usa cocoapods, terminará de generar un nuevo esquema localmente)

Ahora las cosas interesantes

El problema
Toda la información del proyecto está contenida en un archivo enorme llamado project.pbxproject. Puede encontrar esto en el directorio xcodeproj. Suponiendo que está en un equipo de 5 a 6 desarrolladores, todos están agregando clases, configurando el indicador del compilador, agregando recursos, etc. y cada uno de estos cambios termina en el archivo pbxproject.
Este es un gran problema para un equipo de desarrollo, ya que significa que todos están editando este archivo enorme. (Imagínese a todos trabajando en una clase masiva).
Para empeorar las cosas, este no es un archivo particularmente amigable para los humanos, por lo que profundizar e intentar resolver manualmente los conflictos de fusión no es tan simple sin algunos.

The Issues
pbxproject background
Es un plist de estilo antiguo tomado de Nexus (Eso es, empresa de Steve Jobs). Apple mantiene el formato del archivo en privado, sin embargo, una rápida búsqueda en Google proporciona vislumbres de lo que significa el archivo.

  1. Problema 1 (nuevas clases agregadas al proyecto) Agregar 2 clases “ClassE” y “ClassF” le dará un conflicto de fusión que no se puede manejar automáticamente

código

<<<<<<< HEAD
F73BAAD4166D710400F255CD /* ClassF.m in Sources */ = {isa = PBXBuildFile; fileRef = F73BAAD3166D710400F255CD /* ClassF.m */; };

=======

F73BAAD0166D70F400F255CD /* ClassE.m in Sources */ = {isa = PBXBuildFile; fileRef = F73BAACF166D70F400F255CD /* ClassE.m */; };

>>>>>>> 501df570c086e7cacf3847270d7f197339e5595f

Este fragmento es solo uno de los 4 conflictos producidos por 2 desarrolladores que agregan una sola clase al proyecto.
Muchos entran en pánico cuando ven esto, ya que el número parece aleatorio. Sin embargo, esto es realmente muy fácil de resolver. Los números de esta muestra son solo un UUID. Esto significa que se garantiza que serán únicos a nivel mundial (es decir, que nunca volverán a ser los mismos). No importa cuántas personas estén trabajando en el proyecto. No importa cuántas clases se agreguen, estos números siempre son únicos.
Lo que esto significa es que para este conflicto puede eliminar de forma segura los marcadores de combinación de GIT y este conflicto se resolverá.

  1. Problema 2 (Conflictos reales) La mayoría de los conflictos reales son en realidad muy fáciles de resolver. Toma el siguiente ejemplo

código

<<<<<<< HEAD
IPHONEOS_DEPLOYMENT_TARGET = 6.0;

=======

IPHONEOS_DEPLOYMENT_TARGET = 4.3;

>>>>>>> 92e40f741eb04a04bd86985065efde22a709ee1e

No hay ningún misterio aquí, mi rama HEAD actual quiere establecer el objetivo de implementación en 6.0 mientras que un compañero de equipo quiere 4.3 … Este es un conflicto genuino y fácil de resolver. ( Hablar entre sí 🙂 )

  1. Problema 3 (casos de borde) El único caso de borde real con el que he tenido problemas es cuando 2 compañeros de equipo crean un archivo con el mismo nombre. Esto puede causar confusión ya que la única diferencia entre las 2 entradas en este archivo de proyecto será el número UUID y esto no es fácil de rastrear en un archivo grande con muchos cambios. En tales casos, la coherencia debería funcionar como una solución. Con esto, me refiero a asegurarse de mantener el cambio HEAD del cambio externo, nunca confundir el 2 ya que el número UUID debe permanecer consistente para que Xcode vea los archivos. Si no aplica este tipo de cambio de manera constante, verá un archivo en “Fases de compilación -> Compilar fuentes” con un icono en blanco. La solución fácil es eliminar con el archivo y volver a agregarlo al proyecto.

Todo lo mejor