pod install 和 pod update 之間的不同之處？
什么時候使用pod install怯疤？
什么時候使用pod update?
......
1.介紹一下
許多開發(fā)者 使用CocoaPods 時浆洗，似乎認(rèn)為pod install 只用于第一次建立使用CocoaPods的工程，而在這之后要用pod update集峦，但事實并非如此伏社。
這篇引導(dǎo)的目的就是解釋什么該使用pod install,什么時候該使用pod update。
簡單的說就是(總結(jié)精華)：
1. 使用pod install在你的工程里安裝新的pods塔淤。盡管你已經(jīng)有了一個Podfile并且之前運行過pod install摘昌；
盡管你只是在已經(jīng)使用了CocoaPods的工程中添加/移除了pod，你都要使用pod install高蜂。
2. 只有在你想要更新pods到新的版本時才使用pod update [PODNAME]聪黎。
小貼士：
注意：install和update這兩個詞實際上并不是CocoaPods獨有的。它們也被許多其他依賴的管理器推薦使用备恤，
如bundler稿饰，RubyGems或者composer，它們都有類似的命令露泊，并且有與本文描述完全相同的行為和意圖湘纵。
2. 命令的詳細介紹
2.1 pod install
用于工程中第一次 在工程中 安裝初始化pods， 也用于每次編輯Podfile添加滤淳、更新或移除pod時梧喷。
Podfile.lock 文件介紹，這個文件會保持對每個pod已安裝的版本的跟蹤脖咐，并且鎖定這些版本铺敌。
每次運行pod install命令時——下載和安裝新的pods——并將每個已經(jīng)安裝的pods的版本號寫入Podfile.lock文件。
當(dāng)你運行pod install時屁擅，它只會處理沒有被記錄在Podfile.lock文件中的pods的依賴偿凭。
1. 對于已經(jīng)記錄在Podfile.lock中的pods，會下載記錄在Podfile.lock文件中的準(zhǔn)確版本派歌，而不去檢查是否有新版本可用弯囊。
2. 對于沒有記錄在Podfile.lock文件中的pods，會查找匹配Podfile中描述的版本（如pod ‘MyPod’, ‘~>1.2’）胶果。
2.2 pod outdated
當(dāng)你運行pod outdated命令匾嘱，CocoaPods會列出所有有新版本的pods，
新版本是指比記錄在Podfile.lock文件中的版本（即當(dāng)前每個pod安裝的版本）更新的版本早抠。
這意味著如果你對這些pod運行pod update PODNAME霎烙，
它們將會更新——只要這些版本仍然滿足如pod ‘MyPod’, ‘~>x.y’這樣設(shè)置在Podfile中的約束。
2.3 pod update
當(dāng)你運行pod update PODNAME命令，CocoaPods將會嘗試找到PODNAME指定pod的更新版本悬垃，
而不會顧及Podfile.lock文件中記錄的版本游昼。它將會更新pod的最新可用版本
（只要滿足Podfile中的版本約束）。
如果你運行pod update而不帶pod名稱尝蠕，CocoaPods將會更新Podfile文件中記錄的每一個pod到最新可用版本烘豌。
3.用途
使用pod update PODNAME，你可以只更新指定的pod（檢查是否存在新版本并相應(yīng)的更新這個pod）看彼。
相反pod install不會嘗試更新已經(jīng)安裝的pod的版本廊佩。
當(dāng)你添加一個pod到你的Podfile，你應(yīng)該運行pod install闲昭，而不是pod update——才能安裝這個新的pod罐寨，
同時不會帶來在同一個處理過程中更新已存在的pod的風(fēng)險靡挥。
當(dāng)你想要更新指定pod（或所有pod）的版本時序矩，應(yīng)該只使用pod update。
4. 提交Podfile.lock文件
小貼士：
作為提醒跋破，除非你的策略是不能提交Pods文件夾到共享倉庫簸淀，否則你應(yīng)該總是提交并推送你的Podfile.lock文件。
否則毒返，你將會打破上述關(guān)于pod install將會鎖定你的pods的已安裝版本的整個邏輯租幕。
5. 場景示例
以下是一些場景例子列舉了在工程周期中可能遭遇的各種使用情況。
場景1：用戶1創(chuàng)建工程
用戶1創(chuàng)建了一個工程拧簸，并想使用pods A劲绪、B、C盆赤。他創(chuàng)建了這些pods的Podfile贾富，然后運行pod install。
這將會安裝pods A牺六、B颤枪、C，我們假定它們都是版本1.0.0.
Podfile.lock文件將會持續(xù)跟蹤淑际，并記住A畏纲、B和C都已經(jīng)安裝為版本1.0.0。
另外春缕，由于這是第一次運行pod install盗胀，并且Pods.xcodeproj工程并不存在，
該命令也會創(chuàng)建Pods.xcodeproj和.xcworkspace锄贼，但這只是該命令的副作用而非主要功能读整。
場景2：用戶1添加了新的pod
隨后，用戶1想要添加pod D到他們的Podfile。
他們在這之后也應(yīng)該運行pod install米间，因此即使pod B的維護者在第一次執(zhí)行pod install之后發(fā)布了版本1.1.0强品，
這個工程也將繼續(xù)使用版本1.0.0——因為用戶1只想要添加pod D，而不想有意外的更新了pod B的風(fēng)險屈糊。
小貼士：
tip：這就是一些人錯誤的地方的榛，
因為他們在這里使用了pod update——可能認(rèn)為這就是“用新的pods更新工程”的意思？——而不是使用pod install——才能在工程中安裝新的pods逻锐。
場景3：用戶2加入到工程中
然后用戶2夫晌，一個以前從未參與過這個工程的人，加入到團隊之中昧诱。他克隆了倉庫晓淀，然后使用pod install。
Podfile.lock文件（應(yīng)該被提交到git倉庫中）的內(nèi)容會保證用戶2能獲得完全相同的pods盏档，以及與用戶1使用的完全相同的版本凶掰。
盡管pod C的1.2.0版本現(xiàn)在已經(jīng)可用，用戶2仍將獲得pod C的1.0.0版本蜈亩。
因為這就是寫在Podfile.lock中的內(nèi)容懦窘。pod C被Podfile.lock文件鎖在了1.0.0版本（因此這個文件叫這個名字）。
場景4：檢查pod的新版本
后來稚配，用戶1想要檢查這些pods是否有更新可以用畅涂。他運行了pod outdates，這個命令會告訴他pod B有新的1.1.0版本且pod C有新的1.2.0版本道川。
用戶1決定他們要更新pod B大州，但是不更新pod C蒙具；因此他運行pod update B舆瘪，
讓B從版本1.0.0升到版本1.1.0（同時Podfile.lock文件也隨之更新）锨推，但是將pod C保持在1.0.0版本（不會更新到1.2.0）。
5. 在Podfile中使用準(zhǔn)確版本號是不夠的
有些人可能想通過在他們的Podfile中指定pods的準(zhǔn)確版本號宦言，如pod ‘a(chǎn)’, ‘1.0.0’扇单，就能夠保證團隊中的其他人擁有相同的版本。
然后他們即使使用了pod update奠旺，即使添加了新的pod蜘澜，認(rèn)為這將不會有更新到其他pods的風(fēng)險，因為他們已經(jīng)在Podfile中綁定到指定的版本了响疚。
但實際上鄙信，這不足以保證我們在上面場景中提到的用戶1和用戶2總能得到所有pods的相同版本。
一個典型的例子是忿晕，如果pod A依賴了A2——在A.podspec中有聲明dependency ‘A2’, ‘~> 3.0’装诡。
此時，在Podfile中使用pod ‘A’,’1.0.0’，確實會強制用戶1和用戶2都總是使用pod A的1.0.0版本鸦采，但是：
用戶1可能最后得到pod A2的3.4版本（因為這是A2那時的最新版本）宾巍，而當(dāng)用戶2在之后加入工程運行pod install時，
他可能得到pod A2的3.5版本（因為A2的維護者可能在這段時間里發(fā)布了新的版本）渔伯。
這就是為什么確保每一個團隊成員都能在各自的電腦上使用相同版本的pod庫的唯一方法就是使用Podfile.lock顶霞，
并且正確的使用pod install和pod update。
