.gitignore en XCode

Cuando creamos un proyecto nuevo en XCode y marcamos la opción para que utilice el control de versiones, ¿qué está haciendo XCode por debajo?

Básicamente sigue los siguientes pasos:

  • Crea e inicializa un repositorio git en la carpeta raíz del proyecto
  • Añade todos los ficheros al repositorio excepto las carpetas [nombre].xcodeproj/project.xcworkspace y [nombre].xcodeproj/xcuserdata/
  • Hace un commit con el comentario “Initial Commit”

Para ver en qué estado ha quedado el repositorio vamos a seguir los siguientes pasos:

  • Creamos proyecto nuevo en XCode, cualquiera de las plantillas que vienen por defecto nos vale (tanto de iOS como de Mac)
  • Abrimos SourceTree
  • En la ventana “bookmarks” hacemos clic sobre el icono para añadir repositorio

Añadiendo repositorio de XCode a SourceTree paso 1

  • A continuación seleccionamos “Add working copy”, ya que XCode ya ha inicializado el repositorio por nosotros. En el campo “Working copy path” buscamos la carpeta en la que está nuestro proyecto e introducimos un alias campo “”Bookmark Name” si el que crea SourceTree no nos gusta. Hacemos clic sobre “Add” cuando hayamos terminado

Añadiendo repositorio XCode a SourceTree paso 2

  • Cuando se cierre la ventana y volvamos al listado de repositorios de SourceTree, hacemos doble clic sobre el repositorio que acabamos de crear

Los ficheros que XCode no incluye

Cuando git crea el repositorio, añade el siguiente contenido al fichero .git/info/exclude

.DS_Store
UserInterface.xcuserstate

Este fichero, a diferencia de .gitignore, contiene reglas que se aplican sólo a nuestro repositorio local (si compartimos el repositorio con otros usuarios a través de github o bitbucket, no verán estas reglas).

Aparte de estas dos reglas, ¿qué más no ha incluido XCode en el repositorio nada más crearlo?

Si no habéis abierto todavía el repositorio en SourceTree (haced doble clic sobre él en la ventana de Bookmarks) hacedlo ahora. A la izquierda haced clic sobre la rama master, veréis que en la sección “Files in the working tree” nos aparecen los ficheros que XCode no ha añadido al repositorio:

Ficheros nos incluidos por XCode en el repositorio

Si os fijáis, estos ficheros no están incluidos y no se están ignorando. Eso significa que cualquiera podría añadirlos al repositorio en cualquier momento, veamos cómo.

Dejemos la ventana del SourceTree como está (luego volveremos a ella) y volvamos a XCode para modificar alguno de los ficheros (como si estuviésemos trabajando en algo serio). Una vez modificado, vamos a Archivo -> Source Control -> Commit (u OPCIÓN-CMD-C) para acceder a la pantalla para enviar un commit:

Commit desde XCode

Como podemos ver, en la parte de arriba a la izquierda tenemos los ficheros que no están incluidos inicialmente en el repositorio, y que son los mismos que hemos visto con SourceTree. Si los marcáis junto a los otros tres ficheros que he modificado, los añadiríamos al repositorio.

La pregunta es…

¿Deben estar los “Workspace Settings” y “User Data” en el repositorio?

“Workspace Settings” contiene información relacionada con los proyectos, así que a no ser que sea algo que estrictamente sólo vamos a usar nosotros, conviene incluirlo en el repositorio.

Sin embargo, la carpeta “User Data” que contiene la configuración propia de nuestro usuario, sí conviene ignorarla ya que si no lo hacemos y trabajamos con otras personas, vamos a encontrarnos constantemente con conflictos difíciles de resolver sobre el IDE, no sobre el proyecto en sí.

Para ignorar estos ficheros, abrimos un editor de textos cualquiera y dentro de la raíz del proyecto creamos un fichero de texto plano al que llamaremos “.gitignore” (no os olvidéis del “punto” delante del nombre del fichero) y añadimos las siguientes líneas:

.DS_Store
UserInterface.xcuserstate
xcuserdata

  • Las dos primeras reglas son el mismo contenido que teníamos en .git/info/exclude. Las ponemos aquí para asegurarnos de que todo el mundo que se descargue el repositorio ignora estos ficheros
  • La tercera línea es la que ignora las preferencias de usuario

Una vez creado el fichero, volvemos a la pantalla de commit del XCode y veremos lo siguiente:

Ignorando User Data

¡Ya no podemos enviar la carpeta “User Data” por error!. Marcamos la carpeta “Workspace Settings” junto al resto de ficheros y hacemos el commit.

¿Ya está?

No, todavía no. Cuando he creado el fichero .gitignore, no lo he creado usando XCode así que si habéis hecho los commits desde XCode como yo, el fichero .gitignore no está incluido en el repositorio. ¿No me crees? Vuelve a la ventana del SourceTree que hemos dejado olvidada hace unos minutos y verás:

Añadiendo .gitignore al repositorio

Efectivamente, no está incluido. En otro post os contaré porqué necesitamos incluirlo; para no desviarnos del tema de esta entrada, vamos a incluirlo arrastrándolo al área “Files staged in the index” y haciendo clic sobre “Commit”.

(Nota: si preferís añadir el fichero por línea de comandos os resumo los pasos. Abrís una terminal, vais a la carpeta raíz del proyecto de XCode, ejecutáis “git add .gitignore” y luego ejecutáis “git commit -m’Añadiendo .gitignore’ “)

Ahora sí, ya tenemos la versión más sencilla del fichero .gitignore.

¿La versión más sencilla? ¿…es que faltan más cosas?

Sí, en función del proyecto en el que estéis trabajando podéis necesitar no incluir otros ficheros como .nib, clases obsoletas, etc. La comunidad ha generado ya un fichero de reglas estándar que podéis consultar en Stack Overflow, y que copio un poco más abajo para que las tengáis a mano.

¿Usáis vosotros alguna regla que no esté en este fichero? ¿Cuáles son las reglas que utilizáis normalmente? Compartid vuestro .gitignore como un gist en github y poned aquí el enlace. ¡Compartir es vivir!

#########################
# .gitignore file for Xcode4 / OS X Source projects
#
# NB: if you are storing "built" products, this WILL NOT WORK,
#   and you should use a different .gitignore (or none at all)
# This file is for SOURCE projects, where there are many extra
#   files that we want to exclude
#
# For updates, see: http://stackoverflow.com/questions/49478/git-ignore-file-for-xcode-projects
#########################

#####
# OS X temporary files that should never be committed

.DS_Store
*.swp
*.lock
profile


####
# Xcode temporary files that should never be committed
# 
# NB: NIB/XIB files still exist even on Storyboard projects, so we want this...

*~.nib


####
# Xcode build files -
#
# NB: slash on the end, so we only remove the FOLDER, not any files that were badly named "DerivedData"

DerivedData/

# NB: slash on the end, so we only remove the FOLDER, not any files that were badly named "build"

build/


#####
# Xcode private settings (window sizes, bookmarks, breakpoints, custom executables, smart groups)
#
# This is complicated:
#
# SOMETIMES you need to put this file in version control.
# Apple designed it poorly - if you use "custom executables", they are
#  saved in this file.
# 99% of projects do NOT use those, so they do NOT want to version control this file.
#  ..but if you're in the 1%, comment out the line "*.pbxuser"

*.pbxuser
*.mode1v3
*.mode2v3
*.perspectivev3
#    NB: also, whitelist the default ones, some projects need to use these
!default.pbxuser
!default.mode1v3
!default.mode2v3
!default.perspectivev3


####
# Xcode 4 - semi-personal settings, often included in workspaces
#
# You can safely ignore the xcuserdata files - but do NOT ignore the files next to them
#

xcuserdata


####
# XCode 4 workspaces - more detailed
#
# Workspaces are important! They are a core feature of Xcode - don't exclude them :)
#
# Workspace layout is quite spammy. For reference:
#
# (root)/
#   (project-name).xcodeproj/
#     project.pbxproj
#     project.xcworkspace/
#       contents.xcworkspacedata
#       xcuserdata/
#         (your name)/xcuserdatad/
#     xcuserdata/
#       (your name)/xcuserdatad/
#
#
#
# Xcode 4 workspaces - SHARED
#
# This is UNDOCUMENTED (google: "developer.apple.com xcshareddata" - 0 results
# But if you're going to kill personal workspaces, at least keep the shared ones...
#
#
!xcshareddata


####
# Xcode 4 - Deprecated classes
#
# Allegedly, if you manually "deprecate" your classes, they get moved here.
#
# We're using source-control, so this is a "feature" that we do not want!

*.moved-aside


####
# UNKNOWN: recommended by others, but I can't discover what these files are
#
# ...none. Everything is now explained.
.

¡Happy gitting!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *