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

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

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

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

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

我属于不签入库的开发人员阵营，假设我们在其他位置有一个好的副本可用。因此，在我的.gitignore中，我包含了以下针对CocoaPods的行:

Pods/
#Podfile.lock  # changed my mind on Podfile.lock

1. 分配……提交到iOS应用商店/保存为企业或Ad-hoc部署/等等

2. 在Finder中显示您的项目文件夹

3. 右键压缩WhateverProject

这提供了整个项目的构建映像，包括用于构建应用程序的完整项目和工作区设置，以及二进制发行版(如Sparkle，专有sdk，如TestFlight等)，无论他们是否使用CocoaPods。

我已经改变了我的想法，现在将Podfile.lock提交给源代码控制。然而，我仍然相信pod本身是构建工件，应该在源代码控制之外进行管理，通过另一种方法，如CI服务器或如上所述的存档过程。

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

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

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

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

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

忽略不必要的目录:

xcuserdata/

我建议使用GitHub的Objective-C gitignore。 其中，最佳实践为:

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

有关更多信息，您可以参考官方指南。

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

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

• CocoaPods不是一个包管理器，因此作者可以在将来删除库的原始源代码。
• 如果Pods文件夹包含在源代码控制中，则不需要安装CocoaPods来运行项目，因为签出就足够了。
• CocoaPods仍在进行中，有一些选项并不总是会导致相同的结果(例如:head和:git选项目前没有使用存储在Podfile.lock中的提交)。
• 如果你能在一段中长时间后重新开始一个项目，那么失败的点就会更少。

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

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

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

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

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

将“Pods”目录作为一个git子模块/单独的项目似乎是一种很好的结构方式，原因如下。

• 在项目回购中使用pod，当与多个开发人员一起工作时，可能会在pull请求中造成非常大的差异，几乎不可能看到人们更改的实际工作(想象一下库更改了数百到数千个文件，而实际项目中只更改了少数文件)。

• 我看到了不向git提交任何东西的问题，因为拥有库的人可以随时删除它，而你实际上是SOL，这也解决了这个问题。

对我来说，最重要的是将来证明你的来源。如果您计划让您的项目持续一段时间，而CocoaPods消失了，或者其中一个pod的源代码崩溃了，那么如果试图从存档中重新构建，那么您就完全不走运了。

这可以通过定期的全源档案来缓解。

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

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

可能主机决定不再保留他们的GitHub 如果图书馆有几年的历史，会发生什么 (例如5岁以上)有很高的风险 项目在source可能不再可用 还有一点，如果存储库的URL 变化?让我们假设从他们的GitHub服务Pod的人 帐户，决定代表自己在一个不同的处理- 你的Pods的url会崩溃
• 最后一分。如果你是像我一样的开发人员，你会做很多事情 在国家间的航班上编程。我快速拉上 “主”分支，做一个豆荚安装在那个分支，而坐 在机场，为接下来的8个小时做好准备 飞行。我坐了3个小时的飞机，意识到我需要换到 另一个分支…'DOH' -缺失Pod信息，仅在'master'分支上可用

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

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

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

检查舱。

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

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

为什么?

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

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

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

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

签入Pods目录的好处

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

忽略Pods目录的好处

1. 源代码控制回购将更小，占用更少的空间。 只要所有pod的源代码(例如GitHub)都可用，CocoaPods通常能够重新创建相同的安装。(从技术上讲，在pod文件中不使用提交SHA时，不能保证运行pod install将获取和重新创建相同的工件。在Podfile中使用zip文件时尤其如此。 在执行源代码控制操作时，例如合并不同Pod版本的分支时，不会有任何冲突需要处理。 不管你是否检查Pods目录，Podfile和Podfile。锁应始终保持在版本控制下

最后取决于你采取的方法。

Cocoapods团队是这么想的:

你是否检查你的Pods文件夹是由你决定的，因为 工作流程因项目而异。我们建议您保留 pod目录下的源代码控制，不要将它添加到您的 .gitignore。

.但是最终这个决定取决于你

就我个人而言，我想把豆荚排除在外，如果我使用节点，就像node_modules，如果我使用鲍尔，就像bower_components。这适用于几乎所有的依赖管理器，也是git子背后的哲学。

然而，有时你可能想要真正确定某个依赖项的技术发展水平，这样你就可以在你的项目中拥有这个依赖项。当然，如果您这样做，会有一些缺点，但这些问题不仅适用于Cocoapods，而且适用于任何依赖管理器。

下面是Cocoapods团队制作的优点/缺点列表，以及前面提到的引用的全文。

Cocoapods团队:我应该把Pods目录检查到源代码控制中吗?< / >

.gitignore文件

没有答案实际上提供了.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应该始终保持在版本控制之下。

如果Pods没有签入，你的Podfile可能应该为每个Cocoapod请求显式的版本号。Cocoapods.org讨论在这里。

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

Cocoapod文档中直接给出了答案。你可以看看"http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control"

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

签入Pods目录的好处

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

忽略Pods目录的好处

• 源代码控制回购将更小，占用更少的空间。

只要所有pod的源代码(例如GitHub)都可用，CocoaPods通常能够重新创建相同的安装。 (从技术上讲，运行pod install并不能保证将获取 中未使用提交SHA时，重新创建相同的工件 Podfile。在Podfile中使用zip文件时尤其如此)

• 在执行源代码控制操作时不会有任何冲突需要处理，例如合并不同Pod的分支 李的版本。< / p > < / >

是否检查Pods目录，Podfile和 Podfile。锁应始终保持在版本控制下

就个人而言，这取决于:

为什么pod应该是repo的一部分(在源代码控制下)并且不应该被忽略

• 来源是相同的
• 你可以像(即使没有茧足类动物)一样立即构建它
• 即使删除了一个pod，我们仍然有它的副本(是的，这可能发生，而且确实发生了。在一个旧的项目中，你只想要一个小的改变，你需要实现一个新的库，甚至能够构建)。
• pods.xcodeproj设置也是源代码控制的一部分。这意味着，例如，如果你的项目在swift 4中，但一些pod必须在swift 3.2中，因为它们还没有更新，这些设置将被保存。否则，克隆回购的人最终会出现错误。
• 你总是可以从项目中删除pod并运行pod install，反之则不行。
• 甚至Cocoapods的作者也推荐它。

缺点:更大的存储库，令人困惑的差异(主要针对团队成员)，潜在的冲突更多。

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

0. 多更容易合并提交，并审查代码差异。合并是代码库中常见的问题来源，这允许您只关注相关的内容。
1. 对于一些随机的贡献者来说，自己编辑依赖关系并检查其中的更改是不可能的，他们不应该这样做(如果差异很大，也很难识别)。编辑依赖关系是非常糟糕的做法，因为将来的pod install可能会阻塞这些更改。
2. Podfile和Pods/目录之间的差异在队友中更快地被发现。如果你签入Pods/，例如，在Podfile中更新了一个版本，但忘记运行pod install或签入对Pods/的更改，你将很难注意到差异的来源。如果Pods/没有签入，你总是需要运行pod install。
3. 更小的回购规模。拥有一个更小的字节占用是很好的，但在大方案中这并不重要。更重要的是:回购更多的东西也会增加你的认知负荷。没有理由在回购中有你不应该看的东西。参考文档(抽象)来了解事物是如何工作的，而不是参考代码(实现)。
4. 更容易看出某人贡献了多少(因为他们贡献的代码行不包括他们没有编写的依赖项)
5. JAR文件、.venv/(虚拟环境)和node_modules/从来不包含在版本控制中。如果我们完全不知道这个问题，不检入Pods将是基于先例的默认值。

不检入Pods/ . xml的缺点

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

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

TL;DR:当你跟踪Pods/文件夹时，项目更容易 从。当你不跟踪它的时候，就更容易在时间上进行改进 你在团队中工作。

虽然Cocoapods组织鼓励我们跟踪Pods/目录，但他们说这取决于开发人员根据以下利弊来决定是否这样做

就我个人而言，我通常只跟踪Pods/文件夹的项目，我不会再工作一段时间。这样，任何开发人员都可以快速地从中吸取教训，并使用合适的cocoapods版本继续工作。

另一方面，当你没有跟踪Pods/文件夹时，我认为提交历史会变得更干净，更容易合并代码和审查其他人的代码。我通常在安装cocoapod库时设置它的版本，以确保任何人都可以使用与我相同的版本安装项目。

此外，当Pods/目录被跟踪时，所有的开发人员都必须使用相同版本的Cocoapods，以防止每次我们运行pod install来添加/删除pod时更改数十个文件。

底线:当你跟踪Pods/文件夹时，项目更容易从其中获取。当你不追踪它的时候，就更容易改进。