Apple 在 Xcode 5 中引入了一种新的与项目相关的文件类型:“xccheckout”。
这个文件位于“.xcodeproj/project.xcworkspace/xcshareddata/”目录下,貌似和项目的版本控制系统有关。
示例文件在这里: http: //pastebin.com/5EP63iRa
我想这种类型的文件在 VCS 下应该被忽略,但我不确定。
所以这里有问题:
- 应该忽略“xccheckout”吗?
- 它的目的是什么?
Apple 在 Xcode 5 中引入了一种新的与项目相关的文件类型:“xccheckout”。
这个文件位于“.xcodeproj/project.xcworkspace/xcshareddata/”目录下,貌似和项目的版本控制系统有关。
示例文件在这里: http: //pastebin.com/5EP63iRa
我想这种类型的文件在 VCS 下应该被忽略,但我不确定。
所以这里有问题:
您应该签入 Xcode 5.xccheckout
文件;一般来说,xcshareddata
应该提交文件。
.xccheckout
文件包含有关工作空间中使用哪些存储库的元数据。对于单个存储库中的单个项目并没有太大区别。但是,如果您使用的工作空间包含来自不同存储库的多个项目,.xccheckout
则工作空间中存在的文件允许 Xcode 知道构成工作空间的所有组件是什么以及从何处获取它们。
该*.xccheckout
文件包含 VCS 元数据,因此不应检入 VCS。
另一方面:签入此文件可能不会造成合并困难或其他问题。
如果您想忽略此文件(我推荐),您应该将此行添加到您的项目中.gitignore
:
*.xccheckout
Abizern的解决方案不适用于工作空间内的项目。因为,当您使用工作区时,*.xccheckout
文件的路径将是:<workspace-name>.xcworkspace/xcshareddata/<workspace-name>.xcchekout
. 它实际上忽略了比你想要的更多的东西。
编辑: 此文件用于管理 Xcode 对项目中可能存在的许多 VCS 系统的了解,请参阅Chris Hanson的回答。对于 > 99% 的项目,.xccheckout 文件是过度配置。
这取决于。该文件包含对您正在使用的远程存储库的引用。如果您使用的是 Perforce 或 Subversion 等集中式 VCS,每个人的远程存储库都是相同的,因此您可以并且应该签入文件。
如果您使用的是分布式 VCS,例如 Mercurial 或 git,但将其用作 CVCS(换句话说,每个人都从共享存储库直接克隆到他们机器上的个人工作区),那么您仍然可能需要检查它在。
但是,如果您使用 DVCS,每个人都有自己的远程克隆,例如在其标准使用模式中使用 GitHub,您不想签入此文件。如果您这样做了,那么您的拉取请求将询问您的存储库设置复制到其他人的 xccheckout 文件中,但是您的存储库设置将与其他所有人的不同,因为您都使用不同的远程存储库。
是的,该Project.xccheckout
文件应该提交到您的存储库。Xcode 使用这个文件告诉打开工作区的其他人工作区使用的源代码控制存储库的完整列表以及工作副本相对于工作区的位置,无论这些存储库是 Git、SVN 还是两者兼而有之。
当您打开工作区时,Xcode 使用该Project.xccheckout
文件通知用户还有其他存储库构成工作区的一部分,并询问应该签出哪些存储库。当检出其他存储库时,Xcode 将工作副本放置在与Project.xccheckout
生成文件时相同的工作空间相对文件夹结构中。
正如Chris Hanson所说,对于单个存储库、一个项目的工作空间可能并不重要,但对于更复杂的事务,它确实非常方便。
您可以在 WWDC 2013 会议视频了解 Xcode 中的源代码控制中了解更多信息;相关部分从大约 15 分钟开始。
这就是我在 Xcode 的 .gitignore 中的内容。
#Xcode
*.xcuserstate
project.xcworkspace/
xcuserdata/
它保留了与项目在存储库中查找我的方式的本地状态相关的任何内容。
xccheckout 文件位于此处,因此默认情况下不会在我的系统上对其进行跟踪。
Xcode 已经变得更好,并且可以将需要共享的内容和需要保存在本地的内容分开。例如; 这些行将忽略默认的构建方案,这很好,因为您可以将特定的构建方案标记为共享,并将它们放在一个不会被忽略的目录中。
断点被忽略,但您可以将特定断点标记为跨项目共享,并且它们也被放置在不被忽略的目录中。