我已经做了几个月的iOS开发了，刚刚了解到有前途的用于依赖管理的CocoaPods库。
我在一个个人项目中尝试过:在我的Podfile中添加了对Kiwi的依赖，运行pod install CocoaPodsTest。Xcodeproj，瞧，它工作得很好。
我唯一想知道的是:我要签入什么，为了版本控制我要忽略什么?似乎很明显，我想签入Podfile本身，也可能是.xcworkspace文件;但是我是否忽略了Pods/目录?是否还会生成其他文件(当我添加其他依赖项时)，也应该添加到.gitignore中?
当前回答
将“Pods”目录作为一个git子模块/单独的项目似乎是一种很好的结构方式，原因如下。
在项目回购中使用pod，当与多个开发人员一起工作时，可能会在pull请求中造成非常大的差异，几乎不可能看到人们更改的实际工作(想象一下库更改了数百到数千个文件，而实际项目中只更改了少数文件)。 我看到了不向git提交任何东西的问题，因为拥有库的人可以随时删除它，而你实际上是SOL，这也解决了这个问题。
其他回答
我更喜欢与Podfile和Podfile一起提交Pods目录。锁定，以确保我的团队中的任何人都可以随时签出源代码，他们不必担心任何事情或做额外的事情来使其工作。
如果您在某个pod中修复了一个错误，或者根据需要修改了一些行为，但如果没有提交，这些更改将无法在其他机器上使用，那么这也会有所帮助。
忽略不必要的目录:
xcuserdata/
将“Pods”目录作为一个git子模块/单独的项目似乎是一种很好的结构方式，原因如下。
在项目回购中使用pod，当与多个开发人员一起工作时，可能会在pull请求中造成非常大的差异，几乎不可能看到人们更改的实际工作(想象一下库更改了数百到数千个文件，而实际项目中只更改了少数文件)。 我看到了不向git提交任何东西的问题，因为拥有库的人可以随时删除它，而你实际上是SOL，这也解决了这个问题。
就个人而言，这取决于:
为什么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目录中进行检查。在实践中，这并不总是有效的。许多pod都超过了github文件的大小限制，所以如果你使用github，你将会在检查pods目录时遇到问题。
我属于不签入库的开发人员阵营，假设我们在其他位置有一个好的副本可用。因此，在我的.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服务器或如上所述的存档过程。
