Mejores prácticas para Xcode + Git para proyectos de varios desarrolladores

Question

Puedo crear un repositorio y usar GitHub/BitBucket para mis propios proyectos. He tenido problemas al colaborar con otros desarrolladores o al intentar bifurcar un proyecto en GitHub.

Conozco otras respuestas como Best practices for git repositories on open source projects pero existen problemas específicos de OSX/Xcode que quiero saber cómo resolverlos.

1. .DS_Store archivos pueden ser un dolor. Puede usar .gitignore para evitar, pero ¿qué ocurre si ya se han incluido, o si otro desarrollador los vuelve a agregar mediante un comando git torpe?

2. El .xcodeproj tendrá cambios en los nombres de directorio y perfiles de desarrollador para la otra persona. ¿Cuál es la mejor forma de fusionar o evitar conflictos?

3. Si he bifurcado o extraído de un proyecto github, ¿cómo puedo solucionar estos problemas y también minimizar los conflictos de combinación para el mantenedor?

Si la gente tiene un ejemplo .gitignore creada para Xcode, o secuencias de comandos que utilizan para inicializar sus repos entonces que sería genial!

Answer 1

voy a tratar uno por uno:

I. Necesita utilizar git filter-branch sólo si es necesario para eliminar los archivos de su historia por completo. Si estos archivos no contienen ninguna información de tarjeta de crédito, entonces creo que el siguiente debería ser suficiente:

git rm --cached .DS_Store 
git commit -m "{Your message}" 

continuación, añadir este archivo a .gitignore y cometen.

Esto comprometerá la eliminación del archivo del repositorio, pero mantendrá el archivo en el directorio de trabajo. Sin embargo, si lo presiona y alguien más logrará este compromiso, es posible que elimine su archivo, por lo que DEBE comunicarlo. Al confirmar .gitignore, evitará que otros desarrolladores agreguen este archivo nuevamente. Si no es un mantenedor, entonces no creo que deba hacer nada, pero dirija este problema al responsable.

II.Soy un firme creyente de que los archivos ocultos de cualquier naturaleza son la mayor parte del tiempo, y no se supone que sean puestos en el repositorio exactamente por esa razón. Por lo tanto, creo que debe hacer lo mismo con .xcodeproj que con .DS_Store y ponerlo en .gitignore y confirmarlo. .gitignore es la excepción para la regla anterior.

III. Si esos archivos se ignoran correctamente, no habrá problemas en el futuro con ellos. Si ya están en el repositorio y alguien quiere hacer tal limpieza, debe hacerlo el mantenedor y comunicarse dentro del equipo.

Espero que ayude!

Answer 2

git filter-branch puede ayudarlo a eliminar archivos no deseados (archivos .DS_Store) de su repositorio - ver p. https://help.github.com/articles/remove-sensitive-data

Si un commit torpe de git tiene archivos agregados, debería ser capaz de reproducir los conjuntos de cambios corregidos en un repositorio limpio.

Answer 3

Tienes razón en el sentido de que si ya se agrega una .DS_Store, el .gitignore no será de mucha ayuda, sin embargo, creo que sigue siendo un buen recurso para ti y para los demás.

Cuando comienzo un proyecto, normalmente miro este list para ver si ya existe un buen .gitignore. Más específicamente para usted, this, uno es Objective-C .gitignore.

Esperemos que esos recursos sean de alguna utilidad.

Answer 4

1. Pon .DS_Store en .gitignore. Luego, si aún no lo ha hecho, agregue .gitignore al repositorio. (No debe ignorar .gitignore.) Ahora todos los desarrolladores ignorarán los archivos .DS_Store. Si alguna se agregó al informe erróneamente antes de poner .DS_Store en .gitignore, ahora puede eliminarlas (en una confirmación) y deben permanecer fuera.

2. El xcodeproj es un directorio. El único archivo en este directorio que debe estar en el repositorio es el archivo project.pbxproj. Yo generalmente ignoran todos los demás poniendo estas líneas en mi .gitignore:

   *.xcuserstate 
   project.xcworkspace/ 
   xcuserdata/ 
   

   Usted debe evitar poner las rutas absolutas en los valores de creación. Usa caminos relativos

   su depuración y las versiones de lanzamiento debe utilizar iPhone Developer como la identidad de la firma de código, de modo que Xcode seleccionará automáticamente el perfil del desarrollador local. Cuando desee crear un IPA (para distribución), Xcode le ofrecerá volver a firmarlo con una identidad diferente, en cuyo momento puede elegir su perfil de distribución si lo necesita.

3. Si está tratando de usar un proyecto de github que cometió estos errores, puede intentar que el desarrollador los solucione, o puede asegurarse de no tocar los archivos .DS_Store y la firma del código identidades en los mismos commits que desea enviar en sentido ascendente.

Answer 5

Como un usuario de Mac debe descargar una herramienta como SourceTree que apoya Git Flow. Git Flow lo ayudará a establecer algunas prácticas recomendadas sobre la forma en que sus colaboradores asignarán el código al repositorio y, como mínimo, harán que los conflictos de fusión sean menos frecuentes y más manejables. Para obtener un conjunto de archivos de gitignore para varios tipos de proyectos, puede ir al GitHub y descargar uno que esté listo para funcionar. Para Xcode lo tienen listado como Objective-C.gitignore. Ese es un buen punto de partida e incluso cubre Cocoapods. Si está utilizando librerías externas, su proyecto debe usar CocoaPods para que pueda aislar ese código y mantenerlo fuera de su repositorio y evitar los submódulos de git.

Ahora cuando encuentre un archivo que haya ingresado en su repositorio como .DS_Store, simplemente elimínelo y continúe. Asegúrese de agregarlo al archivo .gitignore que está registrado en el proyecto.

En cuanto a xcodeproj ... no debería haber tanta personalización dentro del archivo que sea específica del usuario dado que el filtro de gitignore mencionado anteriormente lo elimina. Si se va a compartir un esquema, asegúrese de marcar compartido en Gestionar esquemas y comprobará los archivos en ese subdirectorio. Debería utilizar una selección automática de certificados, por lo que la única opción real es Desarrollador o Distribución.También debe aprovechar variables provided within Xcode que evitan las rutas completas de hardcoding. Al tratar de pensar en un ejemplo, me vienen a la mente los Pistas, en este caso, es posible que haya escrito /Users/me/MyProject/Resources/MyProject.plist, pero en su lugar debería usar $(SRCROOT)/resources/MyProject.plist.

Answer 6

Para el segundo problema relacionado con el .xcodeproj y conflictos de combinación.

El uso de un archivo de .gitattributes para especificar que los conflictos de fusión para todos los .pbxproj archivos deben ser manejados usando la estrategia merge=union, lo que debería significar que Git sabe fusionar en los cambios de ambos lados del conflicto, teniendo los cambios ascendentes primero.

This article explains it in a bit more depth