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/文件夹时，项目更容易从其中获取。当你不追踪它的时候，就更容易改进。

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

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

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

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

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

.gitignore file

没有答案真的提供了。gitignore，所以这里有两种口味。

在Pods目录中检查(好处)

Xcode/iOS友好的git忽略，跳过Mac OS系统文件，Xcode，构建，其他存储库和备份。

. gitignore:

# Mac OS X Finder
.DS_Store

# Private Keys
*.pem

# Xcode legacy
*.mode1
*.mode1v3
*.mode2v3
*.perspective
*.perspectivev3
*.pbxuser

# Xcode
xcuserdata/
project.xcworkspace/
DerivedData/

# build products
build/
*.[oa]

# repositories
.hg
.svn
CVS

# automatic backup files
*~.nib
*.swp
*~
*(Autosaved).rtfd/
Backup[ ]of[ ]*.pages/
Backup[ ]of[ ]*.key/
Backup[ ]of[ ]*.numbers/

忽略Pods目录(好处)

.gitignore:(附加到前面的列表)

# Cocoapods
Pods/

不管你是否检查Pods目录，Podfile和Podfile。Lock应该始终保持在版本控制之下。

如果pod没有签入，您的Podfile可能需要为每个Cocoapod请求明确的版本号。Cocoapods.org的讨论。

我通常在客户端的应用程序上工作。在这种情况下，我也将Pods目录添加到repo中，以确保在任何给定的时间，任何开发人员都可以进行签出、构建和运行。

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

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

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.