通過推送 Tag 才打 NuGet 包的方法的作用不僅僅是讓打包方便，讓打包這個動作可以完全在本地執行，無需關註其他系統的使用步驟。更重要的是可以強制每個可能被安裝的 NuGet 包版本都能有一個和他對應的 Tag 號，原因是為瞭解決回退到某個版本發現有一個坑，這個坑是因為某個依賴庫的版本問題，此時... ...
通過推送 Tag 才打 NuGet 包的方法的作用不僅僅是讓打包方便，讓打包這個動作可以完全在本地執行，無需關註其他系統的使用步驟。更重要的是可以強制每個可能被安裝的 NuGet 包版本都能有一個和他對應的 Tag 號，原因是為瞭解決回退到某個版本發現有一個坑，這個坑是因為某個依賴庫的版本問題，此時我期望最小改動，我雖然能拿到這個庫的代碼，但是我很難知道我這個版本安裝的 NuGet 庫對應依賴庫的哪個 commit 的代碼
我之前每次需要追蹤某個 NuGet 包對應的依賴庫的源代碼的版本的時候，都需要進入打包伺服器，查看打包日誌，在這樣很坑玩了很久，公司的配置管理員幹掉了伺服器，刪除了日誌。而我接到一個很古老的項目需要修複某個坑，此時這個項目引用了一個底層庫的古老版本，此時我不能升級底層庫，應該底層庫的改動量太大了。但是我又很難定位我現在項目引用的 NuGet 庫對應的底層庫的哪個 commit 代碼。後面只能通過二分的方法，用了幾天的開發才完成
所以看到了我上面的坑，小伙伴大概也就能知道為什麼我期望將 Tag 和 NuGet 包關聯了
在我現在團隊的約定裡面，只要添加了 alpha 也就是預覽版，就可以隨意推送測試的 Tag 讓伺服器幫你打包 NuGet 包，然後在其他的項目安裝。為什麼會鼓勵這樣做？原因是有小伙伴說我的某個項目的開發依賴某個庫，但是假設這個庫一定是合併到主分支之後才能打出 Tag 打包，也就是小伙伴在某個項目的代碼將一直不能推送。同時小伙伴也不能在 csproj 裡面引用某個私有的版本，因為私有的版本只有小伙伴自己能構建通過，其他小伙伴可構建不通過
假設小 A 需要開發項目 F 而這個項目以來庫 L 的更改
而庫 L 的更改如果沒有合併到 master 分支，就不允許推送 Tag 打包
此時小 A 如果推送了代碼，這個代碼引用了還沒有被髮布的 L 庫的代碼，那麼其他小伙伴將無法構建通過
此時小 A 如果推送了代碼，這個代碼引用了小 A 本地生成的 NuGet 庫，那麼其他小伙伴將找不到這個 NuGet 庫，無法構建通過
如果小 A 不推送代碼，只是寫了一個 commit 但是這個 commit 包含了 L 庫的代碼，但是沒有在 csproj 裡面升級 L 庫版本，那麼在回滾代碼的時候，進入到這個 commit 將構建失敗
如果小 A 在 commit 裡面升級到他本地生成的 NuGet 庫，那麼回滾代碼的時候，因為公共伺服器不存在小 A 的本地的 NuGet 庫，依然會構建失敗
此時有一個叫頭像的小伙伴出了一個餿主意，小 A 雖然 L 庫代碼沒有被合併，但是可以知道這個 L 庫被合併之後分配的版本號，此時就在 csproj 裡面更新到這個版本，然後通過本地打包的方法引用和推送。但是這個方法存在以下問題
- 小伙伴本地打包第一次，發現翻車了，想要第二次打包，但是此時的版本號就重疊了，需要經過黑科技刪除 NuGet 緩存重新構建，此時的效率特別低
- 小伙伴在這次 commit 寫的代碼是他認為發佈的時候將會添加的公開方法，但是實際上最後發佈的時候更改了公開方法，此時回滾到這個 commit 雖然能下載到 NuGet 庫，但是發現 L 庫的公開方法不匹配，構建失敗
這就是為什麼選用推送 Tag 打包的原因，允許小伙伴自己選擇預覽版的版本推送，自動打包，這樣就可以在項目中使用此Tag 打出的預覽版的代碼。此時的 commit 其他小伙伴也能構建，回滾代碼的時候也可以在公共伺服器找到 NuGet 包或切換到對應版本的源代碼
在 VisualStudio 的幫助下，使用推Tag打包的成本非常低，因為在 VS 裡面只需要簡單5次點擊加上輸入版本號就能完成 Tag 新建和推送，詳細請看 VisualStudio 如何快速添加一個 Git Tag 推送
在本地推Tag打包還有一個好處是能提升不少的效率，有很多團隊例如我現在的團隊之前就是使用 jenkins 打包，這個工具太強大而讓上手和維護成本都特別高，加上使用的小伙伴太多，伺服器性能不足，每次打包都需要等待緩慢的系統響應。而通過 Tag 打包的方式可以隱藏這部分動作，所有動作都在本地執行。只有最後一步推送需要依賴 Git 服務的網路
