原文地址: 點選直達
pod install
- 在專案中第一次使用CocoaPods, 進行安裝的時候使用這個命令.
- 在
Podfile中增加或刪除某個pod後, 也是使用這個命令. 而不是pod update.
- 每次執行
pod install命令, 下載並安裝新的pod時, 它會為Podfile.lock檔案中的每個pod寫入已安裝的版本. 此檔案跟蹤每個pod的已安裝版本並鎖定這些版本(.lock命名因此而來). - 當執行
pod install，它只解析Podfile.lock中尚未列在其中的pod的依賴庫. - 對於已經在
Podfile.lock中列出的pod,Podfile.lock不會嘗試檢查是否有更新的版本. - 對於尚未在
Podfile.lock中列出的pod, 會搜尋與Podfile（如中所述pod 'MyPod', '~>1.2'）匹配的版本或最新的版本.
注: 第一次執行pod install的時候, .xcworkspace專案和Pods目錄還不存在, pod install命令也會建立.xcworkspace和Pods目錄, 但這是pod install命令的順帶作用，而不是它的主要作用.
pod outdated
當執行pod outdated時, CocoaPods將列出所有比Podfile.lock（每個pod當前安裝的版本）中, 已經列出的版本更新的pod版本. 這意味著如果你在這些pod上執行pod update PODNAME, 它將會把指定的pod更新到最新版本.
pod update
當執行pod update PODNAME時, CocoaPods將嘗試查詢PODNAME更新的pod版本, 會忽略掉Podfile.lock中已經存在的版本.
如果直接執行pod update, 沒有指定PODNAME, CocoaPods會把Podfile中所有的pod都更新到最新版本.(如果已經是最新版本了, 則不更新)
預期用途
使用pod update PODNAME, 將只能更新特定的pod(檢查是否存在新版本並相應地更新pod). 相反, pod install不會嘗試更新已安裝的pod的版本.
當向Podfile中新增一個pod時, 應該執行pod install, 而不是用pod update來安裝這個新pod.
只有在想要更新特定pod（或所有的pod）的版本時才會使用pod update.
必須提交的Podfile.lock
有時候可能你不想提交Pods目錄到原始碼管理中. 但是在多人開發的情況下, 一定要提交Podfile.lock這個檔案, 因為這個檔案裡面記錄了你的Podfile中所有pod的版本資訊. 為避免你的Podfile中的pod版本和別人的Podfile中的pod發生版本不一樣的情況, 而導致出現函式找不到或者其他的錯誤.
場景示例
- user1建立了專案
user1建立了一個專案, 並且想用A, B, C這3個pod庫, 這個時候用pod install安裝了這些pod庫, 並且假設這3個庫的版本號都是1.0.0, 這些版本號等資訊會記錄在Podfile.lock檔案中.
- 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應始終版本控制下保持.
本文內容來源: guides.cocoapods.org/using/pod-i… guides.cocoapods.org/using/using…