前言

在使用CocoaPods時，難免會混淆pod install 和 pod update的用法，于是在官網找到了相應的說明文章，并決定翻譯過來，供大家學習。

以下內容來自:pod install vs. pod update翻譯。

CocoaPods

正文

介紹

很多人使用CocoaPods時往往認為pod install只是在首次配置項目的時候使用的，而pod update是稍后更新庫的時候使用的。但是事實并非如此。

這篇文章的目的是闡述清楚什么時候使用pod install命令，什么時候使用pod update命令。

綜述：

• 使用pod install在你的項目中安裝新的庫，即使你已經有了Podfile文件并且運行過pod install命令，或者你已經有添加、刪除過庫。

• 使用pod update [PODNAME]僅僅是在你想更新庫版本的時候。

命令的詳細細節：

pod install:

該命令是在你第一次在項目中獲取庫的時候使用，并且在每次你對 Podfile文件編輯的時候（添加、更新、刪除）使用。

每一次運行pod install命令后，都會去下載安裝新的庫，并且會修改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中記錄的有最新版本的庫，意思是，如果你進行了pod update PODNAME操作，只要這些庫符合Podfile.lock中的版本限制（如pod MyPod, ‘~>x.y’），那么它就會更新。

pod update

當你運行了 pod update PODNAME命令，CocoaPods將不會考慮Podfile.lock中列出的版本，而直接去查找該庫的新版本。它將更新到這個庫盡可能新的版本，只要符合Podfile中的版本限制要求。

如果使用pod update 命令不帶庫名稱參數，CocoaPods將會去更新Podfile中每一個庫的盡可能新的版本。

正確的用法：

使用pod update PODNAME可以去更新一個庫的指定版本（檢查相應的庫是否存在更新的版本，并且更新）,相對應的，使用pod install將不會更新那些已經下載安裝了的庫。

當你在Podfile中添加了一個新的庫時，你應該使用pod install命令，而不是pod udpate，這樣安裝了新增的庫，也不會重復安裝已經存在的庫。

使用pod update僅僅只是去更新指定庫的版本（或者全部庫）。

提交你的Podfile.lock文件:

提醒一下，即使你一向不commit你的庫文件到你的共享倉庫，你也應該總是commit & push到你的Podfile.lcok文件中。

否則，就會破壞掉pod install 的整個設計邏輯，造成Podfile.lock文件無法鎖定你已經安裝的庫。

場景應用：

這里有一個場景示例來展示在項目的聲明周期中各種方案的使用。

例1：用戶1創建了一個項目

用戶1創建了一個工程，并且想使用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：用戶1添加了一個新庫

其后，用戶1添加了一個庫D到Podfile文件中。

然后他就運行pod install命令了。因此即使庫B的開發者發布了B的一個新版本1.1.0。但只要是在第一次執行pod install之后發布的新的版本，那么B的版本使用的仍然是1.0.0。因為用戶1只是希望添加一個新庫D，不希望更新庫B。

這就是很多人容易出錯的地方，因為他們在這里使用了pod update，而不是pod install，可能是想著“我要更新一下我工程中的庫”。

例3：用戶2加入到工程中

用戶2是一個之前沒有參與到這個工程的人，稍后加入到項目中。他使用pod install命令克隆了代碼倉庫。

如果Podfile.lock被提交到git倉庫中，那么Podfile.lock的內容就會確保用戶1和用戶2會得到完全一樣的庫。

即使庫C已經有了到了1.2.0版本，用戶2使用的庫C仍然是1.0.0版本，因為庫C已經在Podfile.lock里面注冊過了，庫C的1.0.0版本已經在Podfile.lock中被鎖住了。

例4：檢查某個庫的新版本

之后，用戶1想檢查pods里面是否有可更新的庫時，他執行了 pod outdated，這個命令將會羅列出來：庫B有了新版本1.1.0，庫C有了新版本1.2.0。

用戶1決定更新庫B，但不更新庫C，所以執行pod update B，這樣就把庫B從1.0.0更新到1.1.0（同時更新Podfile.lock中相應的庫B的版本記錄），此時，庫C仍然是1.0.0版本，不會被更新到1.2.0。

在Podfile中使用明確的版本還不夠

有些人可能認為在Podfile中指定某個庫的版本已經足以保證所有項目團隊中的人都會使用完全一樣的版本，比如：pod 'A', '1.0.0' 。

然后，他們可能認為此時如果添加一個新庫的時候，我使用pod update并不會去更新其它的庫，因為其它的庫已經被限定了固定的版本號。

但事實上，在以上場景中，這不足以保證用戶1和用戶2用到的庫版本完全一樣。

一個典型的例子是，如果庫A對A2有一個依賴（比如聲明在A.podspec中：dependency 'A2', '~> 3.0'），這樣的話，在你的Podfile中使用 pod 'A', '1.0.0'將會讓用戶1和用戶2都使用同樣版本的庫A（1.0.0）。

• 但是，用戶1最后可能使用的是版本為3.4的庫A2（因為3.4是當時用戶1使用的最新版本）。

• 用戶2稍后加入到項目中，使用pod install 安裝庫，得到的庫A2版本可能是3.5（假設A2的開發者剛剛發布了A2的新版本3.5）。

這就是為什么使用Podfile.lock這一個方式來保證參與項目的每個開發者的電腦中都使用相同版本的庫，并且合理的使用pod install和 pod update。