提问



我已经进行了几个月的iOS开发,并且刚刚了解了有前途的CocoaPods库,用于依赖管理。[26]


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


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

最佳参考


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


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

其它参考1


我提交了我的Pods目录。我不同意Pods目录是一个构建工具。实际上我说它绝对不是。它是你的应用程序源的一部分:它没有它的构建!


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


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


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


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

其它参考2


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



  • Podfile 必须始终受源代码管理。

  • Podfile.lock 必须始终受源代码管理。

  • CocoaPods生成的工作区保持在源代码管理之下。

  • :path选项引用的任何Pod应保持在源代码管理下。

  • ./Pods文件夹可以保持在源代码管理下。



有关更多信息,请参阅官方指南。[29]


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





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



  • CocoaPods不是包管理器,因此作者将来可以删除该库的原始来源。

  • 如果Pods文件夹包含在源代码管理中,则无需安装CocoaPods来运行项目,因为结帐就足够了。

  • CocoaPods仍在进行中,有些选项并不总能导致相同的结果(例如:head:git选项当前未使用:git中存储的提交Podfile.lock)。

  • 如果您可以在中等/很长时间后恢复项目工作,则可以减少失败的程度。


其它参考3


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


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


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

其它参考4


.gitignore文件



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





签入Pods目录(好处)[31]


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目录(好处)[32]


.gitignore: (附加到上一个列表)


# Cocoapods
Pods/



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



如果Pods未签入,则Podfile应该为每个Cocoapod请求显式版本号。 Cocoapods.org在这里讨论。[33]

其它参考5


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


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


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

其它参考6


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



  无论您是否签入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应始终保持在版本控制之下。


其它参考7


假设我们在另一个地方有一个很好的副本,我就是在没有检查库的开发人员的阵营中。所以,在我的.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服务器或我上面描述的存档过程。

其它参考8


我更喜欢提交Pods目录以及PodfilePodfile.lock以确保我的团队中的任何人都可以随时查看来源,他们不必担心任何事情或做其他事情来制作这行得通。


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


并忽略不必要的目录:


xcuserdata/

其它参考9


我必须说,我是将Pods提交到存储库的粉丝。根据已经提到的链接,将为您提供一个良好的.gitignore文件来启动iOS的Xcode项目以允许Pods,但如果您愿意,也可以轻松排除它们:https://github.com/github/gitignore/斑点/主/目标-C.gitignore [35]


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



  • 也许主持人决定他们不再想保留他们的GitHub
    帐户开放如果图书馆说几年之后会发生什么
    (比如年龄超过5年)存在高风险
    项目可能不再在源头提供

  • 另外一点,如果存储库的URL会发生什么
    变化?让我们说从他们的GitHub服务Pod的人
    帐户,决定在不同的句柄下代表自己 -
    您的Pods URL将会中断。

  • 最后另一点。假如你是一个像我这样做很多的开发人员
    在国家之间的航班上编码。我快点拉
    主分支,坐在那个分支上做一个pod安装
    在机场,我自己都准备了即将到来的8小时
    飞行。我进入飞行3个小时,意识到我需要切换到
    另一个分支....DOH - 缺少只在主分支上可用的Pod信息。



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


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


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

其它参考10


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


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



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



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


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


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


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

其它参考11


这取决于个人:


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




  • 来源相同

  • 您可以像一样立即构建它(即使没有cocoapods)

  • 即使删除了一个pod,我们仍然会有它的副本(是的,这可能会发生,而且确实如此。在一个只需要进行少量更改的旧项目中,您需要实现一个新库才能够甚至建立。)

  • pods.xcodeproj设置也是源控件的一部分。这意味着例如如果您在swift 4中有项目,但某些pod必须在swift 3.2中,因为它们尚未更新,这些设置将被保存。否则克隆回购的人最终会出错。

  • 您可以随时从项目中删除pod并运行pod install,但相反的方法无法完成。

  • 即使Cocoapods的作者也推荐它。



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

其它参考12


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


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

其它参考13


检查豆荚。


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



  • 所有版本必须可重现

  • 确保构建的唯一方法是
    可重复的是控制所有依赖关系;检查所有
    因此,依赖是必须的。

  • 从头开始的新开发人员应该能够检查您的项目并开始工作。



为什么?


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


现在,实际上,你不能真正检查所有依赖关系。你不能检查你用来创建构建的机器的图像;你不能检查编译器的确切版本。等等。有现实的限制。但是尽可能检查 - 不这样做只会让你的生活变得更难。而且我们不想要那样。


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

其它参考14


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



  • 在项目仓库中使用pod时,与多个开发人员合作时,可能会在拉取请求中造成非常大的差异,因为几乎不可能看到人们改变的实际工作(想想几百到几千个文件被更改为库,只有少数在实际项目中发生了变化)。

  • 我看到了不对git做任何事情的问题,因为拥有该库的人可以随时将其删除而你基本上是SOL,这也解决了这个问题。


其它参考15


无论您是否签入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应始终保持在版本控制之下。


其它参考16


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