我已经做了几个月的iOS开发了，刚刚了解到有前途的用于依赖管理的CocoaPods库。
我在一个个人项目中尝试过:在我的Podfile中添加了对Kiwi的依赖，运行pod install CocoaPodsTest。Xcodeproj，瞧，它工作得很好。
我唯一想知道的是:我要签入什么，为了版本控制我要忽略什么?似乎很明显，我想签入Podfile本身，也可能是.xcworkspace文件;但是我是否忽略了Pods/目录?是否还会生成其他文件(当我添加其他依赖项时)，也应该添加到.gitignore中?
当前回答
我通常在客户端的应用程序上工作。在这种情况下，我也将Pods目录添加到repo中，以确保在任何给定的时间，任何开发人员都可以进行签出、构建和运行。
如果这是我们自己的应用程序，我可能会排除Pods目录，直到我有一段时间不会使用它。
事实上，我必须得出结论，相对于纯用户的观点，我可能不是回答你的问题的最佳人选:)我会在https://twitter.com/CocoaPodsOrg上发布关于这个问题的推文。
其他回答
我属于不签入库的开发人员阵营，假设我们在其他位置有一个好的副本可用。因此，在我的.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服务器或如上所述的存档过程。
检查舱。
我认为这应该成为软件开发的一个原则
所有构建都必须是可复制的 确保构建的唯一方法是 可复制性是指控制所有依赖关系;全部签到 因此，依赖性是必须的。 一个从头开始的新开发人员应该能够检查您的项目并开始工作。
Why?
CocoaPods或任何其他外部库可能会改变，这可能会破坏事情。或者它们可能会移动，或者被重新命名，或者完全被移除。你不能依赖互联网为你储存东西。你的笔记本电脑可能死机了，生产中有一个严重的bug需要修复。主要开发人员可能会被公共汽车撞到，而他的替代者不得不匆忙启动。我希望最后一个例子只是理论上的但它确实发生在我工作的一家初创公司。撕裂的声音。
现在，实际上，您不能真正检入所有依赖项。您不能检入用于创建构建的机器的映像;你不能检入编译器的确切版本。等等。有现实的限制。但是你要尽可能地检查——不这样做只会让你的生活更加艰难。我们不希望这样。
最后一句话:pod不是构建工件。构建构件是从构建中生成的。您的构建使用Pods，而不是生成它们。我都不知道为什么要讨论这个问题。
每件事我都要登记。(Pods/和Podfile.lock。)
我希望能够克隆存储库，并知道一切将只是工作，因为它上次我使用的应用程序。
我宁愿把东西卖进来，也不愿意冒险，因为不同版本的宝石可能会导致不同的结果，或者有人重写Pod的存储库中的历史等等。
对我来说，最重要的是将来证明你的来源。如果您计划让您的项目持续一段时间，而CocoaPods消失了，或者其中一个pod的源代码崩溃了，那么如果试图从存档中重新构建，那么您就完全不走运了。
这可以通过定期的全源档案来缓解。
我提交我的Pods目录。我不同意Pods目录是一个构建产物。事实上，我想说它绝对不是。它是应用程序源代码的一部分:没有它就无法构建!
我们更容易将CocoaPods视为开发工具，而不是构建工具。它不构建你的项目，它只是为你克隆和安装你的依赖项。为了能够简单地构建项目，不应该必须安装CocoaPods。
通过使CocoaPods成为构建的依赖项，您现在需要确保它在构建项目所需的任何地方都可用……团队管理员需要它，您的CI服务器需要它。通常，您应该始终能够克隆源存储库并进行构建，而不需要做任何进一步的工作。
如果你频繁切换分支，不提交pod目录也会造成巨大的麻烦。现在，每次切换分支时都需要运行pod install，以确保依赖项是正确的。当你的依赖关系稳定时，这可能不那么麻烦，但在项目早期，这是一个巨大的时间消耗。
我忽略了什么?什么都没有。Podfile，锁文件和Pods目录都被提交。相信我，这会帮你省去很多麻烦。缺点是什么?更大一点的回购?又不是世界末日。
