初学者指南：在Xcode中进行协作

您和您的团队已经开始使用Xcode进行黑客入侵。 在第一次合并尝试中，您会看到那些被注定的单词-CONFLICT 。 没关系，您之前已经处理过合并冲突。 除非您没有处理情节提要合并冲突。 或奇怪的软件包命名冲突。 或每次都涉及不记得创建的隐藏目录的冲突。

为什么合作如此痛苦？

两个字： 情节提要。

故事板本身是一个巨大的xml文件。 所有内容，从放置按钮的位置到实际放置视图控制器的位置（甚至不包含其中的内容，仅是视图控制器的位置）都保存在其中。 这意味着，即使您的队友甚至稍微移动视图，也将发生合并冲突。

一旦情节提要中发生合并冲突，就无法再在Xcode中对其进行渲染。 您的应用无法启动。 什么都行不通。

合并这些冲突可能非常困难。 您必须确保xml有效，这意味着所有标记均已关闭。 当情节提要xml文件可能长达数千行时，尤其糟糕。 故事板显然并不适合人类的目光，而且冲突之所以可怕，是因为变化几乎是随机的，这意味着您可能会花费数小时来尝试找出最后的标记或错字。

一般的良好做法是避免使用大型情节提要 。 但是，即使只有几个视图控制器的情节提要也很难处理。

其他协作问题涉及Xcode如何打包您的应用程序，以便您可以在设备上运行它，以及用于维护项目设置，文件结构等的所有元数据。 但是，与情节提要不同，解决这些问题至少不会使您发疯。

因此，请记住以下一些策略，可以使您的生活更轻松。

正确设置Git回购

这是标准的。 确保您的项目具有良好的gitignore （https://github.com/github/gitignore/blob/master/Swift.gitignore），这将有助于解决许多隐藏文件夹问题。

但是，如果您实际使用拉取请求 ，也会有所帮助。

Xcode项目非常脆弱，小事情会导致整个事情停止运行。 如果每个人都推动掌握，即使他们的项目在本地工作，也很可能导致主人中断。 为了避免不得不处理时髦的git命令来回滚提交（基本上，使一切变得混乱），让某人管理master分支并测试pull请求将使您的10倍轻松。

这也假定您也使用分支 。 请。 使用它们。 为不相互依赖的功能建立分支。 模块化工作。 这将帮助您专注于开发，而不是每次需要拉动或推入时都要清理git repo。

处理情节提要

这是处理情节提要的几种不同方法，每种方法各有利弊。

用一台笔记本电脑制作情节提要。 然后请一个人（只有那个人）更改情节提要。

这非常适合小型团队，因为在情节提要之外还有很多事情要做（例如模型逻辑，编写助手等）。 在一个会话中，您可以设置基本的视图控制器，按钮和插座。 之后，只需告诉情节提要的人您需要什么，然后让他们将您的功能连接到视图即可。 您的情节提要人员将处理情节提要的更改，创建主题，IBOutlets等。如果您也关注MVC，那就很好。

电子邮件代码。

这真糟糕。 请。 您确实应该只采用上述策略。

但是，如果必须的话，只需一个人控制项目的“主”工作分支，然后让其他所有人通过电子邮件将代码发送给该人。

从字面上讲整个项目的一台笔记本电脑。

很明显，这样做的利弊是什么。 一方面，您永远不会遇到来自其他人的合并问题，而且您可以结对编程！ 另一方面，并​​行处理不同功能可能很困难。 你的来电。

编写所有代码。

当您对所有内容使用代码时，合并要容易得多。 如果确保只有一个人进行编辑，则可以将其与情节提要结合使用。 最后，走这条路线取决于团队的习惯。 请注意，由于您看不到正在更改的内容，因此代码会使原型开发变慢，并且重构也会变慢。

使用笔尖/笔尖。

故事板的问题在于它们很大，因此可能存在不止一个人愿意从事的工作。 笔尖就像导轨查看局部。 它们更小，模块化，可重用，并且可以推入任何视图控制器的视图中。 然后，您可以将其与第一个策略结合使用！

我不是在这里教您笔尖是如何工作的，但是概述是这样的：

• 与在情节提要板上分配自定义viewcontroller相似，您将自定义uiview分配给笔尖
• 在您的viewcontroller代码中，您可以加载一个笔尖（viewDidLoad），然后将其添加到视图中。 例如，我将使我的视图控制器具有一个UIStackView，为该UIStackView制作一个IBOutlet，然后推入笔尖
• 笔尖可以使用自动布局，因此，如果您希望占用父母宽度的100％，则可以这样做。
• 如果需要，您可以使用笔尖以编程方式查看内容（请参见“所有内容的代码”）。

如果有多个人更改笔尖，则会出现相同的冲突问题。 但是，由于开销较少，这些冲突更易于处理，并且由于项目通常具有许多笔尖（而不是拥有一个巨大的故事板）而发生的次数较少。 话虽如此，请避免做10000件事的胖笔尖 ，否则您会遇到胖故事板遇到的相同问题。

结论

最后，您应该选择适合您团队的策略。 这意味着，如果没有人了解或想了解笔尖，那么就不要。 如果人们不想以编程的方式做事情，那就不要。 您可以混合并匹配笔尖，代码和情节提要。 最后，目标是避免哑合并冲突，因此您可以专注于完成工作。

虽然作为使用过代码，笔尖和情节提要的人，我会说我最喜欢的三个是笔尖。

对于一些扩展阅读，这里有一些不错的资源：

• https://www.toptal.com/ios/ios-ios-user-interfaces-storyboards-vs-nibs-vs-custom-code
• http://www.scott-sherwood.com/tutorial/storyboards-and-nibs-when-to-use-which-and-how-to-mix/