如何在Xcode中使用svn合并冲突（文件project.pbxproj）？

发布于 2024-08-17 00:06:39 字数 407 浏览 21 评论 0原文

我们团队中有两名成员。我们使用Xcode的SCM（使用SVN）来管理我们的源代码文件。
我们都将文件添加到我们的 Xcode 项目中。他已经致力于SVN服务器。当我更新时，Xcode 发现 project.pbxproj 文件存在冲突。然后我选择退出 Xcode 并手动合并冲突。然后我开始编辑我的 project.pbxproj，合并我们的更改。实际上我不知道 Xcode 如何管理文件，我只是添加了一些我的 project.pbxproj 文件中没有的文本。当我完成后，我的项目无法打开。我猜这是因为 project.pbxproj 文件无法手动编辑。

所以，我想知道，当你发现这个问题时，project.pbxproj文件有冲突，如何解决？

谢谢你！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

静待花开 2024-08-24 00:06:39

我使用 git 但我们看到同样的问题 - 如果两个人添加文件，就会出现合并冲突。

通常编辑很容易。只需使用文本编辑器进入 project.pbxproj 文件，然后查找合并冲突部分 - 通常这由类似以下内容标记：

>>>>>>>
Stuff 1
======
Stuff 2
<<<<<<<<

在 99% 的 Xcode 项目合并冲突情况下，您只需接受合并的双方（因为两个人添加了不同的文件） - 所以你只需删除合并标记，在上面的情况下，结果会是这样的：

Stuff 1
Stuff 2

就像我说的，这在大多数情况下都很有效。如果完成后 Xcode 无法读取项目文件，只需获取最新的未合并版本并再次手动添加文件即可。

FOLLOWUP 2023

这个建议仍然基本成立，但最近我一直在开发一个非常大且旧的应用程序，其中包含复杂的 Xcode 项目文件，并且几个团队成员经常进行大量添加。

手动检查合并冲突仍然是主要方法。多人添加新文件通常仍然与使用合并冲突的双方一样简单。

仍然存在一种后备方案，即简单地获取您尝试合并到分支中的项目文件，并使用存在冲突的 Xcode 项目的副本来手动添加回您的更改。

尽管我发现在某些情况下可能会带来挑战，但在解决方案极其不明显的情况下......

第一个是有时，多个人处理同名的文件可能会导致多个完整的文件具有不同标识符的文件。对于此问题，请在文件所在的组中查找文件 ID，然后选择要保留的文件 ID 和要丢弃的文件 ID。

第二个是，在项目中的相似位置引入新组可能会导致分裂组的冲突。在这些情况下，您可能需要将合并一侧的内容完全移出合并冲突区域，并将其与项目文件中的其他组一起正确引入。

最后一个是促使我更新这个答案的非显而易见的解决方案。也就是说，有时您可能会遇到冲突，所有 CoreData 版本的条目都具有完全不同的标识符。例如，如果两个团队同时提高了模型版本，则可能会发生这种情况。

在这种情况下，您似乎可以仅使用这些标识符来选择一侧或另一侧。这有时有效。

然而，在某些情况下，如果我这样做，在加载项目时我将根本看不到模型版本 - Xcode 将它们全部删除。

解决方案再次是，保留合并的两侧，这意味着核心数据模型有两个条目！如果您这样做，会发生什么情况，Xcode 在加载项目时，将为所有模型选择有效的标识符并保存一个正确的版本，而不是允许两者都存在。

对于使用 CoreData 并同时进行多个版本更新的大型团队来说，我们发现一项有助于顺利解决问题的技术是建立一个单独的分支来进行 CoreData 模型更改。这样，所有团队都将尽快使用具有相同当前模型标识符和内部 Xcode 项目 ID 的相同 CoreData 版本。该分支仅包含 CoreData 模型本身，而不包含与模型相关的任何类（尽管可以）。

I use git but we see the same issue - if two people add files there's a merge conflict.

Usually the editing is very easy though. Simply go into the project.pbxproj file with a text editor, and look for the merge conflict section - usually this is marked by something like :

>>>>>>>
Stuff 1
======
Stuff 2
<<<<<<<<

In 99% of Xcode project merge conflict cases, you simply want to accept both sides of the merge (because two people added different files) - so you would simply delete the merge markers, in the above case that would end up like:

Stuff 1
Stuff 2

Like I said, this works great in MOST cases. If Xcode will not read the project file when you are done, just take the most recent un-merged version and manually add your files again.

FOLLOWUP 2023

This advice still mostly holds, but in recent times I've been working on a very large and old application with a complex Xcode project file and several team members often working on large additions.

Manually examining merge conflicts is still the primary approach. Multiple people adding new files is often still just as easy as using both sides of a merge conflict.

There is still also always the fallback of simply taking in a project file you are attempting to merge into your branch, and using a copy of the Xcode project with conflicts to manually add back in your changes.

There are a few cases in particular though that I have found can present challenges, on scenario which has an extremely non-obvious solution...

The first is that sometimes, multiple people working on a file with the same name may result in multiple entires of the file with different identifiers. For this issue, look for file IDs within the group the file will be contained in, and pick which file ID to preserve, and which to discard.

The second is that introducing new groups in similar locations in your project might result in a conflict splitting up a group. In these cases you may need to take the contents of one side of the merge totally out of the merge conflict region, and introduce it correctly alongside other groups in the project file.

The last is the non-obvious solution that prompted me to update this answer. That is that sometimes, you may get a conflict where entries for all of your CoreData versions would have totally different identifiers. This might happen for example if two teams had bumped up the model version at the same time.

In that case it would seem that you can take one side or the other, using only those identifiers. This sometimes works.

However in some cases if I did that, on loading the project I would see no model versions at all - Xcode deleted them all.

The solution was again, to leave in BOTH sides of the merge which meant two entries for core data models! What happens if you do this is Xcode on loading the project, will choose valid identifiers for all of the models and save one correct version instead of allowing both to live.

For a large team using CoreData with multiple ongoing version bumps at once, one technique we found helped smooth thing over was to have a separate branch with CoreData model changes over. That way all teams would be using the same CoreData version with the same current model identifier, and internal Xcode project IDs ASAP. This branch only held the CoreData models themselves, not any classes related to the models (though it could).

回复收藏 0 原文

寄意 2024-08-24 00:06:39

不幸的是，除了在一次签出中手动进行更改然后签入新“合并”的项目之外，您无能为力。

回复收藏 0 原文

dawn曙光 2024-08-24 00:06:39

此解决方案仅适用于 git，但您可以将 .gitattributes 文件添加到您的项目中，然后在该文件中添加以下行：

*.pbxproj merge=union

这会告诉您git 保留合并的双方，这在绝大多数情况下都是您想要的。

回复收藏 0 原文

亽野灬性zι浪 2024-08-24 00:06:39

要手动解决合并冲突，请检查每个冲突项目的 UUID。

示例：

<<<<<<< HEAD
    6B01C4B72008E70000A19171 /* ExistingFile.swift in Sources */ = {isa = PBXBuildFile; fileRef = 6B01C4B62008E70000A19171 /* ExistingFile.swift */; };
    3F01C4B72008E70000889299 /* NewFileA.swift in Sources */ = {isa = PBXBuildFile; fileRef = 3F01C4B72008E70000889299 /* NewFileA.swift */; };
=======
    6B01C4B72008E70000A19171 /* ExistingFile.swift in Sources */ = {isa = PBXBuildFile; fileRef = 6B01C4B62008E70000A19171 /* ExistingFile.swift */; };
    4DF01C4B72008E70000882ED /* NewFileB.swift in Sources */ = {isa = PBXBuildFile; fileRef = 4DF01C4B72008E70000882ED /* NewFileB.swift */; };
>>>>>>> branch_to_merge

检查每个 UUID：

如果它在两个版本中都出现，则在一个版本中将其删除：ExistingFile.swift
如果它没有出现在比较分支上，则保留它：NewFileA.swift 和 NewFileB.swift
如果文件中的其他任何地方都没有引用它，即您只能在整个 project.pbxproj 文件中找到一次，我会假设它是一个人工制品，可以安全地删除它。

结果将是：

    6B01C4B72008E70000A19171 /* ExistingFile.swift in Sources */ = {isa = PBXBuildFile; fileRef = 6B01C4B62008E70000A19171 /* ExistingFile.swift */; };
    3F01C4B72008E70000889299 /* NewFileA.swift in Sources */ = {isa = PBXBuildFile; fileRef = 3F01C4B72008E70000889299 /* NewFileA.swift */; };
    4DF01C4B72008E70000882ED /* NewFileB.swift in Sources */ = {isa = PBXBuildFile; fileRef = 4DF01C4B72008E70000882ED /* NewFileB.swift */; };

注意： 我不建议将 *.pbxproj merge=union 添加到 .gitattribues 文件中以基本上忽略合并冲突因为冲突的合并应该始终手动检查，除非有一个复杂的脚本为您执行此操作。

To manually solve the merge conflicts, check the UUID of each conflicting item.

Example:

<<<<<<< HEAD
    6B01C4B72008E70000A19171 /* ExistingFile.swift in Sources */ = {isa = PBXBuildFile; fileRef = 6B01C4B62008E70000A19171 /* ExistingFile.swift */; };
    3F01C4B72008E70000889299 /* NewFileA.swift in Sources */ = {isa = PBXBuildFile; fileRef = 3F01C4B72008E70000889299 /* NewFileA.swift */; };
=======
    6B01C4B72008E70000A19171 /* ExistingFile.swift in Sources */ = {isa = PBXBuildFile; fileRef = 6B01C4B62008E70000A19171 /* ExistingFile.swift */; };
    4DF01C4B72008E70000882ED /* NewFileB.swift in Sources */ = {isa = PBXBuildFile; fileRef = 4DF01C4B72008E70000882ED /* NewFileB.swift */; };
>>>>>>> branch_to_merge

Check each UUID:

If it occurs in both versions, remove it in one version: ExistingFile.swift
If it does not occur on the comparing branch, keep it: NewFileA.swift and NewFileB.swift
If it is not referenced anywhere else in the file, i.e. you can only find one occurrence in the whole project.pbxproj file, I would assume it is an artefact and safe to delete it.

The result would be:

    6B01C4B72008E70000A19171 /* ExistingFile.swift in Sources */ = {isa = PBXBuildFile; fileRef = 6B01C4B62008E70000A19171 /* ExistingFile.swift */; };
    3F01C4B72008E70000889299 /* NewFileA.swift in Sources */ = {isa = PBXBuildFile; fileRef = 3F01C4B72008E70000889299 /* NewFileA.swift */; };
    4DF01C4B72008E70000882ED /* NewFileB.swift in Sources */ = {isa = PBXBuildFile; fileRef = 4DF01C4B72008E70000882ED /* NewFileB.swift */; };

Note: I don't recommend adding *.pbxproj merge=union to the .gitattribues file to basically ignore merge conflicts because a conflicting merge should alway be checked manually unless there is a sophisticated script doing that for you.

回复收藏 0 原文

蛮可爱 2024-08-24 00:06:39

到目前为止，我用于 pbx 文件的最佳可视化合并工具是 Visual Studio Code 的合并工具。我在 Code 应用程序中打开 pbx 文件并修复冲突，然后再次打开 XCode。

回复收藏 0 原文

往日情怀 2024-08-24 00:06:39

当我遇到其他问题/答案时，我正在寻找解决此问题的简单方法：

https://stackoverflow.com/a/ 14180388/307217

我完全被这个解决方案的简单性震惊了，我试图合并到一个不同的功能分支中，该分支在主干后面有近 200 个修订，XCode 和 Mercurial 对此并不高兴。在尝试此解决方案之前，我尝试手动合并 pbxproj 文件（有超过 100 个冲突）8 次。

基本上解决方案是这样的（假设您使用 Mercurial，因为它很棒）：

尝试在 Mercurial 中进行合并：

hg 更新 FEATURE_BRANCH
hg 合并默认值
*mercurial 给你提供了大量有关 pbxproj 文件存在合并冲突的废话*

打开 Xcode
从顶部工具栏中，选择 Xcode->Open Developer Tool->FileMerge
在左侧，打开冲突的 ' project.pbxproj' 文件（其中包含合并冲突标记的文件）
在右侧，打开“project.pbxproj.orig”，
选择“文件”->“保存合并”并保存到“project.pbxproj”文件

然后返回命令行：

hg resolve -m ProjectName.xcodeproj/project.pbxproj
*合并任何其他损坏的文件*
hg commit -m“手动与主干合并”

吃蛋糕，因为你已经完成了

I was looking for a straightforward solution to this problem when I came across this other question/answer:

https://stackoverflow.com/a/14180388/307217

I was completely blown away by how simple this solution is, I was trying to merge in a disparate feature branch which was almost 200 revisions behind the trunk, XCode and Mercurial were not being happy campers about it. I tried manually merging the pbxproj file (which had over 100 conflicts) 8 times before trying this solution.

Basically the solution is as such (assuming you use Mercurial, because it's awesome):

Attempt your merge in mercurial:

hg update FEATURE_BRANCH
hg merge default
*mercurial gives you a ton of crap about the pbxproj file having merge conflicts*

Open Xcode
From the top toolbar, select Xcode->Open Developer Tool->FileMerge
On the left, open your conflicted 'project.pbxproj' file (the one with merge conflict markup in it)
On the right side, open your 'project.pbxproj.orig'
Select File->Save Merge and save over the 'project.pbxproj' file

Then back at the command line:

hg resolve -m ProjectName.xcodeproj/project.pbxproj
*merge any other broken files*
hg commit -m "manually merged with trunk"

Eat Cake Because You Are Done

回复收藏 0 原文

对你再特殊 2024-08-24 00:06:39

如上所述，处理冲突的最常见的方法是

接受“所有内容”，
将文件重新导入到项目中

，我编写了一个bash脚本来处理( 1）同上。

请注意，这只能解决最常见的合并冲突情况！

#!/bin/bash
#
#
#
if [ $# -eq 0 ]
 then
    echo "File must be provided as argument, darnit!"
    exit 1
fi

if [ $# -eq 2 ]
 then
    echo "only ONE File must be provided as argument, darnit!"
    exit 1
fi


echo "Will remove lines from file:" $1
grep -v "<<<<<" $1  | grep -v ">>>>>>" | grep -v "====" > out.tmp;mv out.tmp $1
echo "Done removing lines from file:" $1

As stated above the most common way of handling the conflicts is to

accept "everything"
re-import the files into the project

I Wrote a bash-script that takes care of (1) above.

Note that this will only solve the most common case of merge conflicts!

#!/bin/bash
#
#
#
if [ $# -eq 0 ]
 then
    echo "File must be provided as argument, darnit!"
    exit 1
fi

if [ $# -eq 2 ]
 then
    echo "only ONE File must be provided as argument, darnit!"
    exit 1
fi


echo "Will remove lines from file:" $1
grep -v "<<<<<" $1  | grep -v ">>>>>>" | grep -v "====" > out.tmp;mv out.tmp $1
echo "Done removing lines from file:" $1

回复收藏 0 原文

才能让你更想念 2024-08-24 00:06:39

有时，可以在不同分支中重新创建一个或几个文件（例如 ManagedObjects），因此当您合并时，一个块中的一个文件可能有两个声明。在这种情况下，您应该删除其中一项声明。

回复收藏 0 原文

感悟人生的甜 2024-08-24 00:06:39

您可以在 VSCODE 上打开它并修复冲突的合并。在 IDE 上查找一些彩色注释或查找 <<< >>>>>在文本搜索中。

回复收藏 0 原文

久伴你 2024-08-24 00:06:39

我碰巧遇到了这个棘手的问题。

您可以尝试这样做，而不是手动处理这些冲突。
假设您在功能分支上。

Git 结帐大师。
将 project.pbxproj
Git checkout 中的内容复制到您的功能分支，然后粘贴。（覆盖 project.pbxproj 中的当前内容）
运行
```
react-native 链接
```

I happened to encounter this tricky problem.

Instead of manually dealing with these conflicts, you can try this.
Suppose you are on feature branch.

Git checkout master.
Copy content in project.pbxproj
Git checkout to your feature branch, and paste it.(Override the current content in project.pbxproj)
Run
```
react-native link
```

回复收藏 0 原文