我使用 git 但我们看到同样的问题 - 如果两个人添加文件，就会出现合并冲突。
通常编辑很容易。只需使用文本编辑器进入 project.pbxproj 文件，然后查找合并冲突部分 - 通常它标记为以下内容：
>>>>>>>
Stuff 1
======
Stuff 2
<<<<<<<<
在 99% 的 Xcode 项目合并冲突情况下，您只是想接受合并的双方（因为两个人添加了不同的文件） - 因此您只需删除合并标记，在上述情况下最终会像这样：
Stuff 1
Stuff 2
就像我说的，这在大多数情况下都很有效。如果完成后 Xcode 无法读取项目文件，只需获取最新的未合并版本并再次手动添加文件即可。
2023 年后续行动
这个建议仍然大部分有效，但最近我一直在开发一个非常大且旧的应用程序，其中包含一个复杂的 Xcode 项目文件，并且几个团队成员经常进行大量添加。
手动检查合并冲突仍然是主要方法。多人添加新文件通常仍然与使用合并冲突的双方一样简单。
仍然存在简单的后备方案，即简单地获取您尝试合并到分支中的项目文件，并使用存在冲突的 Xcode 项目的副本来手动添加回您的更改。
尽管我发现有一些特殊情况可能会带来挑战，但在解决方案极其不明显的情况下......
首先，有时，多个人处理同名的文件可能会导致多个完整的文件具有不同的标识符。对于此问题，请在文件所在的组中查找文件 ID，然后选择要保留的文件 ID 和要丢弃的文件 ID。
第二个是，在项目中的相似位置引入新组可能会导致分裂组的冲突。在这些情况下，您可能需要将合并一侧的内容完全移出合并冲突区域，并将其与项目文件中的其他组一起正确引入。
最后一个是促使我更新这个答案的非显而易见的解决方案。也就是说，有时您可能会遇到冲突，所有 CoreData 版本的条目都具有完全不同的标识符。例如，如果两个团队同时提高了模型版本，则可能会发生这种情况。
在这种情况下，您似乎可以仅使用这些标识符来选择一侧或另一侧。这有时有效。
然而，在某些情况下，如果我这样做，在加载项目时我将根本看不到任何模型版本 - Xcode 将它们全部删除。
解决方案再次是，保留合并的两侧，这意味着核心数据模型有两个条目！如果您这样做，会发生什么情况，Xcode 在加载项目时，将为所有模型选择有效的标识符并保存一个正确的版本，而不是允许两者都存在。
对于使用 CoreData 并同时进行多个版本更新的大型团队来说，我们发现一项有助于顺利解决问题的技术是建立一个单独的分支来进行 CoreData 模型更改。这样，所有团队都将尽快使用具有相同当前模型标识符和内部 Xcode 项目 ID 的相同 CoreData 版本。该分支仅包含 CoreData 模型本身，而不包含与模型相关的任何类（尽管可以）。
