如果你使用CocoaPods，那么你的.gitignore会怎么样？

我已经做了几个月的iOS开发，刚刚学习了用于依赖pipe理的有前途的CocoaPods库。

我在一个个人项目上试了一下：在我的Podfile中添加了一个对Kiwi的依赖，运行了pod install CocoaPodsTest.xcodeproj ， 瞧 ，它工作的很好。

我唯一想知道的是：我该如何检查，以及我对版本控制忽略了什么？ 似乎很明显，我想检查Podfile本身，也可能是.xcworkspace文件; 但是我忽略Pods /目录？ 是否还有其他文件将被生成（当我添加其他的依赖项）时，我也应该添加到我的.gitignore？

Answer 1

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

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

Answer 2

我提交我的Pods目录。 我不同意Pods目录是一个构build的东西。 其实我会说这绝对不是。 这是你的应用程序源的一部分：它不会没有它的构build！

把CocoaPods当作开发者工具而不是构build工具比较容易。 它不会build立你的项目，它只是克隆和安装你的依赖。 不需要安装CocoaPods就可以简单地构build你的项目。

通过使CocoaPods成为你的构build的依赖，你现在需要确保它可以在任何需要构build项目的地方都可用……团队pipe理员需要它，你的CI服务器需要它。 通常，您应该始终能够克隆源代码库并进行构build，而无需进一步的努力。

如果您经常切换分支，不提交您的Pods目录也会造成大量头痛。 现在，您需要每次切换分支时运行pod安装，以确保您的依赖关系是正确的。 当你的依赖稳定时，这可能不那么麻烦，但在一个项目的早期，这是一个巨大的时间。

那么，我忽略了什么？ 没有。 Podfile，锁文件和Pods目录都被提交。 相信我，它会为你节省很多麻烦。 有什么缺点？ 稍大的回购？ 不是世界末日。

Answer 3

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

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

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

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

---

虽然Pods文件夹是构build工件，但在决定是否将其保留在源代码控制之下时，您可能会考虑以下原因：

• CocoaPods不是一个软件包pipe理器，因此作者将来可以删除该库的原始源代码。
• 如果Pods文件夹包含在源代码控制中，则不需要安装CocoaPods来运行该项目，因为结帐就足够了。
• CocoaPods仍在继续工作，有些选项并不总是导致相同的结果（例如:head和:git选项当前不使用存储在Podfile.lock中的Podfile.lock ）。
• 如果您可能在中等/长时间后恢复项目的工作，那么失败的几率就会降低。

Answer 4

我通常在客户端的应用程序上工作。 在这种情况下，我还将Pods目录添加到回购库，以确保在任何给定时间任何开发人员都可以执行结帐并构build和运行。

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

其实，我必须得出结论，我可能不是最好的人回答你的问题，而不是纯粹的用户观点:)我会推特从https://twitter.com/CocoaPodsOrg这个问题。;

Answer 5

.gitignore文件

没有答案实际上提供了一个.gitignore ，所以这里有两种口味。

---

检查Pods目录 （ 优点 ）

Xcode / iOS友好的git忽略，跳过Mac OS系统文件，Xcode，构build，其他存储库和备份。

的.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 在这里讨论。

Answer 6

我检查一切。 （ Pods/和Podfile.lock 。）

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

我宁愿提供的东西比风险有不同的结果，可能是由不同版本的gem，或重写在Pod的存储库中的历史等造成的结果。

Answer 7

假设我们在另一个地方有一个好的副本，我就在没有检查图书馆的开发者的阵营里。 所以，在我的.gitignore中，我包含了CocoaPods特有的以下几行：

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

然后我确定我们有一个安全的地方的图书馆的副本。 而不是（错误）使用项目的代码库来存储依赖项（编译与否）我认为这样做的最好方法是归档生成。 如果你为你的版本使用CI服务器（比如Jenkins），你可以永久地存档对你来说重要的任何版本。 如果您在本地Xcode中执行所有生产版本，请习惯于为您需要保留的任何版本创build项目存档。 如下所示：1.产品 – >归档

1. 分发…提交到iOS应用程序商店/保存为企业或临时部署/你有什么

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

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

这提供了一个完整的项目的图像，包括用于构build应用程序的完整项目和工作区设置以及二进制发行版（如Sparkle，TestFlight等专有SDK），而不pipe它们是否使用CocoaPods。

更新：我已经改变了我的想法，现在提交Podfile.lock到源代码pipe理。 不过，我仍然认为，豆荚本身就是构build工件，应该在源代码控制之外，通过另一种方法（如CI服务器或上述的归档过程）进行pipe理。

Answer 8

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

这也有助于在某个场景中修复了一个错误，或根据需要修改了某些行为，但如果没有提交，这些更改将不能在其他机器上使用。

并忽略不必要的目录：

 xcuserdata/ 

Answer 9

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

无论您是否检入Pods文件夹都取决于您，因为工作stream程因项目而异。 我们build议您将Pods目录保持在源代码pipe理下，并且不要将其添加到.gitignore中。 但最终这个决定取决于你：

检查Pods目录的好处

• 克隆回购之后，即使没有在机器上安装CocoaPods，项目也可以立即生成并运行。 没有必要运行pod安装，并且不需要Internet连接。
• Pod工件（代码/库）始终可用，即使Pod（例如GitHub）的源代码被closures。
• 克隆回购之后，Pod工件保证与原始安装中的相同。

忽略Pods目录的好处

• 源代码pipe理回购将更小，占用更less的空间。

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

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

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

Answer 10

我必须说，我是提交Pods到版本库的粉丝。 下面的链接已经提到会给你一个良好的.gitignore文件，以获得你的Xcode项目的iOS允许豆荚，但也可以轻松地排除他们，如果你愿意： https ： //github.com/github/gitignore/斑点/主/目标-C.gitignore

我之所以把这个Pod添加到版本库是因为一个根本的原因，似乎没有人愿意接受，如果我们的项目如此依赖的一个库突然从networking上移除，会发生什么？

• 也许主持人决定不再希望保持他们的GitHub账户开放如果图书馆说几年（比如5年以上）就会发生什么情况，项目可能无法从源头获得
• 另外还有一点，如果存储库的URL改变了，会发生什么？ 比方说，从他们的GitHub帐户服务Pod的人，决定代表自己在不同的句柄下 – 你的Podsurl将被打破。
• 最后还有一点。 说如果你是像我这样的开发者，在国家之间的航class上做了大量的编码工作。 我快速拉上了“主人”分支，在那个分支上做了一个吊舱安装，同时坐在机场，让我自己都准备好了即将到来的8小时的飞行。 我得到了3个小时的飞行，并意识到我需要切换到另一个分支….“DOH” – 丢失了只在“主”分支上可用的Pod信息。

注意……请注意，“master”分支的发展只是例子，显然版本控制系统中的“主”分支应该保持清洁，可随时部署/build立

我认为，从代码仓库中获取快照肯定比严格限制仓库大小要好。 正如已经提到的那样，podfile.lock文件 – 受版本控制时会为您提供Pod版本的良好历史logging。

在一天结束的时候，如果你有一个紧迫的期限，预算紧张，时间是关键 – 我们需要尽可能的机智，不要浪费时间在严格的意识形态上，而是利用一套工具一起工作 – 让我们的生活更加高效

Answer 11

最后是你采取的方法。

这就是Cocoapods团队对此的看法：

无论您是否检入Pods文件夹都取决于您，因为工作stream程因项目而异。 我们build议您将Pods目录保持在源代码pipe理下，并且不要将其添加到.gitignore中。 但最终这个决定取决于你。

就个人而言，我想保留Pods ，如果我正在使用Node，则使用node_modules;如果使用Bower，则使用bower_components 。 这几乎适用于所有的依赖经理，也是git子模块背后的哲学。

然而，有时候你可能想确定某个依赖关系的状态，这样你就可以在你的项目中拥有自己的依赖关系。 当然，如果你这样做有几个缺点，但是关注不仅适用于Cocoapods，那些Cocoapods也适用于任何依赖pipe理器。

下面是Cocoapods团队制作的优秀/劣势清单，以及前面提到的报价全文。

Cocoapods团队：我应该检查Pods目录到源代码pipe理？

Answer 12

对我来说，最大的担忧是未来打击您的来源。 如果你打算让你的项目持续一段时间，而CocoaPods永远消失或者其中一个豆荚的源头崩溃，那么如果试图从档案库中build立新的，那么你完全不幸运。

这可以通过定期的全部源文件来缓解。

Answer 13

检查豆荚。

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

• 所有的构build必须是可重现的
• 确保构build可重复的唯一方法是控制所有的依赖关系; 因此检查所有的依赖关系是必须的。
• 从头开始的新开发人员应能检查出您的项目并开始工作。

为什么？

CocoaPods或任何其他外部库可能会改变这可能会破坏的东西。 或者他们可能会移动，或者被重命名，或者被完全移除。 你不能依赖互联网来为你储存东西。 您的笔记本电脑可能已经死亡，生产中存在一个严重的缺陷，需要修复。 主要的开发商可能会被公共汽车撞上，而他的替代品也要急着启动。 我希望最后一个是一个理论的例子，但实际上发生在我一起的一个创业公司。 安息。

现在，实际上，你不能真正检查所有的依赖关系。 您无法检入用于创build构build的机器的映像; 你不能检查编译器的确切版本。 等等。 有现实的限制。 但是请尽可能地检查 – 不这样做只会让你的生活变得更难。 而我们不需要这个。

最后一句话：豆荚不是build造的文物。 构build工件是从您的构build生成的。 你的构build使用Pod，不生成它们。 我甚至不确定为什么要这样做。

Answer 14

看起来像一个很好的方式来构build这真的是将“豆荚”目录作为一个git子模块/单独的项目，这是为什么。

• 在你的项目仓库里有豆荚的时候，当和几个开发人员一起工作的时候，可能会导致很大的差异，在几乎不可能看到人们改变的实际工作的情况下（认为数百到数千个文件改变了，在实际项目中几乎没有改变）。

• 我看到没有提交任何东西的问题，因为拥有该库的人可以在任何时候把它取下来，而你本质上是SOL，这也解决了这个问题。

Answer 15

无论您是否检入Pods文件夹都取决于您，因为工作stream程因项目而异。 我们build议您将Pods目录保持在源代码pipe理下，并且不要将其添加到.gitignore中。 但最终这个决定取决于你：

检查Pods目录的好处

1. 克隆回购之后，即使没有在机器上安装CocoaPods，项目也可以立即生成并运行。 没有必要运行pod安装，并且不需要Internet连接。
2. Pod工件（代码/库）始终可用，即使Pod（例如GitHub）的源代码被closures。
3. 克隆回购之后，Pod工件保证与原始安装中的相同。

忽略Pods目录的好处

1. 源代码pipe理回购将更小，占用更less的空间。 只要所有Pod的源代码（例如GitHub）都可用，CocoaPods通常可以重新创build相同的安装（从技术上讲，不能保证在Podfile中不使用提交SHA时运行的pod安装将获取并重新创build相同的工件。在Podfile中使用zip文件时尤其如此。）
2. 执行源代码控制操作时不会有任何冲突，例如合并具有不同Pod版本的分支。 无论您是否检入Pods目录，Podfile和Podfile.lock应始终保持在版本控制之下。

Answer 16

理论上，您应该检查Pods目录。 在实践中，它并不总是工作。 许多豆荚远远超过了github文件的大小限制，所以如果你使用的是github，你将在豆荚目录中检查问题。

Answer 17

个人看来，

为什么豆荚应该是回购的一部分（在源代码pipe理下），不应该被忽略

• 来源是相同的
• 你可以立即build造它（即使没有椰子树）
• 即使删除了一个pod，我们仍然有它的副本（是的，这可能会发生，而且在一个旧的项目中，只需要一个小小的改动就可以实现一个新的库，甚至可以build立）。
• pods.xcodeproj设置也是源代码pipe理的一部分。 这意味着，例如，如果您的项目在swift 4 ，但某些Pod必须在swift 3.2因为它们尚未更新，这些设置将被保存。 否则克隆回购的人最终会出错。
• 您始终可以从项目中删除窗格并运行pod install ，反之则无法完成。
• 即使是Cocoapods的作者也推荐它。

一些缺点：较大的存储库，混淆（主要是团队成员），可能更多的冲突。