在 VisualStudio 的團隊管理功能，提供了方便的添加 Tag 的方法，可以新建一個 Tag 添加 Tag 信息，同時推送某個特定的 Tag 到伺服器。配合推 Tag 打包 NuGet 的方法，將可以讓整套工具用起來特別爽，完全本地化打 Tag 推送就完成了 NuGet 伺服器打包推送 ...
在 VisualStudio 的團隊管理功能，提供了方便的添加 Tag 的方法，可以新建一個 Tag 添加 Tag 信息，同時推送某個特定的 Tag 到伺服器。配合推 Tag 打包 NuGet 的方法，將可以讓整套工具用起來特別爽，完全本地化打 Tag 推送就完成了 NuGet 伺服器打包推送
進入團隊管理界面，我用的英文版的，但是按鈕在中文版也沒有變化。我的 VisualStudio 是 2019 的
點擊 Tags 進入標記界面
此時可以通過點擊 新建Tag按鈕 新建一個 Tag 給他版本號和信息，請看下圖
點擊創建按鈕就可以完成了創建，上面代碼只有 Tag 號是必須的，而信息是不必須的。當然有信息可以協助小伙伴更好瞭解這個 Tag 對應的功能
此時就可以看到剛纔新建的 Tag 了，右擊這個新建的 Tag 號就可以找到推送按鈕，點擊推送按鈕就可以將 Tag 推送到伺服器了
熟悉這個方法可以快速給代碼添加一個 Tag 號
配合 dotnet 配合 Gitlab 做自動推 Tag 時打包 NuGet 包 可以特別方便打 Tag 打包推送
為什麼需要推送 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 包或切換到對應版本的源代碼
