原文鏈接：pod install vs. pod update
介紹
很多人以爲 ‘pod install’只是在初次創建項目的時候使用，而對已存在cocoapods的項目則使用命令pod update，但事實並非如此。
這篇文檔將解釋何時使用 pod install， 何時使用 pod update。
使用 pod install 爲項目添加新的類庫（pods），即使項目中已經存在 Podfile或者已經使用過 pod install 命令。當你需要爲項目添加或者移除第三方庫的時候，均使用 pod install。
只有在需要更新第三方庫版本的時候，才使用 pod update ［PODNAME］
命令詳解
注意：文中 install 和 update 的釋義並非僅在 CocoaPads 中適用，在其他依賴管理工具中（bundler， RubyGems，composer）中同樣適用，這兩條命令在各個工具中具有同樣的行爲和意圖。
pod install
當第一次爲項目導入第三方庫的時候使用此命令，同時，以後每次編輯Podfile爲項目添加、刪除、更新類庫的時候，均使用此命令。
每次執行此命令，會下載並安裝新的類庫，同時將每個類庫的名稱和版本記錄在 Podfile。lock 文件中， Podfile.lock 中保存已安裝類庫的版本，同時鎖定它們的版本。
當你使用 pod install 命令時，它只會解決 Podfile.lock 中尚未列出的類庫的依賴性。
對於Podfile.lock中已列出的類庫，他會下載Podfile.lock中對應版本的類庫，不會檢查是否有可用的新版本。
對於Podfile.lock中尚未列出的，他會下載Podfile文件中描述的版本（例：pod ‘MyPod’, ‘~>1.2’）
pod outdated
當你使用 pod outdated命令， CocoaPods 將會列出Podfile.lock中的有可用更新的類庫（相比於當前安裝的類庫版本）。這意味着只要新版本符合Podfile中設置的格式（pod ‘MyPod’,’~>x.y’）,就可以使用 pod update PODNAME 命令來更新這些類。
pod update
當你使用 pod update PODNAME，CocoaPods 將會查找 PODNAME 類的最新版本，此時不會考慮 Podfile.lock 中記錄的版本。如果存在於Podfile中對應的新版本，就會將此類庫更新到最新版本。
如果未指明PODNAME而直接使用 pod update 命令，CocoaPods將會更新 Podfile中所有類庫。
Intended usage
使用 pod update PODNAME，將會更新指定的類庫（如果存在新版本則更新）。相反， pod install 並不會更新已安裝的類庫。
當你在Podfile中添加了新的類庫時，應當使用 pod install 而不是 pod update，pod update在添加新的類庫的同時，也可能更新其他類庫。
只有需要更新指定類庫（或所有類庫）時，才能使用 pod update。
Commit your Podfile
請注意，雖然你不回commit Pods文件夾，但需要commit & push Podfile.lock文件。
Otherwise, it would break the whole logic explained above about pod install being able to lock the installed versions of your pods.
Podfile.lock：當你執行 pod install 之後，除了 Podfile 外，CocoaPods 還會生成一個名爲 Podfile.lock 的文件, Podfile.lock 應該加入到版本控制裏面，不應該把這個文件加入到 .gitignore 中。因爲 Podfile.lock 會鎖定當前各依賴庫的版本，之後如果多次執行 pod install 不會更改版本，要 pod update 纔會改 Podfile.lock 了。這樣多人協作的時候，可以防止第三方庫升級時造成大家各自的第三方庫版本不一致。
使用場景案例
此節爲模擬使用場景，將說明整個項目週期可能遇到的各種情況。
場景1: 程序員甲創建了項目
甲創建了項目文件並需要向項目中導入A, B, C三個類庫。 他根據類庫創建了Podfile文件，然後執行 pod install。
就這樣安裝了A,B,C三個類庫，同時它們的版本都爲1.0.0 。同時 Podfile.lock 文件中記錄下了它們的版本信息。
順便提一下：因爲這是他們第一次運行 pod install命令，而且還沒有 Pods.xcodeproj 項目文件。這條命令同時會創建Pods.xcodeproj 和 .xcworkspace， 雖然這也是pod install 的附帶效果，但並不是主角。
場景2:甲添加了一個新的庫
沒過多久，甲想將類庫D添加到Podfile中。
那麼此時他們在修改Podfile之後需要使用pod install 命令，這樣即使類庫B的維護者發佈了1.1.0的新版本，甲仍能保證項目中B是1.0.0版——因爲甲只想添加類庫D，並不想意外的更新某個類庫。
很多人在這個場景犯錯，他們經常使用 pod update命令——大概在想“我需要用update來更新我的項目吧”。正確的選擇應該使用pod install 來安裝新的類庫。
場景3:程序員乙加入到項目中
程序員乙剛剛加入到這個項目中，他clone repository 之後使用pod install安裝第三發類庫命令。
項目中的Podfile.lock將提供類庫的版本信息，保證甲和乙使用相同版本的類庫，不會帶來大家版本不一致的問題。
即使類庫C已經更新到版本1.2.0，但乙安裝的C的版本仍是1.0.0 。因爲Podfile.lock 已經將C的版本鎖定爲1.0.0了。
場景4:檢查類庫更新版本
沒過多久，甲想檢查一下類庫是否有新版本。於是他使用 pod outdated 命令，發現類庫B有1.1.0版本，類庫C有1.2.0版本。
但甲只想更新B，不想更新C；於是他運行 pod update B 將B更新到1.1.0版，這個命令同時更新了Podfile.lock 文件中B的紀錄。此時C仍爲1.0.0版，不會更新。
在Podfile中指定類庫版本還不夠
有些人可能認爲只要在 Podfile 中指定版本信息就好了，就像 pod ‘A’, ‘1.0.0’ ，足夠保證團隊中每個人都能使用相同版本的類庫了，何須像上面那麼麻煩？
之後向項目添加其他類庫時，他們可能會使用 pod update， 心想”我已經在 Podfile 中指定了版本信息了，不用擔心更新其他類庫“。
但事實並非如此，這樣做並不能保證上面情景中，甲乙始終使用相同的類庫。
據一個典型的例子，類庫A依賴於聲明在 A.podspec 中的類庫A2（dependence ‘A2’,’~>3.0’）。這種情況,在 Podfile 中寫入 pod ‘A’, ‘1.0.0’ 的確能保證甲乙同時使用1.0.0版本的A，但是：
甲結束編輯項目的時候，A2的版本爲3.4（因爲這是當時最新版本）
後來，乙加入項目，當他使用 pod install 的時候，可能得到A2的版本是3.5（因爲A2的維護者可能在甲乙交界期間發佈了新版本）
爲了保證團隊中每個成員都使用相同版本的類庫，一定要commit&push Podfile.lock,同時正確區別使用pod install 和pod update。