如果你正在使用CocoaPods，你的.gitignore会有什么？

Question

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

我在个人项目上尝试过：向我的Podfile添加了Kiwi依赖项，运行pod install CocoaPodsTest.xcodeproj和 voila ，它运行良好。

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

Answer 1

我提交了我的Pods目录。我并不同意Pods目录是一个构建工件。事实上，我说它绝对不是。它是您的应用程序源的一部分：没有它就不会构建它！

将CocoaPods视为开发人员工具而不是构建工具更容易。它不构建您的项目，它只是为您克隆和安装您的依赖项。安装CocoaPods是不必要的，以便能够简单地构建您的项目。

通过使CocoaPods成为您构建的依赖项，您现在需要确保它可用于构建项目所需的任何位置......团队管理员需要它，您的CI服务器需要它。作为一项规则，您应始终能够克隆源存储库并构建，而无需任何进一步的努力。

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

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

Answer 2

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

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

Answer 3

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

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

有关详细信息，请参阅official guide。

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

---

虽然Pods文件夹是一个构建工件，但在决定使用它时，您可能会考虑将其保持在源代码控制之下：

• CocoaPods不是包管理器，因此作者将来可以删除该库的原始来源。
• 如果Pods文件夹包含在源代码管理中，则无需安装CocoaPods来运行项目，因为结帐就足够了。
• CocoaPods仍在进行中，并且有些选项并不总是会导致相同的结果（例如:head和:git选项当前未使用Podfile.lock中存储的提交{1}}）。
• 如果您可以在中等/很长时间后恢复项目工作，那么失败的程度就会减少。

Answer 4

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

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

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

Answer 5

.gitignore文件

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

检入Pods目录（Benefits）

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目录（Benefits）

.gitignore： （附加到上一个列表）

# Cocoapods
Pods/

  

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

如果未登记Pods，则Podfile应该为每个Cocoapod请求明确的版本号。 Cocoapods.org讨论here。

Answer 6

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

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

我宁愿供应商品而不是风险，因为不同版本的宝石可能导致不同的结果，或有人在Pod的存储库中重写历史记录等。

Answer 7

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

  

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

     

签入Pods目录的好处

     

  
• 克隆了repo后，即使没有在机器上安装CocoaPods，项目也可以立即构建和运行。没有   需要运行pod安装，并且不需要Internet连接。
  
• Pod工件（代码/库）始终可用，即使Pod的源（例如GitHub）发生故障也会消失。
  
• 克隆回购后，保证Pod工件与原始安装中的工件相同。
  

     

忽略Pods目录的好处

     

  

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

  

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

  

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

  

     

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

Answer 8

假设我们在另一个地方有一个好的副本，我就是不会检查图书馆的开发人员阵营。所以，在我的.gitignore中，我包含了以下特定于CocoaPods的行：

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

然后我确保我们在安全的位置有一个库的副本。而不是（错误地）使用项目的代码存储库来存储依赖项（编译与否）我认为最好的方法是归档构建。如果为构建使用CI服务器（例如Jenkins），则可以永久存档对您很重要的任何构建。如果您在本地Xcode中执行所有生产版本，那么习惯于为您需要保留的任何版本存档项目。就像是： 1.产品 - ＆gt;归档

1. 分发...提交到iOS App Store / Save for Enterprise或Ad-hoc Deployment /你有什么

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

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

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

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

Answer 9

我更喜欢提交Pods目录以及Podfile和Podfile.lock，以确保我的团队中的任何人都可以随时查看来源，他们不必担心任何事情或做其他事情让它发挥作用的东西。

这也有助于您修复其中一个pod中的错误或根据您的需要修改某些行为，但如果未提交，这些更改将无法在其他计算机上使用。

忽略不必要的目录：

xcuserdata/

Answer 10

我必须说，我是将Pods提交到存储库的粉丝。在已经提到的链接之后，将为您提供一个好的.gitignore文件来启动iOS的Xcode项目以允许Pod，但如果您愿意，也可以轻松地将它们排除：https://github.com/github/gitignore/blob/master/Objective-C.gitignore

我想成为将Pod添加到存储库的粉丝的原因是出于一个根本原因，似乎没有人接受，如果我们的项目如此依赖的库突然从Web中删除会发生什么？

• 也许主持人决定他们不再想保留他们的GitHub 帐户开放如果图书馆说几年之后会发生什么 （比如年龄超过5年）存在高风险 项目可能不再在源头提供
• 另外一点，如果存储库的URL会发生什么 变化？让我们说从他们的GitHub服务Pod的人 帐户，决定在不同的句柄下代表自己 - 您的Pods URL将会中断。
• 最后另一点。假如你是一个像我这样的开发人员，他做了很多事情 在国家之间的航班上编码。我快点拉 'master'分支，坐在那个分支上做pod安装 在机场，我自己都准备好了即将到来的8小时 飞行。我进入飞行3小时，意识到我需要切换到 另一个分支....'DOH' - 缺少Pod信息，只能在'master'分支上找到。

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

我认为，从这些中，代码存储库中的快照肯定比严格存储库大小更好。如前所述，podfile.lock文件 - 在受版本控制的情况下，可以为您提供Pod版本的良好历史记录。

在一天结束时，如果你有一个紧迫的截止日期，预算紧张，时间至关重要 - 我们需要尽可能多的资源，而不是浪费时间在严格的意识形态上，而是利用一套工具共同努力 - 让我们的生活更轻松，更高效。

Answer 11

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

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

  

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

我个人希望将 Pods 保留为 node_modules ，如果我使用 Node 或 bower_components 如果我使用 Bower 。这适用于几乎所有的Dependency Manager，并且是 git子模块背后的哲学。

但是，有时您可能希望确定某个依赖项的最新，这样您就可以在项目中拥有自己的依赖项。当然，如果您这样做有几个缺点，但是问题不仅适用于Cocoapods，那些适用于那里的任何Dependency Manager。

下面有一个由Cocoapods团队制作的好的优点/缺点列表，以及之前提到的报价的全文。

Cocoapods team: Should I check the Pods directory into source control?

Answer 12

这取决于个人：

为什么pod应该成为repo的一部分（在源代码管理下）并且不应该被忽略

• 来源相同
• 您可以像一样立即构建它（即使没有cocoapods）
• 即使删除了一个pod，我们仍然拥有它的副本（是的，这可能会发生，而且确实如此。在一个只需要进行少量更改的旧项目中，您需要实现一个新库才能够甚至建立）。
• pods.xcodeproj设置也是源代码管理的一部分。这意味着例如如果项目位于swift 4，但某些广告单元必须位于swift 3.2，因为它们尚未更新，则会保存这些设置。否则克隆回购的人最终会出错。
• 您可以随时从项目中删除pod并运行pod install，但相反的方法无法完成。
• 即使Cocoapods的作者也推荐它。

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

Answer 13

检查Pods。

我认为这应该是软件开发的原则

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

为什么？

CocoaPods或任何其他外部库可能会改变，这可能会破坏事物。或者他们可能会移动，或重命名，或完全删除。你不能依靠互联网为你存储东西。您的笔记本电脑可能已经死亡，生产中存在一个需要修复的严重错误。主要的开发人员可能会受到公共汽车的打击，他的更换必须匆忙启动。我希望最后一个是理论上的例子，但它确实发生在我所在的创业公司。 RIP。

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

最后一句话：Pod不是构建工件。构建工件是从构建中生成的。您的构建使用Pod，而不是生成它们。我甚至不确定为什么要讨论这个问题。

Answer 14

对我来说，最大的担忧是未来证明您的来源。如果你打算让你的项目持续一段时间并且CocoaPods消失或者其中一个pod的来源出现故障，那么如果你想从存档中构建新的东西，那么你将完全失去运气。

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

Answer 15

不是{em> not 的专家，他们在Pods/中进行版本控制（按主观的重要性顺序）：

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

not 在Pods/

中检查的缺点

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

总的来说，不包含Pods目录的 是防止更多不良做法的护栏。 包含 Pods目录使运行项目更加容易。我喜欢前者而不是后者。如果没有可能首先犯某些错误，那么您无需向项目中的每个新人汇报“该做什么”。我还喜欢为Pods使用单独的版本控制来减轻弊端的想法。

Answer 16

您是否签入Pods文件夹取决于您，因为工作流程因项目而异。我们建议您将Pods目录保留在源代码管理下，并且不要将其添加到.gitignore。但最终这个决定取决于你：

签入Pods目录的好处

1. 克隆了repo后，即使没有在机器上安装CocoaPods，项目也可以立即构建和运行。无需运行pod安装，也无需连接Internet。
2. Pod工件（代码/库）始终可用，即使Pod的源（例如GitHub）发生故障也会消失。
3. 克隆回购后，保证Pod工件与原始安装中的工件相同。

忽略Pods目录的好处

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

Answer 17

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

Answer 18

看起来像一个很好的结构方法，这真的是将“Pods”目录作为git子模块/单独的项目，这就是原因。

• 在项目仓库中使用pod时，在与多个开发人员合作时，可能会在拉取请求中导致非常大的差异，几乎不可能看到人们改变的实际工作（想想几百到几千个文件发生了变化）对于图书馆而言，实际项目中只有少数人改变了。

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

Answer 19

  

TL; DR：跟踪Pods/文件夹时，该项目更容易   从接。如果您不跟踪它，则可以更轻松地改进   你是一个团队中的工作。

尽管Cocoapods组织鼓励我们跟踪Pods/目录，但他们说要由开发人员根据以下优点和缺点来决定是否这样做：http://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control

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

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

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

底线：当您跟踪Pods/文件夹时，可以更轻松地提取项目。如果您不进行跟踪，则可以更轻松地进行改进。