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

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

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


当前回答

我建议使用GitHub的Objective-C gitignore。 具体来说,最佳实践是:

Podfile必须始终处于源代码控制之下。 Podfile。Lock必须始终处于源代码控制之下。 CocoaPods生成的工作区应该保持在源代码控制之下。 任何使用:path选项引用的Pod都应该保存在源代码控制下。 ./Pods文件夹可以保存在源代码控制下。

要了解更多信息,您可以参考官方指南。

来源:我是CocoaPods核心团队的成员,就像@alloy一样


尽管Pods文件夹是一个构建工件,但在决定是否将其置于源代码控制之下时,您可能会考虑以下原因:

CocoaPods is not a package manager so the original source of the library could be removed in future by the author. If the Pods folder is included in source control, it is not necessary to install CocoaPods to run the project as the checkout would suffice. CocoaPods is still work in progress and there are options which don’t always lead to the same result (for example the :head and the :git options currently are not using the commits stored in the Podfile.lock). There are less points of failure if you might resume work on a project after a medium/long amount of time.

其他回答

我属于不签入库的开发人员阵营,假设我们在其他位置有一个好的副本可用。因此,在我的.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服务器或如上所述的存档过程。

.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的讨论。

就个人而言,这取决于:

为什么pod应该是repo的一部分(在源代码控制下)并且不应该被忽略

The source is identical You can build it right away as is (even without the cocoapods) Even if a pod is deleted, we still have its copy (Yes, this can happen and it did. In an old project where you want just a small change you would need to implement a new library to be able to even build). pods.xcodeproj settings are part of the source control as well. This means e.g. if you have the project in swift 4, but some pods must be in swift 3.2 because they are not updated yet, these settings will be saved. Otherwise the one who cloned the repo would end up with errors. You can always delete pods from the project and run pod install, the opposite can not be done. Even the authors of the Cocoapods recommend it.

缺点:更大的存储库,令人困惑的差异(主要针对团队成员),潜在的冲突更多。

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

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

我必须说,我是将pod提交到存储库的粉丝。按照前面提到的链接,你会得到一个很好的。gitignore文件来启动你的iOS Xcode项目,以允许Pods,但如果你愿意,你也可以轻松地排除它们:https://github.com/github/gitignore/blob/master/Objective-C.gitignore

我之所以热衷于将pod添加到存储库中,有一个根本原因,但似乎没有人注意到,如果我们的项目如此依赖的库突然从网络上删除了,会发生什么?

Maybe the host decides they no longer want to keep their GitHub account open What happens if the library is say several years old (like older than 5 years for example) there is a high risk the project may no longer be available at source Also another point, what happens if the URL to the repository changes? Lets say the person serving the Pod from their GitHub account, decides to represent themselves under a different handle - your Pods URLs are going to break. Finally another point. Say if you're a developer like me who does a lot of coding when on a flight between countries. I do a quick pull on the 'master' branch, do a pod install on that branch, while sitting in the airport and have myself all set for the upcoming 8 hour flight. I get 3 hours into my flight, and realise I need to switch to another branch.... 'DOH' - missing Pod information which is only available on the 'master' branch.

NB……请注意,用于开发的“主”分支只是举个例子,很明显,版本控制系统中的“主”分支应该保持干净,并且在任何时候都可以部署/构建

我认为从这些方面来看,在代码存储库中创建快照肯定比严格限制存储库大小要好。如前所述,播客文件。锁文件-而版本控制将给你一个良好的Pod版本历史。

在一天结束的时候,如果你有一个紧迫的截止日期,预算紧张,时间是至关重要的——我们需要尽可能多的资源,不要把时间浪费在严格的意识形态上,而是利用一套工具一起工作——让我们的生活更容易、更有效。