检查舱。

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

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

Why?

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

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

最后一句话:pod不是构建工件。构建构件是从构建中生成的。您的构建使用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.

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

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

忽略不必要的目录:

xcuserdata/

是否检入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.

理论上，您应该在Pods目录中进行检查。在实践中，这并不总是有效的。许多pod都超过了github文件的大小限制，所以如果你使用github，你将会在检查pods目录时遇到问题。

不签入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的想法，这减轻了缺点。