2013年就開始使用Cocoapods來使用第三方套件，儘管有發佈初學者的Cocoapods教學，可是在「管理」這方面卻還是有些不明白，像是pod install與pod update的差別，真的是要到需要的時候才會認真去釐清差異，過去一直install和update混著用，如今看官方說明就更明白，畢竟我今年開始是團隊合作寫iOS App囉！
文章開頭先說總結：團隊每人都要同步podfile.lock，如此能保證大家套件版本一致。
過去我以為只要Podfile指定好版本後就萬無一失，當時我獨自一人開發顯然不會有問題。然而遇到團隊如果要加入新人，只有Podfile無法保證下指令pod install後會跟資深同事版本一致，必須再參照記錄在podfile.lock中的套件，接著下指令pod install，才能保證版本一致。
現再來取用官方說明，能清楚了解兩者的差異！
pod install ：
這個是第一次在工程裡面使用pods的時候使用，並且，也是每次你編輯你的Podfile（添加、移除、更新）的時候使用。
每次運行pod install命令的時候，在下載、安裝新的庫的同時，也會把你安裝的每個庫的版本都寫在了Podfile.lock文件裡面。這個文件記錄你每個安裝庫的版本號，並且鎖定了這些版本。
當你使用pod install它只解決了pods裡面，但不在Podfile.lock文件裡面的那些庫之間的依賴。對於在Podfile.lock裡面所列出的那些庫，會下載在Podfile.lock裡面明確的版本，並不會去檢查是否該庫有新的版本。對於還不在Podfile.lock裡面的庫，會找到Podfile裡面描述對應版本（例如：pod “MyPod", “~>1.2″）。
如圖，我在Podfile中移除一個RNCachingURLProtocol的套件。
pod update：
當你運行pod update PODNAME 命令時，CocoaPods會幫你更新到這個庫的新版本，而不需要考慮Podfile.lock裡面的限制，它會更新到這個庫盡可能的新版本，只要符合Podfile裡面的版本限制。
如果你運行pod update，後面沒有跟庫的名字，CocoaPods就會更新每一個Podfile裡面的庫到盡可能的最新版本。
另外來看一下一個有趣的指令～
pod outdated：
當你運行pod outdated命令，CocoaPods會列出那些所有較Podfile.lock裡面有新版本的庫（那些當前被安裝著的庫的版本）。這個意思就是，如果你運行pod update PODNAME，如果這個庫有新的版本，並且新版本仍然符合在Podfile裡的限制，它就會被更新。
來看看我install和update後podfile.lock的差異：
update
install
其他場景可以參考官方舉例的說明⋯⋯
場景1：User1創建了一個工程
User1創建了一個工程，並且想使用A、B、C這三個庫，所以他就創建了一個含有這個三個庫的Podfile，並且運行了pod intall。
這樣就會安裝了A、B、C三個庫到這個工程裡面，假設我們的版本都為1.0.0。
因此Podfile.lock跟踪並記錄A、B、C這三個庫以及版本號1.0.0。
順便說一下：由於這個工程是第一次運行pod install，並且Pods.xcodeproj工程文件還不存在，所以這個命令也會同時創建Pods.xcodeproj以及.xcworkspace工程文件，這只是這個命令的一個副作用，並不是主要目的。
場景2：User1添加了一個庫
之後，User1添加了一個庫D到Podfile文件中。
然後他就應該運行pod install命令了。所以即使庫B的開發者發布了B的一個新版本1.1.0。但只要是在第一次執行pod install之後發布的，那麼B的版本仍然是1.0.0。因為User1只是希望添加一個新庫D，不希望更新庫B。
這就是很多人容易出錯的地方，因為他們在這裡使用了pod update，因為想著“更新我的工程一個新的庫而已”。這裡要注意！
場景3：User2加入到這個工程中
然後，User2，一個之前沒有參與到這個工程的人，加入了。他clone了一份倉庫，然後使用pod install命令。
Podfile.lock的內容就會保證User1和User2會得到完全一樣的pods，前提是Podfile.lock被提交到git倉庫中。
即使庫C的版本已經更新到了1.2.0，User2仍然會使用C的1.0.0版本，因為C已經在Podfile.lock裡面註冊過了，C的1.0.0版本已經被Podfile.lock鎖住了。
場景4：檢查某個庫的新版本
之後，User1想檢查pods裡面是否有可用的更新時，他執行了pod outdated，這個命令執行後，會列出來：B有了1.1.0版本，C有了1.2.0版本。
這時候，User1打算更新庫B，但不更新庫C，所以執行pod update B，這樣就把B從1.0.0更新到1.1.0（同時更新Podfile.lock裡面對B的版本記錄），此時，C仍然是1.0.0版本，不會更新。
在Podfile中使用明確版本還不夠
有些人認為在Podfile中明確某個庫的版本，例如：pod ‘A’, ‘1.0.0’ ,足以保證所有項目裡面的人都會使用完全一樣的版本。
這個時候，他們可能會覺得，此時如果添加一個新庫的時候，我使用pod update並不會去更新其它的庫，因為其它的庫已經被限定了固定的版本號。
但事實上，這不足以保證User1和User2的pods中庫的版本會完全一樣。
一個典型的例子是，如果庫A有一個對庫A2的依賴（聲明在A.podspec中：dependency ‘A2’, ‘~> 3.0’），如果這樣的話，使用pod ‘A’, ‘1.0.0 ‘ 在你的Podfile中，的確會讓User1和User2都使用同樣版本的庫A（1.0.0），然而：
最後User1可能使用A的依賴庫A2的版本為3.4（因為3.4是當時User1使用的最新版本），但User2使用的庫A2版本是3.5（假設A2的開發者剛剛發布了A2的新版本3.5）。
所以只有一個方法來保證某項目的每個開發者都使用相同版本的庫，就是每個電腦中都使用同樣的Podfile.lock，並且合理使用pod install 和pod update。
關於Podfile.lock
當你執行pod install之後，除了 Podfile 外，CocoaPods 還會生成一個名為Podfile.lock的文件，Podfile.lock 應該加入到版本控制裡面，不應該把這個文件加入到.gitignore中。因為Podfile.lock會鎖定當前各依賴庫的版本，之後如果多次執行pod install 不會更改版本，要pod update才會改Podfile.lock了。這樣多人協作的時候，可以防止第三方庫升級時造成大家各自的第三方庫版本不一致。
CocoaPods 官方文檔也在What is a Podfile.lock一節中介紹了Podfile.lock的作用，並且指出：
This file should always be kept under version control.
了然於心後，團隊合作就不用踩坑囉！話說比我早進公司的同事，當時就是pod update，讓專案起始開發同事搞了一陣子才排除問題ＸＤ～
參考：使用pod install還是pod update？、pod install vs. pod update、用CocoaPods做iOS程序的依賴管理。
逍遙文工作室 
Comments on: "[iOS] pod install與pod update的差別" (1)
[…] [iOS] pod install與pod update的差別 […]
讚Liked by 1 person