423

我已经做了几个月的 iOS 开发，并且刚刚了解到用于依赖管理的有前途的CocoaPods库。

我在一个个人项目上进行了尝试：将Kiwi的依赖项添加到我的 Podfile 中，运行pod install CocoaPodsTest.xcodeproj，然后瞧，效果很好。

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

4

19 回答 19

421

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

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

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

如果您经常切换分支，不提交您的 Pods 目录也会让人头疼。现在你需要在每次切换分支时运行 pod install 以确保你的依赖是正确的。随着您的依赖关系稳定下来，这可能不会那么麻烦，但是在项目的早期，这是一个巨大的时间消耗。

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

于 2014-03-12T11:25:44.417 回答
289

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

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

于 2012-02-26T16:34:20.737 回答
163

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

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

更多信息可以参考官方指南。

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

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

  • CocoaPods 不是包管理器，因此作者将来可能会删除该库的原始源代码。
  • 如果 Pods 文件夹包含在源代码管理中，则无需安装 CocoaPods 即可运行项目，因为签出就足够了。
  • CocoaPods 仍在进行中，并且有些选项并不总是导致相同的结果（例如:head和:git选项当前不使用存储在 中的提交Podfile.lock）。
  • 如果您可以在中/长时间后恢复项目工作，那么故障点就会减少。
于 2014-03-11T10:59:33.530 回答
58

.gitignore 文件

实际上没有答案提供 a .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 讨论在这里。

于 2016-01-28T15:22:15.440 回答
38

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

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

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

于 2012-02-26T16:24:49.150 回答
19

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

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

我宁愿供应商的东西，也不愿冒可能由不同版本的 gem 或有人在 Pod 的存储库中重写历史等导致的不同结果。

于 2013-11-20T16:50:10.597 回答
18

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 工件（代码/库）始终可用，即使 Pod 的源（例如 GitHub）出现故障。
  • 克隆 repo 后，Pod 工件保证与原始安装中的工件相同。

忽略 Pods 目录的好处

  • 源代码控制 repo 会更小，占用更少的空间。

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

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

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

于 2016-08-25T10:03:59.087 回答
13

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

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

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

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

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

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

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

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

于 2013-09-25T20:33:54.723 回答
11

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

这也有助于您在其中一个 pod 中修复错误或根据需要修改某些行为但如果未提交这些更改将在其他机器上不可用的情况。

并忽略不必要的目录：

xcuserdata/
于 2013-12-15T10:53:59.143 回答
10

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

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

  • 也许主机决定他们不再想保持他们的 GitHub 帐户保持开放 如果库已经使用几年（例如超过 5 年）会发生什么情况 项目可能不再从源代码可用的高风险
  • 还有一点，如果存储库的 URL 发生变化会发生什么？假设从他们的 GitHub 帐户服务 Pod 的人决定用不同的句柄来代表自己——你的 Pod URL 将被破坏。
  • 最后还有一点。假设您是像我这样的开发人员，在国家之间的航班上进行大量编码。我在“master”分支上快速拉动，在该分支上安装 pod，同时坐在机场，为即将到来的 8 小时飞行做好准备。我在飞行 3 小时后意识到我需要切换到另一个分支......“DOH” - 缺少仅在“主”分支上可用的 Pod 信息。

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

我认为从这些方面来看，代码存储库中的快照肯定比严格存储库大小要好。正如已经提到的， podfile.lock 文件 - 虽然版本受控，但可以为您提供 Pod 版本的良好历史记录。

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

于 2014-11-20T14:33:45.080 回答
9

这取决于个人：

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

  • 来源是一样的
  • 您可以按原样立即构建它（即使没有 cocoapods）
  • 即使一个 pod 被删除，我们仍然有它的副本（是的，这可能发生并且确实发生了。在一个旧项目中，您只需要一个小改动，您需要实现一个新库才能构建）。
  • pods.xcodeproj设置也是源代码控制的一部分。这意味着，例如，如果您有项目swift 4，但某些 pod 必须在其中，swift 3.2因为它们尚未更新，这些设置将被保存。否则，克隆 repo 的人最终会出错。
  • 您始终可以从项目中删除 pod 并运行pod install，反之则不行。
  • 甚至Cocoapods的作者也推荐它。

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

于 2017-09-21T11:41:37.400 回答
8

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

这是 Cocoapods 团队的想法：

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

就我个人而言，我希望将Pods排除在外，如果我使用的是Node_modules，则如果我使用的是Bower，则为bower_components。这适用于几乎所有的依赖管理器，也是git 子模块背后的理念。

但是，有时您可能希望真正确定某个依赖项的最新技术，这样您就可以在项目中拥有自己的依赖项。当然，如果你这样做，会有一些缺点，但问题不仅适用于 Cocoapods，也适用于任何依赖管理器。

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

Cocoapods 团队：我应该将 Pods 目录检查到源代码管理中吗？

于 2015-08-13T16:14:21.497 回答
6

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

  1. 合并提交和查看代码差异要容易得多。合并是代码库中问题的常见来源，这使您可以只关注相关的事情。
  2. 一些随机贡献者不可能自己编辑依赖项并检查更改，这是他们永远不应该做的（如果差异很大，也很难识别）。编辑依赖项是非常糟糕的做法，因为未来pod install可能会遮挡更改。
  3. 在队友之间更快地发现目录Podfile和目录之间的差异。例如，Pods/如果您签入并更新 中的版本，但忘记运行或签入对 的更改，您将很难注意到差异的来源。如果未签入，则始终需要运行。Pods/Podfilepod installPods/Pods/pod install
  4. 较小的回购规模。有一个较小的字节足迹很好，但这在宏伟的计划中并不重要。更重要的是：在 repo 中有更多的东西也会增加你的认知负担。没有理由在回购中包含您不应该查看的内容。请参阅文档（抽象）以了解某些东西是如何工作的，而不是代码（实现）。
  5. 更容易辨别某人贡献了多少（因为他们贡献的代码行不包括他们没有编写的依赖项）
  6. JAR文件，.venv/（虚拟环境），并且node_modules/从不包含在版本控制中。如果我们完全不知道这个问题，那么根据先例，不签到将是默认设置。Pods

不检查的缺点Pods/

  1. 您必须pod install在切换分支或恢复提交时运行。
  2. 您不能仅通过克隆存储库来运行项目。您必须安装 pod 工具，然后运行pod install​​.
  3. 您必须有 Internet 连接才能运行pod install，并且 pod 的来源必须可用。
  4. 如果依赖项的所有者删除了他们的包，您将无法使用它（尽管您不应该首先使用已弃用的依赖项 - 这只会迫使您更早地进行依赖项卫生）。

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

于 2018-11-30T21:03:59.970 回答
3

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

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

于 2014-08-21T04:39:50.103 回答
2

检查 Pod。

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

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

为什么？

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

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

最后一句话：Pod 不是构建工件。构建工件是从您的构建中生成的。您的构建使用 Pod，而不是生成它们。我什至不确定为什么要对此进行辩论。

于 2015-06-26T01:39:16.987 回答
2

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/文件夹时，项目更容易从中获取。当你不跟踪它时，它更容易改进。

于 2019-09-13T01:39:36.977 回答
1

理论上，您应该检查 Pods 目录。在实践中，它并不总是有效。许多 pod 远远超出了 github 文件的大小限制，因此如果您使用 github，您将在检查 Pods 目录时遇到问题。

于 2016-06-28T05:54:44.177 回答
0

似乎一个很好的方式来构建它真的是将“Pods”目录作为一个 git 子模块/单独的项目，这就是原因。

  • 在与多个开发人员一起工作时，在您的项目 repo 中拥有 pod 可能会导致拉取请求中的非常大的差异，几乎不可能看到人们更改的实际工作（想想为库更改了数百到数千个文件，并且只有一个在实际项目中几乎没有变化）。

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

于 2014-07-16T21:13:11.830 回答
0

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

签入 Pods 目录的好处

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

忽略 Pods 目录的好处

  1. 源代码控制 repo 会更小，占用更少的空间。只要所有 Pod 的源（例如 GitHub）都可用，CocoaPods 通常能够重新创建相同的安装。（从技术上讲，当不使用 Podfile 中的提交 SHA 时，不能保证运行 pod install 会获取并重新创建相同的工件. 在 Podfile 中使用 zip 文件时尤其如此。）
  2. 执行源代码控制操作时不会有任何冲突需要处理，例如合并具有不同 Pod 版本的分支。无论您是否签入 Pods 目录，Podfile 和 Podfile.lock 都应始终处于版本控制之下。
于 2015-07-23T09:35:11.103 回答