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

签入Pods目录的好处

克隆repo之后，项目可以立即构建和运行，甚至不需要在机器上安装CocoaPods。不需要运行pod install，也不需要连接互联网。 Pod构件(代码/库)总是可用的，即使Pod的源(例如GitHub)宕机。 克隆repo后，Pod工件保证与原始安装中的工件相同。

忽略Pods目录的好处

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.

我建议使用GitHub的Objective-C gitignore。 具体来说，最佳实践是:

Podfile必须始终处于源代码控制之下。 Podfile。Lock必须始终处于源代码控制之下。 CocoaPods生成的工作区应该保持在源代码控制之下。 任何使用:path选项引用的Pod都应该保存在源代码控制下。 ./Pods文件夹可以保存在源代码控制下。

要了解更多信息，您可以参考官方指南。

来源:我是CocoaPods核心团队的成员，就像@alloy一样

尽管Pods文件夹是一个构建工件，但在决定是否将其置于源代码控制之下时，您可能会考虑以下原因:

CocoaPods is not a package manager so the original source of the library could be removed in future by the author. If the Pods folder is included in source control, it is not necessary to install CocoaPods to run the project as the checkout would suffice. CocoaPods is still work in progress and there are options which don’t always lead to the same result (for example the :head and the :git options currently are not using the commits stored in the Podfile.lock). There are less points of failure if you might resume work on a project after a medium/long amount of time.

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.

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

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

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

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

签入Pods目录的好处

克隆repo之后，项目可以立即构建和运行，甚至不需要在机器上安装CocoaPods。不需要运行pod install，也不需要连接互联网。 Pod构件(代码/库)总是可用的，即使Pod的源(例如GitHub)宕机。 克隆repo后，Pod工件保证与原始安装中的工件相同。

忽略Pods目录的好处

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.

我必须说，我是将pod提交到存储库的粉丝。按照前面提到的链接，你会得到一个很好的。gitignore文件来启动你的iOS Xcode项目，以允许Pods，但如果你愿意，你也可以轻松地排除它们:https://github.com/github/gitignore/blob/master/Objective-C.gitignore

我之所以热衷于将pod添加到存储库中，有一个根本原因，但似乎没有人注意到，如果我们的项目如此依赖的库突然从网络上删除了，会发生什么?

Maybe the host decides they no longer want to keep their GitHub account open What happens if the library is say several years old (like older than 5 years for example) there is a high risk the project may no longer be available at source Also another point, what happens if the URL to the repository changes? Lets say the person serving the Pod from their GitHub account, decides to represent themselves under a different handle - your Pods URLs are going to break. Finally another point. Say if you're a developer like me who does a lot of coding when on a flight between countries. I do a quick pull on the 'master' branch, do a pod install on that branch, while sitting in the airport and have myself all set for the upcoming 8 hour flight. I get 3 hours into my flight, and realise I need to switch to another branch.... 'DOH' - missing Pod information which is only available on the 'master' branch.

NB……请注意，用于开发的“主”分支只是举个例子，很明显，版本控制系统中的“主”分支应该保持干净，并且在任何时候都可以部署/构建

我认为从这些方面来看，在代码存储库中创建快照肯定比严格限制存储库大小要好。如前所述，播客文件。锁文件-而版本控制将给你一个良好的Pod版本历史。

在一天结束的时候，如果你有一个紧迫的截止日期，预算紧张，时间是至关重要的——我们需要尽可能多的资源，不要把时间浪费在严格的意识形态上，而是利用一套工具一起工作——让我们的生活更容易、更有效。