2010-10-26 25 views
29

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

¿Alguien tiene consejos sobre cómo manejar los conflictos de fusión en grandes y complejos archivos como el archivo de proyecto Xcode?


EDIT-- Algunas preguntas relacionadas:

Git and pbxproj

Should I merge .pbxproj files with git using 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/

+0

Interesante pregunta. desafortunadamente, creo que no hay solución. Tengo curiosidad de saber si alguien obtendrá una buena respuesta. Si no, echa un vistazo a http://stackoverflow.com/questions/3929087/dividing-a-project-into-multiple-xcode-project-files/3932613#3932613 :) –

Respuesta

7

1) romper sus proyectos arriba en pequeños, bibliotecas más lógicas/paquetes. los proyectos masivos son regularmente el signo de un mal diseño, como el objeto que hace demasiado o es demasiado grande.

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

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

4) utilice archivos xcconfig siempre que sea posible. esto también reduce la cantidad de cambios que debe realizar al actualizar sus compilaciones. Los archivos xcconfig definen una colección de configuraciones de compilación 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 dependencias de destino: cree objetivos que realicen operaciones lógicas, en lugar de operaciones físicas. este suele ser un objetivo de script de shell o un objetivo agregado. por ejemplo: "construir dependencias", "ejecutar todas las pruebas unitarias", "construir todo", "limpiar todo". entonces no tiene que mantener cada cambio de dependencia en cada paso de una manera; es como usar referencias.

6) definen un "Árbol de fuentes" común para su código y un segundo para fuentes de terceros.

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

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

+0

Grandes sugerencias, aunque eluden en lugar de resolver el problema. 1 + 6 ya lo estoy haciendo. 4 + 5 lo consideraré. 2 + 7 - ¿podría proporcionar más información? – Felixyz

+0

sí, simplemente proyectan archivos/estructuras (y eluden el problema más que resolverlo). 2) estructurar sus archivos de origen, recursos, casos de prueba, etc. para que pueda recrear fácilmente cualquier objetivo agregando todos los contenidos de un directorio en un proyecto (específicamente, los casos de prueba residirían en otro proyecto o tendrían un segundo objetivo dedicado a las pruebas que también construirías agregando todo, desde el directorio unit_test al objetivo unit_test). de esta forma, escribiría y diseñaría los archivos fuente (etc.) para que pudiera reconstruir cualquier objetivo en función de sus (cont) – justin

+0

(cont) dependencias, el contenido (completo) de un directorio y un la adición de un xcconfig. si un proyecto está dañado o se debe usar en otra ide (o versión de xcode), la importación tarda menos de 1 minuto. esto también puede ayudar a mantener los bits no utilizados fuera del árbol principal del proyecto. también hace que sea fácil hacer compilaciones combinadas. si eres obsesivo con la corrección de la declaración de lo que se exporta y la visibilidad (que definitivamente debería ser una preocupación si trabajas en programas no triviales), entonces puedes crear una compilación combinada en muy poco tiempo. (cont) – justin

2

La mejor manera que he encontrado es indicarle a Git que trate el archivo .pbxproj como un archivo binario. Esto evita confusas fusiones.

Agregue esto a su archivo .gitatributes:

*.pbxproj -crlf -diff -merge 
+1

¿Qué diferencia hace esto a la fusión física? – esbenr

+4

Si esto hace que el archivo sea realmente binario, ¿cómo facilita la fusión? – damian

+1

por favor, consulte estos: http://robots.thoughtbot.com/xcode-and-git-bridging-the-gap ---- Cita: Debido al formato personalizado utilizado en este tipo de archivo, esto es exactamente lo que queremos Cuando surge un conflicto de fusión para este archivo, git combinará automáticamente los cambios de ambos lados del conflicto, aplicando primero los cambios ascendentes. – chakming

2

para comparar dos proyectos de Xcode abierto abierto FileMerge (Xcode abierto y seleccione Xcode (desde el panel de Manu) -> Abrir herramientas para desarrolladores -> FileMerge) . ahora haga clic en el botón "izquierda" y abra el directorio principal del proyecto xcode. haga clic en el botón "a la derecha" y abra el directorio principal del proyecto xcode para comparar.

¡Ahora haga clic en el botón "fusionar"!

Eso es todo!

+1

Lo más fácil, si está usando git: 'git config --global merge.tool opendiff' (solo necesita hacerse una vez), entonces' git mergetool' lo lanzará por usted. – damian

+1

No estoy seguro de que FileMerge tenga un soporte especial para archivos de proyectos de Xcode en particular? – Benjohn

0

Otra opción a considerar que puede ayudar a reducir el número de veces que experimenta el problema. Para explicarlo, llamaré a la sucursal que las ramas de los miembros del equipo provienen de la rama "desarrollar". Tenga una convención en su equipo que cuando se modifica el archivo de proyecto, los cambios (junto con cualquier otro cambio requerido para garantizar la integridad de la construcción) se confirman en una confirmación separada. Ese compromiso es luego seleccionado en la rama de desarrollo. Otros miembros del equipo que planean modificar el archivo 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.

3

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

Es un guión que le ayudará a combinar correctamente los archivos de proyecto XCode. Tenga en cuenta que todavía es alfa.

Descargo de responsabilidad: soy el autor de mergepbx.

+0

Simon, ¿este proyecto está maduro en este momento? –

+2

Bueno, me funciona, ¿así que sí? Desafortunadamente no hay posibilidad de asegurarse de que realmente funcione con todo, ya que no hay documentación sobre el formato de archivo del proyecto. Por lo tanto, nunca será mejor que "funciona para mí y nadie se ha quejado hasta ahora". – Simon

+0

Simon - Después de pasar años en el desarrollo y control de calidad, escuchar "bueno, funciona para mí", eso me asusta. Tal vez es todo lo que tenemos, pero aún así. –

Cuestiones relacionadas