我已经做了几个月的iOS开发了,刚刚了解到有前途的用于依赖管理的CocoaPods库。

我在一个个人项目中尝试过:在我的Podfile中添加了对Kiwi的依赖,运行pod install CocoaPodsTest。Xcodeproj,瞧,它工作得很好。

我唯一想知道的是:我要签入什么,为了版本控制我要忽略什么?似乎很明显,我想签入Podfile本身,也可能是.xcworkspace文件;但是我是否忽略了Pods/目录?是否还会生成其他文件(当我添加其他依赖项时),也应该添加到.gitignore中?


当前回答

对我来说,最重要的是将来证明你的来源。如果您计划让您的项目持续一段时间,而CocoaPods消失了,或者其中一个pod的源代码崩溃了,那么如果试图从存档中重新构建,那么您就完全不走运了。

这可以通过定期的全源档案来缓解。

其他回答

就我个人而言,我不检查Pods目录和内容。我不能说我花了很长时间来考虑这些影响,但我的推理是这样的:

Podfile引用了每个依赖项的特定标记或提交,因此pod本身可以从Podfile生成,因此它们更像一个中间构建产品而不是源代码,因此,在我的项目中不需要版本控制。

每件事我都要登记。(Pods/和Podfile.lock。)

我希望能够克隆存储库,并知道一切将只是工作,因为它上次我使用的应用程序。

我宁愿把东西卖进来,也不愿意冒险,因为不同版本的宝石可能会导致不同的结果,或者有人重写Pod的存储库中的历史等等。

我通常在客户端的应用程序上工作。在这种情况下,我也将Pods目录添加到repo中,以确保在任何给定的时间,任何开发人员都可以进行签出、构建和运行。

如果这是我们自己的应用程序,我可能会排除Pods目录,直到我有一段时间不会使用它。

事实上,我必须得出结论,相对于纯用户的观点,我可能不是回答你的问题的最佳人选:)我会在https://twitter.com/CocoaPodsOrg上发布关于这个问题的推文。

最后取决于你采取的方法。

Cocoapods团队是这么想的:

是否检查您的Pods文件夹取决于您,因为 工作流程因项目而异。我们建议您保留 pod目录下的源代码控制,不要将它添加到您的 .gitignore。但最终这个决定取决于你。

就我个人而言,我想把Pods排除在外,如果我使用Node,就像node_modules,如果我使用Bower,就像bower_components。这适用于几乎所有的依赖管理器,也是git子模块背后的理念。

然而,有时你可能想要真正确定某个依赖项的最新状态,这样你才能在项目中拥有该依赖项。当然,如果您这样做,会有一些缺点,但这些问题不仅适用于Cocoapods,而且适用于任何依赖管理器。

下面是Cocoapods团队制作的利弊清单,以及之前提到的引文全文。

Cocoapods团队:我应该将Pods目录检入源代码控制吗?

将“Pods”目录作为一个git子模块/单独的项目似乎是一种很好的结构方式,原因如下。

在项目回购中使用pod,当与多个开发人员一起工作时,可能会在pull请求中造成非常大的差异,几乎不可能看到人们更改的实际工作(想象一下库更改了数百到数千个文件,而实际项目中只更改了少数文件)。 我看到了不向git提交任何东西的问题,因为拥有库的人可以随时删除它,而你实际上是SOL,这也解决了这个问题。