介紹
很多人使用 CocoaPods 的時候可能會以為第一次是用 pod install 安裝配置工程，之后都是用pod update ，但其實不是這樣。
這篇文章的目的是為了解釋 pod install 和 pod update正確的使用時機。
TL;DR:
- 如果你是第一次安裝 pods ，或者你在 Podfile 中新增/移除了 pods， 使用
pod install命令安裝 pods 。 - 在更新新版本的 pods 時，使用
pod update [PODNAME]。
命令詳情
小提示：使用
install和update的詞匯并不是 CocoaPods 想出來的。靈感來源于其他語言的依賴管理，比如 bundler， RubyGems，composer 等，它們跟 CocoaPods 有著很多相似的命令，意圖也相同。
pod install
在第一次安裝 pods 的使用該命令，但也可以在每次往 Podfile中新增，修改 ，移除 pods 的時候使用。
- 每次執(zhí)行
pod install命令 —— 下載并安裝新的 pods —— 根據(jù)Podflie.lock文件的版本來安裝對應(yīng)的 pod。 - 當執(zhí)行
pod install時，只解決沒有在Podfile.lock里列出的 pods。- 如果在
Podfile.lock列表中，會先下載Podfile.lock中顯示指定的版本，而不會試圖安裝新版本。 - 如果不在
Podfile.lock列表中，會搜索在Podfile文件列表中指定的版本（就像pod ‘MyPod’, ‘~>1.2’）
- 如果在
pod outdated
當執(zhí)行 pod outdated, CocoaPods 會列出 Podfile.lock 中所有新版本的 pods。這意味著如果你執(zhí)行 pod update PODNAME，這些 pods 會被更新到 Podfile 文件里面所指定的能夠升級的最高版本，形如：pod 'MyPod', '~>x.y’。
Podfile 版本約束規(guī)則可以參考這里。
pod update
當執(zhí)行 pod update PODNAME時，Cocoapods 會查找 PODNAME 新的版本，忽略 Podfile.lock 中鎖定的版本號。將 pods 升級到最高版本，不過仍會受到 Podfile 中指定的版本約束。
如果執(zhí)行 pod update 沒有指定名字， CocoaPods 會更新Podfile 列表中所有的 pods。
根據(jù)意圖使用
pod update PODNAME 會更新指定的 pod，相對的 pod install 不會更新已經(jīng)安裝的 pods 版本。
當新增 pod 到 Podfile，你應(yīng)該使用 pod install， 而不是 pod update 來安裝新版本的 pod ，避免在這個過程中更新已經(jīng)存在的 pods。
如果你想要更新新版本 pods 再使用 pod update 命令。
提交 Podfile.lock 文件
作為提醒，如果你沒有提交 Pods 文件目錄到 git，你必須提交并推送 Podfile.lock 文件。
否則，可能會造成團隊之間執(zhí)行 pod install安裝的 pods 版本不一致。
案例
下面介紹一些在實際工程項目中可能會遇到的問題。
階段一：用戶 1 創(chuàng)建工程
用戶 1 創(chuàng)建了一個新的工程并想要使用 A, B,C三個 pods。他創(chuàng)建Podfile 文件，加入這三個 pods，并執(zhí)行 pod install。
這樣就成功安裝了 A, B, C三個 pods，假設(shè)它們的版本都是 1.0.0。
Podfile.lock 會跟蹤并記錄 A, B, C 的版本為 1.0.0。
因為這是我們第一次執(zhí)行
pod install，.xcodeproj工程將不再存在。取而代之的是.xcworkspace以及Pods.xcodeproj，但這并不會影響主工程的功能。
階段二：添加一個 pod
此后，如果用戶 1 想要新增 pod D 到 Podfile 文件。
他必須執(zhí)行 pod install，即使現(xiàn)在 pod B 發(fā)布了新版本 1.1.0，工程仍然會使用 1.0.0 的版本。因為用戶 1 只是想添加 pod D并不希望更新其它的 pods。
這里有些用戶可能會誤用
pod update，這是不對的。
階段三：用戶 2 加入工程
接著用戶 2 需要參與工程開發(fā)，他是新加入的，先克隆了工程并執(zhí)行 pod install。
Podfile.lock 文件(已被提交到版本控制)會保證新用戶安裝的 pods 版本，同用戶 1 的一致。
即使 pod C 此時有新版本 1.2.0可用，用戶 2 安裝的仍舊是 1.0.0版本。因為 C 已經(jīng)被 Podfile.lock 文件鎖定在 1.0.0 版本了。
階段四：檢查 pod 新版本
之后，用戶 1 想要檢查一下 pods 是否有新版本可用，他執(zhí)行 pod outdated 這將會告訴他 B 發(fā)布了 1.1.0, C 發(fā)布了 1.2.0 的新版本。
用戶 1 決定更新 pod B，但是不想更新 pod C，所以他執(zhí)行 pod update B 將 B 從 1.0.0 版本更新到 1.1.0 版本（會同時更新 Podfile.lock 文件）并保持 pod C 的版 本還是 1.0.0。
為 Podfile 文件指定版本號的缺陷
有人可能會認為只要在 Podfile 文件中指定 pods 的版本，就可以保證團隊之間保持相同版本的 pods，比如 pod ‘A’， ‘1.0.0’
在加入新 pod 的時候，即使執(zhí)行 pod update,也不會有升級其它 pods 的風(fēng)險，因為它們的版本在 Podfile 中指定死了。
但實際上，上述場景并不能保證 用戶1 和 用戶2 所有 pods 的版本都一致。
舉個典型的例子，加入 pod A 在 A.podspec (關(guān)于 podspec 的說明請查看 CocoaPods 制作專題)文件中指定依賴為 ’A2’, ‘~> 3.0’，這種情況下，在 Podfile 中使用 pod 'A', ‘1.0.0’ 這的確會保證用戶 1 和 用戶 2 使用的 pod A 是 1.0.0 版本的，但是：
- 用戶 1 當時安裝的 A2 是
3.4版本的； - 當用戶 2 加入并執(zhí)行
pod install的時候，A2可能有了3.5版本，就會導(dǎo)致他安裝的是最新版本的。
所以，這就是為什么需要團隊之間協(xié)作將 Podfile.lock 提交到版本控制，并正確的區(qū)分 pod install 和 pod update的重要性。
