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

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

忽略不必要的目录:

xcuserdata/

我必须说，我是将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版本历史。

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

检查舱。

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

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

Why?

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

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

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

我建议使用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.

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

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

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

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

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

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

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

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