Fusionando files de proyecto de Xcode

A menudo hay conflictos en el file de proyecto de Xcode (Project.xcodeproj / project.pbxproj) al fusionar sucursales (estoy usando git). A veces es fácil, pero a veces termino con un file de proyecto corrupto y tengo que revertir. En el peor de los casos, tengo que arreglar manualmente el file del proyecto en una segunda confirmación (que puede aplastarse con la anterior) arrastrando los files, etc.

¿Alguien tiene consejos sobre cómo manejar los conflictos de combinación en files grandes y complejos como el file de proyecto de Xcode?


EDITAR – Algunas preguntas relacionadas:

Git y pbxproj

¿Debería unir files .pbxproj con git usando merge = union?

RECURSOS:

http://www.alphaworks.ibm.com/tech/xmldiffmerge

http://www2.informatik.hu-berlin.de/~obecker/XSLT/#merge

http://tdm.berlios.de/3dm/doc/thesis.pdf

http://www.cs.hut.fi/~ctl/3dm/

http://el4j.svn.sourceforge.net/viewvc/el4j/trunk/el4j/framework/modules/xml_merge/

1) divide tus proyectos en bibliotecas / packages más pequeños y más lógicos. los proyectos masivos son regularmente el signo de un mal layout, como el object que hace demasiado o es demasiado grande.

2) layout para una reconstrucción fácil: esto también ayuda si está escribiendo progtwigs que deben ser creados por múltiples herramientas o IDEs. muchos de mis 'proyectos' se pueden rebuild agregando un directory.

3) eliminar las fases de construcción extrañas. ejemplo: eliminé la fase de compilation "Copiar cabeceras" de todos los proyectos. include explícitamente los files específicos a través de la directiva include.

4) utilice files xcconfig siempre que sea posible. esto también networkinguce la cantidad de cambios que debe realizar al actualizar sus comstackciones. Los files xcconfig definen una colección de configuraciones de compilation y admiten #include . por supuesto, luego borre la (mayoría de) las configuraciones definidas por el usuario de cada proyecto y destino cuando defina el xcconfig que se usará.

5) para dependencies de destino: crear objectives que realicen operaciones lógicas, en lugar de operaciones físicas. este suele ser un objective de script de shell o un objective agregado. por ejemplo: "build dependencies", "ejecutar todas las testings unitarias", "build todo", "limpiar todo". entonces no tiene que mantener cada cambio de dependencia en cada paso de una manera; es como usar references.

6) defina un "Árbol fuente" común para su código, y un segundo para fonts de terceros.

7) hay herramientas de construcción externas disponibles. esta puede ser una opción para usted (al less, para algunos de sus objectives).

en este punto, un xcodeproj será mucho más simple. requerirá less cambios y será muy fácil de rebuild. puede ir mucho más allá con estos conceptos para networkingucir aún más la complejidad de sus proyectos y construcciones.

Es posible que desee probar https://github.com/simonwagner/mergepbx/

Es una secuencia de commands que le ayudará a fusionar correctamente los files de proyecto de XCode. Tenga en count que todavía es alfa.

Descargo de responsabilidad: soy el autor de mergepbx.

La mejor manera que he encontrado es instruir a Git para que trate el file .pbxproj como un file binary. Esto evita confusas fusiones.

Agregue esto a su file .gitatributes:

 *.pbxproj -crlf -diff -merge 

Para comparar dos proyectos de Xcode, abra abrir FileMerge (abra xcode y select Xcode (desde el panel principal) -> Abrir herramientas de desarrollador -> FileMerge). ahora click el button "izquierda" y abra el directory principal del proyecto xcode. click el button "derecha" y abra el directory principal del proyecto xcode para comparar.

¡Ahora haz clic en el button "fusionar"!

¡Eso es!

Otra opción para considerar que puede ayudar a networkingucir el número de veces que experimenta el problema. Para explicarlo, llamaré a la sucursal que las twigs de los miembros del equipo provienen de la twig "desarrollar". Tenga una convención en su equipo que cuando se modifique el file del proyecto, los cambios (junto con cualquier otro cambio requerido para garantizar la integridad de la construcción) se cometan en una confirmación separada. Ese compromiso es luego seleccionado en la twig de desarrollo. Otros miembros del equipo que planean modificar el file del proyecto en su sucursal pueden seleccionar su sucursal o volver a establecer la base de su sucursal en el último desarrollo. Este enfoque requiere comunicación entre el equipo y cierta disciplina. Como dije, no siempre será posible; en algunos proyectos podría ayudar mucho y en algunos proyectos podría no serlo.