我已经做了几个月的iOS开发了，刚刚了解到有前途的用于依赖管理的CocoaPods库。
我在一个个人项目中尝试过:在我的Podfile中添加了对Kiwi的依赖，运行pod install CocoaPodsTest。Xcodeproj，瞧，它工作得很好。
我唯一想知道的是:我要签入什么，为了版本控制我要忽略什么?似乎很明显，我想签入Podfile本身，也可能是.xcworkspace文件;但是我是否忽略了Pods/目录?是否还会生成其他文件(当我添加其他依赖项时)，也应该添加到.gitignore中?
当前回答
TL;DR:当你跟踪Pods/文件夹时，项目更容易 从。当你不跟踪它的时候，就更容易在时间上进行改进 你在一个团队中工作。
虽然Cocoapods组织鼓励我们跟踪Pods/目录，但他们说这取决于开发人员根据这些利弊来决定是否这样做:http://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control
就我个人而言，我通常只跟踪那些我暂时不会再做的项目的Pods/文件夹。这样，任何开发人员都可以快速地从中吸取教训，并使用合适的cocoapods版本继续工作。
另一方面，我认为当你不跟踪Pods/文件夹时，提交历史会变得更清晰，更容易合并代码和审查其他人的代码。我通常在安装cocoapod库时设置它的版本，以确保任何人都可以使用与我相同的版本安装项目。
此外，当pod /目录被跟踪时，所有开发人员都必须使用相同版本的Cocoapods，以防止每次我们运行pod install来添加/删除pod时更改数十个文件。
底线:当您跟踪Pods/文件夹时，项目更容易从其中获取。当你不追踪它的时候，就更容易改进。
其他回答
就我个人而言，我不检查Pods目录和内容。我不能说我花了很长时间来考虑这些影响，但我的推理是这样的:
Podfile引用了每个依赖项的特定标记或提交，因此pod本身可以从Podfile生成，因此它们更像一个中间构建产品而不是源代码，因此，在我的项目中不需要版本控制。
我提交我的Pods目录。我不同意Pods目录是一个构建产物。事实上，我想说它绝对不是。它是应用程序源代码的一部分:没有它就无法构建!
我们更容易将CocoaPods视为开发工具，而不是构建工具。它不构建你的项目，它只是为你克隆和安装你的依赖项。为了能够简单地构建项目，不应该必须安装CocoaPods。
通过使CocoaPods成为构建的依赖项，您现在需要确保它在构建项目所需的任何地方都可用……团队管理员需要它，您的CI服务器需要它。通常，您应该始终能够克隆源存储库并进行构建，而不需要做任何进一步的工作。
如果你频繁切换分支，不提交pod目录也会造成巨大的麻烦。现在，每次切换分支时都需要运行pod install，以确保依赖项是正确的。当你的依赖关系稳定时，这可能不那么麻烦，但在项目早期，这是一个巨大的时间消耗。
我忽略了什么?什么都没有。Podfile，锁文件和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服务器或如上所述的存档过程。
理论上，您应该在Pods目录中进行检查。在实践中，这并不总是有效的。许多pod都超过了github文件的大小限制，所以如果你使用github，你将会在检查pods目录时遇到问题。
TL;DR:当你跟踪Pods/文件夹时，项目更容易 从。当你不跟踪它的时候，就更容易在时间上进行改进 你在一个团队中工作。
虽然Cocoapods组织鼓励我们跟踪Pods/目录，但他们说这取决于开发人员根据这些利弊来决定是否这样做:http://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control
就我个人而言，我通常只跟踪那些我暂时不会再做的项目的Pods/文件夹。这样，任何开发人员都可以快速地从中吸取教训，并使用合适的cocoapods版本继续工作。
另一方面，我认为当你不跟踪Pods/文件夹时，提交历史会变得更清晰，更容易合并代码和审查其他人的代码。我通常在安装cocoapod库时设置它的版本，以确保任何人都可以使用与我相同的版本安装项目。
此外，当pod /目录被跟踪时，所有开发人员都必须使用相同版本的Cocoapods，以防止每次我们运行pod install来添加/删除pod时更改数十个文件。
底线:当您跟踪Pods/文件夹时，项目更容易从其中获取。当你不追踪它的时候，就更容易改进。
