最后取决于你采取的方法。

Cocoapods团队是这么想的:

是否检查您的Pods文件夹取决于您，因为 工作流程因项目而异。我们建议您保留 pod目录下的源代码控制，不要将它添加到您的 .gitignore。但最终这个决定取决于你。

就我个人而言，我想把Pods排除在外，如果我使用Node，就像node_modules，如果我使用Bower，就像bower_components。这适用于几乎所有的依赖管理器，也是git子模块背后的理念。

然而，有时你可能想要真正确定某个依赖项的最新状态，这样你才能在项目中拥有该依赖项。当然，如果您这样做，会有一些缺点，但这些问题不仅适用于Cocoapods，而且适用于任何依赖管理器。

下面是Cocoapods团队制作的利弊清单，以及之前提到的引文全文。

Cocoapods团队:我应该将Pods目录检入源代码控制吗?

检查舱。

我认为这应该成为软件开发的一个原则

所有构建都必须是可复制的 确保构建的唯一方法是 可复制性是指控制所有依赖关系;全部签到 因此，依赖性是必须的。 一个从头开始的新开发人员应该能够检查您的项目并开始工作。

Why?

CocoaPods或任何其他外部库可能会改变，这可能会破坏事情。或者它们可能会移动，或者被重新命名，或者完全被移除。你不能依赖互联网为你储存东西。你的笔记本电脑可能死机了，生产中有一个严重的bug需要修复。主要开发人员可能会被公共汽车撞到，而他的替代者不得不匆忙启动。我希望最后一个例子只是理论上的但它确实发生在我工作的一家初创公司。撕裂的声音。

现在，实际上，您不能真正检入所有依赖项。您不能检入用于创建构建的机器的映像;你不能检入编译器的确切版本。等等。有现实的限制。但是你要尽可能地检查——不这样做只会让你的生活更加艰难。我们不希望这样。

最后一句话:pod不是构建工件。构建构件是从构建中生成的。您的构建使用Pods，而不是生成它们。我都不知道为什么要讨论这个问题。

对我来说，最重要的是将来证明你的来源。如果您计划让您的项目持续一段时间，而CocoaPods消失了，或者其中一个pod的源代码崩溃了，那么如果试图从存档中重新构建，那么您就完全不走运了。

这可以通过定期的全源档案来缓解。

我属于不签入库的开发人员阵营，假设我们在其他位置有一个好的副本可用。因此，在我的.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”目录作为一个git子模块/单独的项目似乎是一种很好的结构方式，原因如下。

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

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

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