Apple a introduit un nouveau type de fichier lié au projet dans Xcode 5: "xccheckout".
Ce fichier se trouve dans le répertoire ".xcodeproj/project.xcworkspace/xcshareddata /" et semble lié au système de contrôle de version du projet.
Un exemple de fichier est ici: http://Pastebin.com/5EP63iRa
Je suppose que ce type de fichier doit être ignoré sous VCS, mais je ne suis pas sûr.
Alors voici les questions:
Vous devriez vérifier dans un Xcode 5 .xccheckout
fichier; en général, les fichiers dans xcshareddata
devraient être validés.
Un .xccheckout
fichier contient des métadonnées sur les référentiels utilisés dans un espace de travail. Pour un projet unique dans un référentiel unique, cela ne fait pas beaucoup de différence. Mais si vous utilisez un espace de travail comportant plusieurs projets de différents référentiels, la présence d'un .xccheckout
fichier dans l’espace de travail permet à Xcode de connaître tous les composants qui constituent un espace de travail et où les obtenir.
Le fichier *.xccheckout
Contient des métadonnées VCS et ne doit donc pas être archivé dans le VCS.
En revanche, l’archivage de ce fichier ne créera probablement pas de difficultés de fusion ni d’autres problèmes.
Si vous souhaitez ignorer ce fichier (ce que je recommande), vous devez ajouter cette ligne au .gitignore
De votre projet:
*.xccheckout
Abizern 's solution ne fonctionnera pas pour les projets au sein d'un espace de travail. En effet, lorsque vous utilisez un espace de travail, le chemin du fichier *.xccheckout
Sera: <workspace-name>.xcworkspace/xcshareddata/<workspace-name>.xcchekout
. Et il en ignore plus que vous ne le voudriez.
Edit: Ce fichier permet de gérer les connaissances de Xcode sur les nombreux systèmes VCS éventuellement présents dans votre projet. Voir Chris Hanson answer. Pour plus de 99% des projets, le fichier .xccheckout correspond à une surcharge de configuration.
Ça dépend. Le fichier contient des références au référentiel distant que vous utilisez. Si vous utilisez un VCS centralisé tel que Perforce ou Subversion, le référentiel distant sera le même et vous pourrez ainsi enregistrer le fichier.
Si vous utilisez un VCS distribué tel que Mercurial ou git, mais que vous l'utilisez comme s'il s'agissait d'un CVCS (en d'autres termes, tout le monde cloné depuis un référentiel partagé directement sur son espace de travail personnel sur sa machine), vous pouvez toujours le vérifier. dans.
Cependant, si vous utilisez un DVCS avec tout le monde ayant son propre clone distant, par exemple en utilisant GitHub dans son modèle d'utilisation standard, vous NE voulez PAS archiver ce fichier. Si vous l'avez utilisé, vos demandes d'extraction demanderont les paramètres de votre référentiel. être copié dans le fichier xccheckout de tous les autres, mais les paramètres de votre référentiel seront différents de ceux de tous les autres parce que vous utilisez tous des référentiels distants différents.
Oui, le fichier Project.xccheckout
Doit être validé dans votre référentiel. Xcode utilise ce fichier pour informer les autres utilisateurs de l’espace de travail de la liste complète des référentiels de contrôle des sources utilisés par cet espace de travail, ainsi que de l’emplacement de la copie de travail par rapport à l’emplacement correspondant. espace de travail, que ces référentiels soient Git, SVN ou les deux.
Lorsque vous ouvrez l’espace de travail, Xcode utilise le fichier Project.xccheckout
Pour informer l’utilisateur que d’autres référentiels font partie de l’espace de travail, et demande quels fichiers doivent être extraits. Lors de l'extraction de référentiels supplémentaires, Xcode place les copies de travail dans la même structure de dossiers relative à l'espace de travail que lors de la génération du fichier Project.xccheckout
.
Comme Chris Hanson a dit, cela n'a probablement pas d'importance pour un espace de travail à un seul dépôt, mais pour les affaires plus complexes, ce sera très pratique.
Vous pouvez en savoir plus à ce sujet dans la vidéo de la session WWDC 2013 Comprendre le contrôle de code source dans Xcode ; la partie pertinente commence à environ 15 minutes.
C'est ce que j'ai dans mon .gitignore pour Xcode.
#Xcode
*.xcuserstate
project.xcworkspace/
xcuserdata/
Il garde tout ce qui concerne l'état local de la manière dont les projets me cherchent hors du référentiel.
Le fichier xccheckout est sous ici, donc il n'est pas suivi sur mon système par défaut.
Xcode est devenu meilleur et séparant ce qui doit être partagé et ce qui doit être conservé localement. Par exemple; ces lignes vont ignorer les schémas de construction par défaut, ce qui est très bien car vous pouvez marquer des schémas de construction spécifiques comme partagés, et ils sont placés dans un répertoire qui n'est pas ignoré.
Les points d'arrêt sont ignorés, mais vous pouvez les marquer comme partagés entre les projets. Ils sont également placés dans un répertoire non ignoré.