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

Question

我已经进行了几个月的iOS开发,并且刚刚学习了有用的依赖管理CocoaPods库.

我在个人项目上试了一下:在我的Podfile中添加了对Kiwi的依赖,运行pod install CocoaPodsTest.xcodeproj,瞧,它运行得很好.

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

Answer 1

我提交了我的Pods目录.我不同意Pods目录是一个构建工件.事实上,我肯定会说它绝对不是.它是应用程序源代码的一部分:如果没有它,它将无法构建!

将CocoaPods视为开发人员工具而不是构建工具更容易.它不构建您的项目,它只是克隆并为您安装依赖项.没有必要安装CocoaPods才能简单地构建您的项目.

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

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

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

Answer 2

我个人不检查Pods目录和内容.我不能说我花了很长时间考虑其影响,但我的推理是这样的:

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

Answer 3

我建议使用GitHub的Objective-C gitignore.详细而言,最佳做法是:

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

有关更多信息,请参阅官方指南.

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

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

• CocoaPods不是包管理器,因此作者将来可以删除库的原始源.
• 如果Pods文件夹包含在源代码管理中,则无需安装CocoaPods来运行项目,因为结帐就足够了.
• CocoaPods仍在进行中,并且有些选项并不总是导致相同的结果(例如,当前:head的:git选项和选项都不使用存储在其中的提交Podfile.lock).
• 如果您可以在中/长时间后恢复项目工作,则可以减少故障点.

Answer 4

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

Answer 5

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

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

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

Answer 6

对此的答案直接在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通常能够重新创建相同的安装.(从技术上讲,无法保证在Podfile中不使用提交SHA时,运行pod安装将获取并重新创建相同的工件.在Podfile中使用zip文件时尤其如此.)

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

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

Answer 7

我检查一切.(Pods/和Podfile.lock.)

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

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

Answer 8

假设我们在另一个地方有一份好的副本,那我就是那些没有登记图书馆的开发人员.所以,在我的.gitignore中,我包含了以下特定于CocoaPods的行:

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

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

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项目以允许Pods,但如果您愿意,也可以轻松排除它们:https://github.com/github/gitignore/斑点/主/目标-C.gitignore

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

• 也许主持人决定他们不再希望保持他们的GitHub帐户开放如果图书馆说几年之后会发生什么(例如,比例超过5年),项目可能无法再从源头获得
• 还有一点,如果存储库的URL发生变化会发生什么？让我们说,从他们的GitHub帐户服务Pod的人,决定用不同的句柄代表自己 - 你的Pods URL将会破坏.
• 最后另一点.假如你是一个像我这样的开发人员,在国家之间的航班上进行大量编码.我快速拉开'主'分支,在那个分支上做一个pod安装,同时坐在机场,让我自己为即将到来的8小时飞行做好准备.我进入飞行3小时,意识到我需要切换到另一个分支....'DOH' - 缺少Pod信息,这些信息只能在'master'分支上找到.

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

我认为,从这些中,代码存储库中的快照肯定比对存储库大小严格要好.正如已经提到的,podfile.lock文件 - 在受版本控制的情况下,可以为您提供Pod版本的良好历史记录.

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

Answer 11

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

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

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

就个人而言,如果我使用Bower,我想将Pods保留为node_modules,如果我使用的是Node或bower_components.这适用于几乎所有的Dependency Manager,并且是git子模块背后的哲学.

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

下面是Cocoapods团队制作的优秀利弊名单,以及之前提到的报价全文.

Cocoapods团队:我应该将Pods目录检查为源代码管理吗？

Answer 12

这取决于个人:

为什么pod应该是repo的一部分(在源代码管理下),不应该被忽略

• 来源是相同的
• 您可以立即构建它(即使没有cocoapods)
• 即使删除了一个pod,我们仍然会有它的副本(是的,这可能会发生并且确实如此.在一个旧项目中,您只需要进行一些小改动就需要实现一个新的库才能构建).
• pods.xcodeproj设置也是源控件的一部分.这意味着,例如,如果您有项目swift 4,但某些pod必须在,swift 3.2因为它们尚未更新,这些设置将被保存.否则克隆回购的人最终会出错.
• 您可以随时从项目中删除pod并运行pod install,但相反则无法完成.
• 即使是Cocoapods 的作者也推荐它.

一些缺点:更大的存储库,混乱的差异(主要是团队成员),可能更多的冲突.

Answer 13

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

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

不办理登机手续的缺点Pods/

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

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