我属于不签入库的开发人员阵营，假设我们在其他位置有一个好的副本可用。因此，在我的.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目录添加到repo中，以确保在任何给定的时间，任何开发人员都可以进行签出、构建和运行。

如果这是我们自己的应用程序，我可能会排除Pods目录，直到我有一段时间不会使用它。

事实上，我必须得出结论，相对于纯用户的观点，我可能不是回答你的问题的最佳人选:)我会在https://twitter.com/CocoaPodsOrg上发布关于这个问题的推文。

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

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

每件事我都要登记。(Pods/和Podfile.lock。)

我希望能够克隆存储库，并知道一切将只是工作，因为它上次我使用的应用程序。

我宁愿把东西卖进来，也不愿意冒险，因为不同版本的宝石可能会导致不同的结果，或者有人重写Pod的存储库中的历史等等。

我更喜欢与Podfile和Podfile一起提交Pods目录。锁定，以确保我的团队中的任何人都可以随时签出源代码，他们不必担心任何事情或做额外的事情来使其工作。

如果您在某个pod中修复了一个错误，或者根据需要修改了一些行为，但如果没有提交，这些更改将无法在其他机器上使用，那么这也会有所帮助。

忽略不必要的目录:

xcuserdata/

不签入pod /版本控制的优点(按重要性的主观顺序):

Much easier to merge commits, and review code diffs. Merging is a common source of issues in a code base, and this allows you to focus only on things that are pertinent. It's impossible for some random contributor to edit the dependencies themselves and check the changes in, which they should never do (and again would be hard to identify if the diff is massive). Editing dependencies is very bad practice because a future pod install could occlude the changes. Discrepancies between the Podfile and the Pods/ directory are found quicker among teammates. If you check in Pods/ and, for example, update a version in the Podfile, but forget to run pod install or check in the changes to Pods/, you will have a much harder time noticing the source of the discrepancy. If Pods/ isn't checked in, you always need to run pod install anyway. Smaller repo size. Having a smaller byte-footprint is nice, but that doesn't matter much in the grand scheme. More importantly: having more things in the repo also increases your cognitive load. There is no reason to have things in the repo that you shouldn't be looking at. Refer to documentation (the abstraction) to know how something works, not at code (the implementation). Easier to discern how much someone contributes (since their lines of code contributed won't include dependencies they didn't write) JAR files, .venv/ (virtual environments), and node_modules/ are never included in version control. If we were completely agnostic about the question, not checking in Pods would be the default based on precedent.

不检查pod的缺点/

切换分支或还原提交时必须运行pod install。 您不能仅仅通过克隆存储库来运行项目。您必须安装pod工具，然后运行pod install。 你必须有互联网连接才能运行pod install，而且pod的源代码必须可用。 如果依赖的所有者删除了他们的包，你就不能使用它(尽管你一开始就不应该使用已弃用的依赖——这只会迫使你更早地进行依赖卫生)。

总之，不包含Pods目录是防止更多不良做法的屏障。包含Pods目录可以使项目更容易运行。比起后者，我更喜欢前者。如果一开始就不存在犯某些错误的可能性，那么你就不需要向项目中的每个新人汇报“什么不能做”。我也喜欢有一个单独的版本控制Pods的想法，这减轻了缺点。