我更喜欢与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.

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

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

Cocoapods团队是这么想的:

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

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

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

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

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

我提交我的Pods目录。我不同意Pods目录是一个构建产物。事实上，我想说它绝对不是。它是应用程序源代码的一部分:没有它就无法构建!

我们更容易将CocoaPods视为开发工具，而不是构建工具。它不构建你的项目，它只是为你克隆和安装你的依赖项。为了能够简单地构建项目，不应该必须安装CocoaPods。

通过使CocoaPods成为构建的依赖项，您现在需要确保它在构建项目所需的任何地方都可用……团队管理员需要它，您的CI服务器需要它。通常，您应该始终能够克隆源存储库并进行构建，而不需要做任何进一步的工作。

如果你频繁切换分支，不提交pod目录也会造成巨大的麻烦。现在，每次切换分支时都需要运行pod install，以确保依赖项是正确的。当你的依赖关系稳定时，这可能不那么麻烦，但在项目早期，这是一个巨大的时间消耗。

我忽略了什么?什么都没有。Podfile，锁文件和Pods目录都被提交。相信我，这会帮你省去很多麻烦。缺点是什么?更大一点的回购?又不是世界末日。

Cocoapod文档中直接给出了答案。你可以看看“http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control”。

Whether or not you check in your Pods folder is up to you, as workflows vary from project to project. We recommend that you keep the Pods directory under source control, and don't add it to your .gitignore. But ultimately this decision is up to you: Benefits of checking in the Pods directory After cloning the repo, the project can immediately build and run, even without having CocoaPods installed on the machine. There is no need to run pod install, and no Internet connection is necessary. The Pod artifacts (code/libraries) are always available, even if the source of a Pod (e.g. GitHub) were to go down. The Pod artifacts are guaranteed to be identical to those in the original installation after cloning the repo. Benefits of ignoring the Pods directory The source control repo will be smaller and take up less space. As long as the sources (e.g. GitHub) for all Pods are available, CocoaPods is generally able to recreate the same installation. (Technically there is no guarantee that running pod install will fetch and recreate identical artifacts when not using a commit SHA in the Podfile. This is especially true when using zip files in the Podfile.) There won't be any conflicts to deal with when performing source control operations, such as merging branches with different Pod versions. Whether or not you check in the Pods directory, the Podfile and Podfile.lock should always be kept under version control.