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

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

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


当前回答

我属于不签入库的开发人员阵营,假设我们在其他位置有一个好的副本可用。因此,在我的.gitignore中,我包含了以下针对CocoaPods的行:

Pods/
#Podfile.lock  # changed my mind on Podfile.lock

Then I make sure that we have a copy of the libraries in a safe location. Rather than (mis-)use a project's code repository to store dependencies (compiled or not) I think the best way to do this is to archive builds. If you use a CI server for your builds (such as Jenkins) you can permanently archive any builds that are important to you. If you do all your production builds in your local Xcode, make a habit of taking an archive of your project for any builds you need to keep. Something like: 1. Product --> Archive

分配……提交到iOS应用商店/保存为企业或Ad-hoc部署/等等 在Finder中显示您的项目文件夹 右键压缩WhateverProject

这提供了整个项目的构建映像,包括用于构建应用程序的完整项目和工作区设置,以及二进制发行版(如Sparkle,专有sdk,如TestFlight等),无论他们是否使用CocoaPods。

更新:我已经改变了我的想法,现在提交Podfile。锁定源代码控制。然而,我仍然相信pod本身是构建工件,应该在源代码控制之外进行管理,通过另一种方法,如CI服务器或如上所述的存档过程。

其他回答

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

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

.gitignore file

没有答案真的提供了。gitignore,所以这里有两种口味。


在Pods目录中检查(好处)

Xcode/iOS友好的git忽略,跳过Mac OS系统文件,Xcode,构建,其他存储库和备份。

. gitignore:

# Mac OS X Finder
.DS_Store

# Private Keys
*.pem

# Xcode legacy
*.mode1
*.mode1v3
*.mode2v3
*.perspective
*.perspectivev3
*.pbxuser

# Xcode
xcuserdata/
project.xcworkspace/
DerivedData/

# build products
build/
*.[oa]

# repositories
.hg
.svn
CVS

# automatic backup files
*~.nib
*.swp
*~
*(Autosaved).rtfd/
Backup[ ]of[ ]*.pages/
Backup[ ]of[ ]*.key/
Backup[ ]of[ ]*.numbers/

忽略Pods目录(好处)

.gitignore:(附加到前面的列表)

# Cocoapods
Pods/

不管你是否检查Pods目录,Podfile和Podfile。Lock应该始终保持在版本控制之下。

如果pod没有签入,您的Podfile可能需要为每个Cocoapod请求明确的版本号。Cocoapods.org的讨论。

我属于不签入库的开发人员阵营,假设我们在其他位置有一个好的副本可用。因此,在我的.gitignore中,我包含了以下针对CocoaPods的行:

Pods/
#Podfile.lock  # changed my mind on Podfile.lock

Then I make sure that we have a copy of the libraries in a safe location. Rather than (mis-)use a project's code repository to store dependencies (compiled or not) I think the best way to do this is to archive builds. If you use a CI server for your builds (such as Jenkins) you can permanently archive any builds that are important to you. If you do all your production builds in your local Xcode, make a habit of taking an archive of your project for any builds you need to keep. Something like: 1. Product --> Archive

分配……提交到iOS应用商店/保存为企业或Ad-hoc部署/等等 在Finder中显示您的项目文件夹 右键压缩WhateverProject

这提供了整个项目的构建映像,包括用于构建应用程序的完整项目和工作区设置,以及二进制发行版(如Sparkle,专有sdk,如TestFlight等),无论他们是否使用CocoaPods。

更新:我已经改变了我的想法,现在提交Podfile。锁定源代码控制。然而,我仍然相信pod本身是构建工件,应该在源代码控制之外进行管理,通过另一种方法,如CI服务器或如上所述的存档过程。

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

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

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

我提交我的Pods目录。我不同意Pods目录是一个构建产物。事实上,我想说它绝对不是。它是应用程序源代码的一部分:没有它就无法构建!

我们更容易将CocoaPods视为开发工具,而不是构建工具。它不构建你的项目,它只是为你克隆和安装你的依赖项。为了能够简单地构建项目,不应该必须安装CocoaPods。

通过使CocoaPods成为构建的依赖项,您现在需要确保它在构建项目所需的任何地方都可用……团队管理员需要它,您的CI服务器需要它。通常,您应该始终能够克隆源存储库并进行构建,而不需要做任何进一步的工作。

如果你频繁切换分支,不提交pod目录也会造成巨大的麻烦。现在,每次切换分支时都需要运行pod install,以确保依赖项是正确的。当你的依赖关系稳定时,这可能不那么麻烦,但在项目早期,这是一个巨大的时间消耗。

我忽略了什么?什么都没有。Podfile,锁文件和Pods目录都被提交。相信我,这会帮你省去很多麻烦。缺点是什么?更大一点的回购?又不是世界末日。