我已经做了几个月的 iOS 开发，刚刚了解到用于依赖管理的有前途的 CocoaPods 库。
我在一个个人项目上进行了尝试：将 Kiwi 的依赖项添加到我的 Podfile 中，运行 pod install CocoaPodsTest.xcodeproj，瞧，效果很好。
我唯一想知道的是：我要签入什么，我要忽略什么以进行版本控制？很明显，我想检查 Podfile 本身，可能还有 .xcworkspace 文件；但是我会忽略 Pods/ 目录吗？是否还会生成其他文件（当我添加其他依赖项时）我也应该添加到我的 .gitignore 中？
【问题讨论】：
标签： objective-c git cocoapods
我通常在客户的应用程序上工作。在这种情况下，我还将 Pods 目录添加到 repo 中，以确保在任何给定时间任何开发人员都可以进行检查并构建和运行。
如果它是我们自己的应用程序，我可能会排除 Pods 目录，直到我暂时不处理它。
实际上，我必须得出结论，与纯粹用户的观点相比，我可能不是回答您问题的最佳人选：) 我将在 https://twitter.com/CocoaPodsOrg 上发布有关此问题的推文。
【讨论】：
我个人不会检查 Pods 目录和内容。我不能说我花了很长时间考虑这些影响，但我的推理是这样的：
Podfile 指的是每个依赖项的特定标记或提交，因此 Pod 本身可以从 podfile 生成，因此它们更像是中间构建产品而不是源，因此不需要版本控制我的项目。
【讨论】：
Podfile.lock：它被称为by Cocoapods，建议受版本控制。
我属于不签入库的开发人员阵营，假设我们在另一个位置有一个好的副本可用。因此，在我的 .gitignore 中，我包含以下特定于 CocoaPods 的行：
Pods/
#Podfile.lock # changed my mind on Podfile.lock
然后，我会确保我们在安全的位置拥有这些库的副本。我认为最好的方法是归档构建，而不是（错误地）使用项目的代码存储库来存储依赖项（编译或未编译）。如果您使用 CI 服务器进行构建（例如 Jenkins），您可以永久归档任何对您很重要的构建。如果您在本地 Xcode 中进行所有生产构建，请养成为您需要保留的任何构建的项目存档的习惯。就像是： 1. 产品 --> 存档
分发...提交到 iOS App Store / 保存以供企业或临时部署 / 你有什么
在 Finder 中显示您的项目文件夹
右键单击并压缩“WhateverProject”
这提供了整个项目的构建映像，包括用于构建应用程序的完整项目和工作区设置以及二进制发行版（如 Sparkle、TestFlight 等专有 SDK 等），无论它们是否使用 CocoaPods。
更新：我改变了主意，现在将Podfile.lock 提交给源代码管理。但是，我仍然认为 pod 本身是构建工件，应该在源代码控制之外通过另一种方法进行管理，例如 CI 服务器或我上面描述的存档过程。
【讨论】：
Podfile.lock:docs.cocoapods.org/guides/working_with_teams.html
Podfile.lock 包含本地 pod 的路径，因此我没有考虑将其添加到版本控制中。但是，现在想来，这与我在Podfile 中所做的本地更改没有什么不同，但从未提交。感谢您指出这一点。
Podfile.lock 文件。
我检查了一切。 （Pods/ 和 Podfile.lock。）
我希望能够克隆存储库，并且知道一切都会像我上次使用该应用程序时那样工作。
我宁愿供应商的东西，也不愿冒可能由不同版本的 gem 或有人在 Pod 的存储库中重写历史等导致的不同结果。
【讨论】：
我更喜欢将Pods 目录连同Podfile 和Podfile.lock 一起提交，以确保我团队中的任何人都可以随时查看源代码，而他们不必担心任何事情或做额外的事情来使其正常工作。
这也有助于您在其中一个 pod 中修复错误或根据需要修改某些行为但如果未提交这些更改将无法在其他计算机上使用。
并忽略不必要的目录：
xcuserdata/
【讨论】：
我建议使用GitHub’s Objective-C gitignore。 具体来说，最佳做法是：
Podfile必须始终处于源代码控制之下。Podfile.lock必须始终处于源代码控制之下。:path 选项引用的任何 Pod都应保持在源代码控制之下。./Pods 文件夹可以受源代码控制。更多信息可以参考official guide。
来源：我是 CocoaPods 核心团队的一员，和 @alloy 一样
虽然 Pods 文件夹是一个构建工件，但在决定是否将其置于源代码控制之下时，您可能会考虑以下原因：
:head 和 :git 选项当前未使用存储在 Podfile.lock 中的提交）。 【讨论】：
我提交了我的 Pods 目录。我不同意 Pods 目录是构建工件。事实上，我会说它绝对不是。它是您的应用程序源代码的一部分：没有它就无法构建！
将 CocoaPods 视为开发工具而不是构建工具更容易。它不会构建您的项目，它只是为您克隆和安装您的依赖项。不必安装 CocoaPods 就可以简单地构建您的项目。
通过使 CocoaPods 成为您构建的依赖项，您现在需要确保它在您构建项目所需的任何地方都可用...团队管理员需要它，您的 CI 服务器也需要它。通常，您应该始终能够克隆您的源存储库并进行构建，而无需任何进一步的努力。
如果您经常切换分支，不提交您的 Pods 目录也会让人头疼。现在你需要在每次切换分支时运行 pod install 以确保你的依赖是正确的。随着您的依赖关系稳定下来，这可能不会那么麻烦，但是在项目的早期，这是一个巨大的时间消耗。
那么，我忽略了什么？没有。 Podfile、锁文件和 Pods 目录都被提交。相信我，它会为你省去很多麻烦。有什么缺点？一个稍微大一点的回购？不是世界末日。
【讨论】：
Pods 目录会导致您痛苦，这确实是不公平的，因为签入它也会带来一系列问题。例如开发人员在 Podfile 中添加了一个依赖版本，却没有记住在 Pod 中检查更新的源代码。墨菲定律。 pod install 每次切换分支都会花费您宝贵的时间......几十秒 - 但它完全消除了这类问题。
It won't build without it! 你也可以提交 XCode
似乎将“Pods”目录作为一个 git 子模块/单独项目来构建它的好方法，这就是原因。
在与多个开发人员合作时，在您的项目 repo 中包含 pod 可能会导致拉取请求中出现非常大的差异，在这种情况下，几乎不可能看到人们更改的实际工作（想想数百到数千个文件已更改）对于库，在实际项目中只更改了一些）。
我看到了不向 git 提交任何内容的问题，因为拥有该库的人可以随时将其删除，而您本质上是 SOL，这也解决了这个问题。
【讨论】：
对我来说，最大的担忧是在未来验证您的来源。如果您打算让您的项目持续一段时间并且 CocoaPods 消失或其中一个 pod 的来源出现故障，那么如果尝试从存档中重新构建，那么您完全不走运。
这可以通过定期的完整源档案来缓解。
【讨论】：
我必须说，我非常喜欢将 Pod 提交到存储库。按照已经提到的链接，将为您提供一个很好的 .gitignore 文件，以启动您的 iOS 的 Xcode 项目，以允许 Pod，但如果您愿意，您也可以轻松地排除它们：https://github.com/github/gitignore/blob/master/Objective-C.gitignore
我之所以喜欢将 Pods 添加到存储库中的原因是一个似乎没有人接受的根本原因，如果我们的项目如此依赖的库突然从网络上删除会发生什么？
注意...请注意，用于开发的“主”分支仅用于示例，显然版本控制系统中的“主”分支应随时保持清洁和可部署/可构建 em>
我认为，从这些方面来看，您的代码存储库中的快照肯定比严格控制存储库大小要好。如前所述，podfile.lock 文件 - 虽然版本受控，但可以为您提供 Pod 版本的良好历史记录。
归根结底，如果您的截止日期紧迫，预算紧张，那么时间至关重要 - 我们需要尽可能地足智多谋，不要将时间浪费在严格的意识形态上，而是利用一套工具共同努力——让我们的生活更轻松、更高效。
【讨论】：
签入 Pod。
我认为这应该是软件开发的一个宗旨
为什么？
CocoaPods 或任何其他外部库可能会发生变化，这可能会破坏事情。或者它们可能会移动，或者被重命名，或者被完全删除。您不能依靠互联网为您存储东西。您的笔记本电脑可能已经死机，并且生产中存在需要修复的严重错误。主要开发人员可能会被公共汽车撞到，他的继任者必须匆忙启动。我希望最后一个是理论上的例子，但它实际上发生在我所在的一家初创公司。 RIP。
现在，实际上，您无法真正检查所有依赖项。您无法签入用于创建构建的机器的映像；您无法检查编译器的确切版本。等等。有现实的限制。但尽你所能检查 - 不这样做只会让你的生活更加艰难。我们不希望这样。
最后一句话：Pod 不是构建工件。构建工件是从您的构建中生成的。您的构建使用 Pod，而不是生成它们。我什至不确定为什么要对此进行辩论。
【讨论】：
是否签入 Pods 文件夹取决于您，因为工作流程因项目而异。我们建议您将 Pods 目录置于源代码控制之下，并且不要将其添加到您的 .gitignore 中。但最终这个决定取决于你：
签入 Pods 目录的好处
忽略 Pods 目录的好处
【讨论】：
最终取决于您采取的方法。
这是 Cocoapods 团队的想法：
是否签入 Pods 文件夹取决于您，因为 工作流程因项目而异。我们建议您保留 源代码控制下的 Pods 目录，不要将其添加到您的 .gitignore。但最终这个决定取决于你。
如果我使用 Node 或 bower_components，我个人希望将 Pods 排除在外，作为 node_modules如果我使用 Bower。这适用于几乎所有的依赖管理器，也是 git 子模块 背后的哲学。
然而，有时您可能想真正确定某个依赖项的state-of-art，这样您就可以在项目中拥有自己的依赖项。当然，如果你这样做会有一些缺点，但问题不仅适用于 Cocoapods，也适用于任何依赖管理器。
下面是 Cocoapods 团队制作的一个很好的优点/缺点列表，以及前面提到的报价全文。
Cocoapods team: Should I check the Pods directory into source control?
【讨论】：
没有答案实际上提供了.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.
【讨论】：
理论上，您应该检查 Pods 目录。在实践中，它并不总是有效。许多 pod 远远超出了 github 文件的大小限制，因此如果您使用 github，您将在检查 Pods 目录时遇到问题。
【讨论】：
在 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 install，并且不需要 Internet 连接。
- 即使 Pod 的源（例如 GitHub）出现故障，Pod 工件（代码/库）也始终可用。
- 在克隆 repo 后，Pod 工件保证与原始安装中的工件相同。
忽略 Pods 目录的好处
源代码管理存储库会更小，占用空间更少。
只要所有 Pod 的源（例如 GitHub）都可用，CocoaPods 通常能够重新创建相同的安装。 （从技术上讲，不能保证运行 pod install 会获取 并在不使用提交 SHA 时重新创建相同的工件 播客文件。在 Podfile 中使用 zip 文件时尤其如此。）
在执行源代码控制操作时不会有任何冲突需要处理，例如合并不同 Pod 的分支 版本。
无论您是否签入 Pods 目录、Podfile 和 Podfile.lock 应始终处于版本控制之下。
【讨论】：
这取决于个人：
pods.xcodeproj 设置也是源代码控制的一部分。这意味着例如如果您在 swift 4 中有项目，但某些 pod 必须在 swift 3.2 中，因为它们尚未更新，这些设置将被保存。否则克隆 repo 的人最终会出错。pod install，反之则不行。一些缺点：更大的存储库、令人困惑的差异（主要针对团队成员）、潜在的更多冲突。
【讨论】：
不将Pods/ 签入版本控制的优点（按主观重要性排序）：
pod install 可能会阻止更改。Podfile 和 Pods/ 目录之间的差异在队友中发现得更快。如果您签入Pods/ 并更新Podfile 中的版本，但忘记运行pod install 或签入对Pods/ 的更改，您将很难注意到源代码差异。如果Pods/ 未签入，则始终需要运行pod install。JAR 文件、.venv/（虚拟环境）和node_modules/ 永远不会包含在版本控制中。如果我们完全不知道这个问题，不签入Pods 将是基于先例的默认设置。不签入Pods/的缺点
pod install。pod install。pod install，并且 pod 的来源必须可用。总而言之，不包括Pods 目录是防止更多不良做法的护栏。 包括Pods 目录使项目的运行更加容易。我更喜欢前者而不是后者。如果一开始就不可能犯某些错误，那么您就不需要向项目中的每个新人汇报“不做什么”。我也喜欢为 Pods 提供单独版本控制的想法，以减轻缺点。
【讨论】：
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/ 文件夹时，项目更容易从中获取。当你不跟踪它时，它更容易改进。
【讨论】：