正確的使用pod install 和 pod update - CocoaPods

時間 2020-01-27

標籤正確使用 pod install update cocoapods 简体版

原文原文鏈接

pod install

在項目中第一次使用CocoaPods, 進行安裝的時候使用這個命令.
在Podfile中增長或刪除某個pod後, 也是使用這個命令. 而不是pod update.

每次運行pod install命令, 下載並安裝新的pod時, 它會爲Podfile.lock文件中的每一個pod寫入已安裝的版本. 此文件跟蹤每一個pod的已安裝版本並鎖定這些版本(.lock命名所以而來).
當運行pod install，它只解析Podfile.lock中還沒有列在其中的pod的依賴庫.html
- 對於已經在Podfile.lock中列出的pod, Podfile.lock不會嘗試檢查是否有更新的版本.
- 對於還沒有在Podfile.lock中列出的pod, 會搜索與Podfile（如中所述pod 'MyPod', '~>1.2'）匹配的版本或最新的版本.

注: 第一次運行pod install的時候, .xcworkspace項目和Pods目錄還不存在, pod install命令也會建立.xcworkspace和Pods目錄, 但這是pod install命令的順帶做用，而不是它的主要做用.git

pod outdated

當運行pod outdated時, CocoaPods將列出全部比Podfile.lock（每一個pod當前安裝的版本）中, 已經列出的版本更新的pod版本. 這意味着若是你在這些pod上運行pod update PODNAME, 它將會把指定的pod更新到最新版本.ide

pod update

當運行pod update PODNAME時, CocoaPods將嘗試查找PODNAME更新的pod版本, 會忽略掉Podfile.lock中已經存在的版本.函數

若是直接運行pod update, 沒有指定PODNAME, CocoaPods會把Podfile中全部的pod都更新到最新版本.(若是已是最新版本了, 則不更新)ui

預期用途

使用pod update PODNAME, 將只能更新特定的pod(檢查是否存在新版本並相應地更新pod). 相反, pod install不會嘗試更新已安裝的pod的版本.spa

當向Podfile中添加一個pod時, 應該運行pod install, 而不是用pod update來安裝這個新pod.版本控制

只有在想要更新特定pod（或全部的pod）的版本時纔會使用pod update.code

必須提交的Podfile.lock

有時候可能你不想提交Pods目錄到源代碼管理中. 可是在多人開發的狀況下, 必定要提交Podfile.lock這個文件, 由於這個文件裏面記錄了你的Podfile中全部pod的版本信息. 爲避免你的Podfile中的pod版本和別人的Podfile中的pod發生版本不同的狀況, 而致使出現函數找不到或者其餘的錯誤.htm

場景示例

user1建立了項目

user1建立了一個項目, 而且想用A, B, C這3個pod庫, 這個時候用pod install安裝了這些pod庫, 而且假設這3個庫的版本號都是1.0.0, 這些版本號等信息會記錄在Podfile.lock文件中.ip

user1添加了新的pod

根據項目的進度需求, 添加了D這個pod庫到項目中, 這個時候應該使用pod install去安裝D這個庫到項目中, 即便在添加D這個庫以前, B的版本被維護者更新到了1.1.0, 使用pod install也只會安裝D這個庫到項目中, 而不會去幫你更新B的版本. 從而不會出現由於B的版本更新後, 假如某些函數過時了, 或者某些函數被移除了, 而致使你被迫須要修改項目代碼.

user2加入到項目中

假設團隊中新增長了一位基友user2, 他克隆了項目, 而且pod install. (前提是你沒有把Pods目錄添加到源代碼管理中), 若是你將Podfile.lock提交到了版本控制. 那麼基友安裝後的pod會和你的如出一轍, 不會出現他的pod版本比你的高. 即使如今C的版本更新到了1.2.0, 基友安裝的也是1.0.0版本. 由於在Podfile.lock中記錄的pod C就是1.0.0版本.

檢查pod的新版本

後來, user1想要檢查下是否有更新pod的版本. 運行pod outdated, 會告訴你pod B有一個新1.1.0版本, pod C已是1.2.0版本. user1決定他想要更新pod B, 但不更新pod C. 所以, 他會運行pod update B, 將B從1.0.0版本更新到版本1.1.0（並相應的更新Podfile.lock）, 但會將pod C保留在版本中1.0.0(不會將其更新爲1.2.0).

使用指定版本的Podfile是不夠的

有些人可能會認爲, 經過在Podfile中指定pod確切的版本, 像pod 'A', '1.0.0', 就足以保證每個人和其餘人都會有相同的版本. 而後他們甚至可使用pod update, 即便只是添加一個新的pod, 認爲它永遠不會有更新其餘pod版本的風險, 由於它們在Podfile中被固定到了一個特定的版本.

但事實上, 這還不足以保證咱們上面場景中的user1和user2, 始終得到全部pod的徹底相同的版本. 舉一個典型的例子, 若是pod A中有對pod A2的依賴, 在A.podspecas中聲明dependency 'A2', '~> 3.0'. 在這種狀況下，pod 'A', '1.0.0'在你的Podfile中使用的時候, 確實會強制user1和user2始終使用A 1.0.0 的pod版本.

可是: user1最終可能獲取到的A2版本是pod 3.4(由於那時A2是最新版本), 當user2在之後加入項目時運行pod install, 他可能會在A2的版本中得到pod 3.5(由於維護者A2可能在此期間發佈了新版本).

這就是爲何爲了確保在每一個團隊成員使用的每臺電腦上, 全部相同的pod版本的惟一方法, 是使用Podfile.lock和正確使用pod install和pod update的緣由.

我應該將Pods目錄添加到源代碼管理中嗎？

是否將Pods文件夾添加到源代碼管理中都取決於你，由於工做流程因項目而異. 咱們建議您將Pods目錄保留在源代碼管理下, 不要將其添加到您的.gitignore. 但最終這個決定取決於你:

添加Pod目錄的好處

克隆了repo後, 即便沒有在機器上安裝CocoaPods, 項目也能夠當即構建和運行. 無需運行pod install, 也無需Internet鏈接.
Pod（代碼/庫）老是可用的, 即便Pod的源（例如GitHub）要關閉也是如此.
在克隆repo後, Pod組件保證與原始安裝中的組件相同.

忽略Pods目錄的好處

源代碼倉庫將更小, 而且佔用更少的空間.
只要全部Pod的源（例如GitHub）均可用, CocoaPods一般可以從新建立相同的安裝.（從技術上講, 沒法保證pod install在Podfile中不使用提交SHA時, 運行將獲取並從新建立相同的組件. 在Podfile中使用zip文件時尤爲如此.）
執行源控制操做時不會有任何衝突, 例如合併具備不一樣Pod版本的分支.

不管你是否在忽略Pods目錄, Podfile並Podfile.lock應始終版本控制下保持.