135

从 git 工作流程的角度来看,当多人协作时,情节提要相当痛苦。例如,.storyboard 文件中的 XML 的起始<document>标记toolsVersionsystemVersion属性会被最新的文件操纵器碰巧正在运行的任何配置更改。精确同步每个人的 Xcode 版本似乎有助于解决问题toolsVersion,但systemVersion无论如何都会发生变化,具体取决于开发人员正在运行的特定 Mac 和/或 OS X 版本。

这是愚蠢的,但大多是无害的。然而,让我们担心的是,在其他时候,只需在git pull. 也就是说,Alice 对故事板进行更改,提交并将它们推送到存储库。然后 Bob 提取 Alice 的更改并打开情节提要以进行进一步的更改。在他打开故事板的那一刻,文件图标立即变为已修改但未保存的状态,并git status显示发生了许多奇怪的变化。所有这一切都没有 Bob 更改任何内容或自己保存文件。

我们看到的最常见的自动更改是<classes>故事板文件末尾附近整个标签层次结构的消失或重新出现。我们还没有弄清楚是什么原因造成的。我们可能在不同的 .lproj 目录中有几个本地化版本的故事板,当在 Interface Builder 中打开它们时,类层次结构可能会自发地从一些中删除并添加到其他目录中,或者在某些目录中单独存在。这会在 中引起很多噪音git diff,但实际上并没有破坏任何功能。我们通常会选择性地将我们所做的实际更改添加到 git 的索引中,提交这些更改,然后丢弃自发的、无意义的<classes>变化。这是为了保持提交小而漂亮,因为它们应该是。但是,最终,由于 Xcode 不断地重新进行更改,并且有人只是愤怒地提交它们以及其他一些东西......这很好,直到其他人的 Xcode 决定想要将它们改回没有明显的原因。(我们的提交历史对此有很多咒骂。)

还有其他人看到这种行为吗?这是我们的一台或多台开发人员 Mac 上的 Xcode 错误还是配置问题?在与 XIB 文件协作时,我们已经看到了一些类似的行为,但情节提要似乎更容易受到这种影响。

4

6 回答 6

80
于 2013-08-28T09:57:44.827 回答
19

这是 XCode 4.5+ 中的一个错误,我希望它得到修复,是的,它是一个 PITA。

这是Apple的完整错误

如何避免 Xcode 对情节提要文件进行无偿编辑?

于 2012-11-05T13:36:40.200 回答
11

这个问题可以通过非常明智地使用git add -p任何 Xcode 生成的文件来缓解,包括故事板、XIB、核心数据模型和项目文件,所有这些都遭受了对实际界面/模型/没有影响的类似临时修改。项目。

我在情节提要上看到的最常见的垃圾更改是系统版本号(正如您提到的)以及不断添加和删除该<classes>部分,我从未见过遗漏会导致问题。对于 XIB,它是 的添加和删除<reference key="NSWindow"/>,这在 Cocoa Touch 中甚至不是一个类。哇。

把它想象成大海:涨潮和退潮都有。让它冲刷你。

啊。就是这样。

您可以在暂存更改、重置垃圾更改并进行干净提交时忽略这些修改。

从技术角度来看,我在故事板中看到的与 XIB 相比的唯一优势是,Apple 尚未取消 FileMerge 以拒绝合并有冲突的故事板。(FileMerge 曾经能够合并 XIB,但新版本打破了这一点。Thxxxx 伙计们!!!)

请在http://bugreporter.apple.com/上提交有关所有这些问题的大量错误!并且不要忘记在OpenRadar上创建条目。

于 2012-11-20T14:28:29.130 回答
6

Throwing on another answer here because this situation has improved greatly. The XML for the XIB file that represents the StoryBoard has been greatly simplified.

I have also recently bitten the bullet and started to use the interface in Xcode to Source Control. I have been on the command line for years and happy there, but the interface is nice and it lets you split commits, which is really important if you use a ticketing system that links to commits.

Anyway, I noticed today that there was a change on the storyboard and the built in diff showed me it was a single attribute in the document tag (systemVersion). So not a big deal.

I have read articles where people say SBs were outlawed on their teams because of merging issues. Total madness. They are so amazing, especially now that they have intelligent autolayout built in, you are really missing out if you are not using them.

于 2013-11-01T18:14:13.497 回答
3

It's helpful to know why this insanity is happening, but for those who believe in keeping their projects free of warnings and who just want a quick-and-dirty to get their projects back to a healthy state:

  1. Don't commit anything until explicitly instructed.

  2. Open Xcode and create a new storyboard (Command+N > iOS > User Interface > Storyboard). I'll assume you call it the default name of Storyboard.storyboard.

  3. Open the storyboard that Xcode has violated. I'll assume this is Base.lproj/Main.storyboard.

  4. Select and copy everything on the storyboard (Command+A then Command+C).

  5. Open Storyboard.storyboard.

  6. Copy and paste everything into Storyboard.storyboard.

  7. Close Xcode.

  8. Open a terminal and change directories to your repository.

  9. Replace Main.storyboard with Storyboard.storyboard (mv Storyboard.storyboard Base.lproj/Main.storyboard).

  10. git add Base.lproj/Main.storyboard; git commit -m "Fix Xcode's insanity."

  11. Disregard the changes to project.pbxproj via git checkout -- project.pbxproj. If you git diff the file, you'll see that it has just added information about our temporary storyboard (which no longer exists).

  12. Open Xcode back up and see that the warnings has disappeared.

  13. Breathe.

于 2015-07-11T16:26:05.477 回答
0

Working on same storyboard is not a problem. But working on same viewcontroller which creates conflicts on pull/merge is frightening. we can not really avoid that working in same viewcontroller for a large team.

Good thing is, most of the time we can fixed the same viewcontroller conflicts if we understand the xml structure. I never failed to merge these while working in team. Suppose you are working with a viewcontroller. Your view is blank currently. Please ,have a look at the viewcontroller's xml structure from source code option.

enter image description here

Storyboard is xml bounded by document type tag. Everything in the storyboard contains in scene sceneID= tag. scene tag holds every viewcontrollers. Thats the basic.

Now we added a UILabel and a UIButton on the view. Also set the autolayout of the elements. Now it's looks like :

enter image description here

Adding a level/button to viewcontroller added some new code inside the subview tag of the view. Same thing will go for further element addition or any UI changes. Carefully check the tag structure which is really important to fix any conflicts.

Now we add another viewcontroller in the storyboard name Homeviewcontroller. Adding a new viewcontroller means it adds a new scene under scenes tag. Look at this:

enter image description here

At this point, we will change the structure randomly and observe the issues/warnings. We change first viewcontroller label end tag and save the file. Now run it and look at the warning. Error says end tag is not correct which created from line 23. In line 23 , we see a label constrains is set with no end tag. That's the problem. Now we put the end tag and build the project. After setting end tag, we can view the storyboard successfully.

enter image description here

When face any warning of conflicts , please compare with your previous source and changes source. We remove the old/redundant code , keep the new code with proper tag start-end and get things fixed.

[N.B , i will update the answer with some more test cases when get times]

于 2020-03-10T07:44:28.880 回答