我已经进行了几个月的iOS开发，并且刚刚了解到有希望的依赖管理CocoaPods库。

我尝试过了一个个人项目：增加的依赖，以猕猴桃我Podfile，跑步pod install CocoaPodsTest.xcodeproj，和瞧，它的工作太棒了。

我唯一想知道的是：我要签入什么，对于版本控制我应该忽略什么？似乎很明显，我想检入Podfile本身，也可能检入.xcworkspace文件。但是我会忽略Pods /目录吗？在我添加其他.gitignore时是否还会有其他文件生成（当我添加其他依赖项时）？

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

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

我提交我的Pods目录。我不同意Pods目录是一个构建工件。实际上，我肯定会说不是。它是您应用程序源的一部分：没有它，它将无法构建！

将CocoaPods视为开发人员工具而不是构建工具会更容易。它不会构建您的项目，它只会为您克隆并安装您的依赖项。无需安装CocoaPods就可以轻松构建您的项目。

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

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

那么，我该忽略什么呢？没有。Podfile，锁定文件和Pods目录都已提交。相信我，它将为您节省很多麻烦。缺点是什么？一个更大的回购？不是世界末日。

我建议使用GitHub的Objective-C gitignore。详细而言，最佳做法是：

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

有关更多信息，请参阅官方指南。

资料来源：我是CocoaPods核心团队的成员，例如@alloy

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

• CocoaPods不是软件包管理器，因此作者将来可能会删除该库的原始源。
• 如果Pods文件夹包含在源代码管理中，则不必安装CocoaPods来运行项目，因为结帐就足够了。
• CocoaPods仍在开发中，有些选项并不总是会导致相同的结果（例如:head和和:git选项当前未使用存储在中的提交Podfile.lock）。
• 如果您在中/长时间后可以继续进行项目工作，则故障点较少。

.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目录也添加到仓库中，以确保任何给定时间任何开发人员都可以进行检出以及构建和运行。

如果它是我们自己的应用程序，我可能会排除Pods目录，直到我暂时不会使用它为止。

实际上，我必须得出结论，与纯用户的观点相比，我可能不是回答您问题的最佳人选：）我将从https://twitter.com/CocoaPodsOrg鸣叫这个问题。

我检查所有东西。（Pods/和Podfile.lock。）

我希望能够克隆存储库，并知道一切都会像我上次使用该应用程序一样正常工作。

我宁愿卖东西，也不愿冒险因不同版本的gem或有人在Pod的存储库中重写历史记录等导致不同的结果。

答案直接在Cocoapod文档中给出。您可能会看到“ http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control ”

由于工作流程因项目而异，因此，是否签入Pods文件夹取决于您自己。我们建议您将Pods目录保留在源代码控制下，不要将其添加到.gitignore中。但是最终，这个决定取决于您：

签入Pods目录的好处

• 克隆存储库后，即使没有在计算机上安装CocoaPods，项目也可以立即构建并运行。无需运行pod安装，也不需要Internet连接。
• Pod工件（代码/库）始终可用，即使Pod的源（例如GitHub）已关闭。
• 克隆回购协议后，保证Pod构件与原始安装中的构件相同。

忽略Pods目录的好处

• 源代码控制库将更小且占用的空间更少。

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

• 在执行源代码控制操作时（例如合并具有不同Pod版本的分支），不会有任何冲突要处理。

无论您是否签入Pods目录，都应始终将Podfile和Podfile.lock保持在版本控制之下。

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

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

然后，请确保我们在安全的位置拥有这些库的副本。我认为不是（错误地）使用项目的代码存储库来存储依赖项（是否已编译），我认为做到这一点的最佳方法是归档构建。如果将CI服务器用于构建（例如Jenkins），则可以永久存档任何对您重要的构建。如果您在本地Xcode中完成所有生产版本，请养成对需要保留的所有版本进行项目存档的习惯。类似于：1.产品->存档

1. 分发...提交到iOS App Store /保存以进行企业部署或临时部署/您拥有什么

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

3. 右键单击并压缩“ WhateverProject”

这提供了整个项目的竣工图像，包括用于构建应用程序的完整项目和工作空间设置以及二进制发行版（例如Sparkle，专有SDK（例如TestFlight等）），无论它们是否使用CocoaPods。

更新：我已经改变了主意，现在确实将其提交Podfile.lock给源代码管理。但是，我仍然认为，吊舱本身就是构建工件，应该通过源代码控制之外的其他方式（例如，您如上所述的CI服务器或存档过程）进行管理。

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

如果您已修复其中一个Pod内的错误或根据需要修改了某些行为，但是如果未提交这些更改将在其他计算机上不可用，则这也将提供帮助。

并忽略不必要的目录：

xcuserdata/

我必须说，我是将Pod提交到存储库的粉丝。继已经提到的链接会给你一个很好的.gitignore文件起床您的Xcode项目的iOS允许吊舱也为你轻松排除他们，如果你愿意的话：https://github.com/github/gitignore/ blob / master / Objective-C.gitignore

我之所以喜欢将Pods添加到存储库，是因为一个根本的原因（似乎没人在接受），如果突然从网络上删除了我们项目所依赖的库，会发生什么情况？

• 托管人可能决定不再希望保持其GitHub帐户的开放状态如果该库已存在数年（例如，超过5年）会发生什么情况，那么该项目很有可能无法从源头获得
• 还有一点，如果存储库的URL发生更改，会发生什么？可以说，从GitHub帐户服务Pod的人决定用不同的方式来代表自己-您的Pod URL将会中断。
• 最后一点。假设您是像我这样的开发人员，并且在国家/地区之间飞行时需要进行很多编码。我坐在机场时快速拉动“主”分支，在该分支上安装了吊舱，并准备好迎接即将到来的8个小时的飞行。我飞行了3个小时，意识到我需要切换到另一个分支...。'DOH'-缺少Pod信息，该信息仅在'master'分支上可用。

注意：请注意，用于开发的“ master”分支仅作为示例，显然，版本控制系统中的“ master”分支应随时保持清洁和可部署/可构建。

我认为从这些角度来看，代码存储库中的快照肯定比严格限制存储库大小要好。如前所述，podfile.lock文件-在受版本控制的同时，将为您提供Pod版本的良好历史记录。

归根结底，如果您有紧迫的期限，紧缩的预算，时间至关重要，那么我们需要尽可能地足智多谋，不要在严格的意识形态上浪费时间，而是要利用一套工具来共同工作-使我们的生活更轻松，更高效。

最后由您自己决定采取的方法。

这是Cocoapods团队的想法：

由于工作流程因项目而异，因此，是否签入Pods文件夹取决于您自己。我们建议您将Pods目录保留在源代码控制下，不要将其添加到.gitignore中。但是最终，这个决定取决于您。

我个人想保持吊舱出来，因为node_modules如果我使用节点或bower_components如果我使用鲍尔。这适用于几乎所有的Dependency Manager，也是git子模块背后的原理。

但是，有时您可能需要真正确定某个依赖项的最新状态，这样您就可以在项目中自带依赖项。当然，这样做有很多弊端，但关注点不仅适用于Cocoapods，也适用于任何依赖管理器。

下面是Cocoapods小组制定的一个良好的利弊清单，以及前面提到的报价的全文。

Cocoapods小组：我应该将Pods目录检入源代码管理吗？

这取决于个人：

为什么Pod应该是回购协议的一部分（在源代码控制下）并且不应被忽略

• 来源是相同的
• 您可以立即构建它（即使没有cocoapods）
• 即使Pod被删除，我们也仍然拥有它的副本（是的，这确实可以发生，并且确实可以。在一个旧项目中，您只需要进行很小的更改，就需要实现一个新的库才能进行构建）。
• pods.xcodeproj设置也是源代码管理的一部分。这意味着，例如，如果您的项目位于swift 4，但swift 3.2由于尚未更新某些窗格，则必须将其放入其中，这些设置将被保存。否则，克隆回购协议的人将最终出错。
• 您始终可以从项目中删除pod并运行pod install，反之亦然。
• 甚至Cocoapods 的作者也推荐它。

一些缺点：更大的存储库，令人困惑的差异（主要针对团队成员），潜在的更多冲突。

对我来说，最大的担忧是将来要证明您的来源。如果您打算让项目持续一段时间，而CocoaPods曾经消失了，或者其中一个Pod的来源掉了，那么，如果您试图从档案库中重新构建，那么您将完全不走运。

可以通过定期的全源归档来缓解这种情况。

签入Pod。

我认为这应该是软件开发的宗旨

• 所有版本都必须是可复制的
• 确保构建可复制的唯一方法是控制所有依赖项。因此，必须检查所有依赖项。
• 从头开始的新开发人员应能够签出您的项目并开始工作。

为什么？

CocoaPods或任何其他外部库可能会更改，这可能会导致问题。否则它们可能会移动，重命名或完全删除。您不能依靠互联网为您存储东西。您的笔记本电脑可能已经死亡，并且生产中存在严重的错误需要修复。主要开发人员可能会受到公交车的袭击，他的替代者必须急忙启动。我希望最后一个是理论上的例子，但实际上是在我所在的一家初创公司发生的。RIP。

现在，实际上，您不能真正签入所有依赖项。您无法检入用于创建内部版本的机器的映像；您无法检入编译器的确切版本。等等。有现实的限制。但是，请尽一切可能-不这样做只会使您的生活更加艰难。而且我们不想要那样。

总结：豆荚不是造物。构建工件是从构建中生成的东西。您的构建使用Pod，而不是生成它们。我什至不确定为什么要对此进行辩论。

不签入Pods/版本控制的优点（按主观顺序排列）：

1. 很多容易合并提交，并查看代码的diff。合并是代码库中常见问题的来源，这使您可以仅关注与之相关的事情。
2. 对于某些随机贡献者来说，自己无法编辑依赖项并检查其中的更改是不可能的（他们永远都不应这样做）（而且很难确定差异是否很大）。编辑依赖项是非常不好的做法，因为将来pod install可能会遮挡更改。
3. 在队友之间Podfile，Pods/目录和目录之间的差异更快。如果您签入Pods/并更新了中的版本Podfile，但是却忘记了运行pod install或签入对的更改Pods/，那么您将很难注意到差异的根源。如果Pods/未签入，则始终需要运行pod install。
4. 回购规模较小。具有较小的字节占用空间是很好的，但这在宏伟的方案中并没有多大关系。更重要的是：回购中包含更多内容也会增加您的认知负担。没有任何理由让您不应在仓库中查看某些东西。请参考文档（抽象）以了解某些事物的工作原理，而不是代码（实现）。
5. 更容易辨别某人的贡献（因为他们贡献的代码行将不包含他们未编写的依赖项）
6. JAR文件.venv/（虚拟环境），并且node_modules/永远不会包含在版本控制中。如果我们完全不知道该问题，Pods则基于先例，默认情况下不检入。

不检查的缺点Pods/

1. 你必须跑 pod install切换分支或还原提交时。
2. 您不能仅通过克隆存储库来运行项目。您必须安装pod工具，然后运行pod install。
3. 您必须具有Internet连接才能运行pod install，并且pod的来源必须可用。
4. 如果依赖项的所有者删除了他们的程序包，则您会遇到麻烦。

总之，不包括该Pods目录是对更坏的做法护栏。包括在Pods运行的项目更容易目录品牌。我喜欢前者而不是后者。您不需要进行汇报的关于“什么样的项目每一个新的人不会做”，如果没有在第一个地方使某些失误的可能性。我也喜欢为它提供单独版本控制以Pods减轻Cons 的想法。

从理论上讲，您应该签入Pods目录。实际上，它并不总是有效。许多Pod超出了github文件的大小限制，因此，如果您使用github，则在Pods目录中检查时会出现问题。

TL; DR：跟踪Pods/文件夹时，更容易从中提取项目。当您不跟踪它时，在团队中工作时更容易进行改进。

尽管Cocoapods组织鼓励我们跟踪Pods/目录，但他们说，由开发人员根据这些优点和缺点决定是否执行此目录：http :  //guides.cocoapods.org/using/using-cocoapods.html ＃should-i-check-the-pods-directory-to-source-control

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

另一方面，我认为提交历史记录变得更整洁，并且在您不跟踪Pods/文件夹时更容易合并代码并查看其他人的代码。我通常在安装时安装cocoapod库的版本，以确保任何人都可以使用与我相同的版本来安装项目。

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

底线：当您跟踪Pods/文件夹时，更容易从中提取项目。如果您不跟踪它，则更容易进行改进。

看来，构建此结构的好方法实际上是将“ Pods”目录作为git子模块/单独的项目，这就是原因。

• 与多个开发人员一起工作时，在项目存储库中包含Pod可能会导致拉取请求中的差异非常大，几乎看不到人为更改的实际工作（例如，为库更改了数百至数千个文件，而只有一个在实际项目中很少更改）。

• 我看到了不向git提交任何内容的问题，因为拥有该库的人可以随时删除它，而您本质上是SOL，这也解决了这一问题。

由于工作流程因项目而异，因此，是否签入Pods文件夹取决于您自己。我们建议您将Pods目录保留在源代码控制下，不要将其添加到.gitignore中。但是最终，这个决定取决于您：

签入Pods目录的好处

1. 克隆存储库后，即使没有在计算机上安装CocoaPods，项目也可以立即构建并运行。无需运行pod安装，也不需要Internet连接。
2. Pod工件（代码/库）始终可用，即使Pod的源（例如GitHub）已关闭。
3. 克隆回购协议后，保证Pod构件与原始安装中的构件相同。

忽略Pods目录的好处

1. 源代码控制库将更小且占用的空间更少。只要所有Pod的源代码（例如GitHub）都可用，CocoaPods通常就可以重新创建相同的安装。 。在Podfile中使用zip文件时尤其如此。）
2. 在执行源代码控制操作时（例如合并具有不同Pod版本的分支），不会有任何冲突要处理。无论您是否签入Pods目录，都应始终将Podfile和Podfile.lock保持在版本控制之下。