在管理專案版本時，我們追求的標籤（Tag）應該是清晰且具備語意的。但有時候手快打錯了字，或是推送到遠端（Remote）後才發現命名不夠精確，這時該怎麼辦？
本篇將針對標籤的「命名地雷」與「遠端更名流程」進行深度解析。一、 避開命名地雷：為什麼你的指令會報錯？
在 Git 中，標籤名稱就像檔案路徑一樣，有其嚴格的格式限制。
最常見的錯誤：包含空格 如果你執行 git tag v1.0.0 Chat Frontend，Git 會將 Chat 誤認為是目標位置（Commit ID），導致解析失敗。
正確的命名建議：
- 使用連字號：
v1.0.0-chat-frontend - 使用底線：
chat_frontend_v1.0.0 - 使用斜線（分類）：
chat/frontend/v1.0.0
二、 進階實戰：如何更換「已推送到遠端」的標籤？
Git 其實沒有「重新命名」標籤的直接指令，我們的邏輯是：「建立一個新的，然後刪除舊的（包含本地與遠端）」。
假設我們想將舊標籤 v1.0.0 更改為更詳盡的 chat_frontend_v1.0.0，並指定在特定 Commit 4d2cb29 上，請依照以下四步驟操作：
步驟 1：建立新的附註標籤
使用 -a 建立附註標籤，並透過 -m 加入發布訊息：
指令：
git tag -a chat_frontend_v1.0.0 4d2cb29 -m "Chat frontend 1.0.0 版本發布"
步驟 2：刪除本地舊標籤
指令：
git tag -d v1.0.0
步驟 3：刪除遠端伺服器上的舊標籤
標籤一旦推送到遠端，就必須手動下達刪除指令：
指令：
git push origin --delete v1.0.0
步驟 4：推送新標籤至遠端
指令：
git push origin chat_frontend_v1.0.0
三、 附註標籤（Annotated Tag）的好處
為什麼建議開發者多使用 git tag -a 而不是簡單的標籤？
- 資訊完整： 它會記錄標籤是「誰」在「何時」打的。
- 包含備註： 可以像 Commit 一樣寫下詳細的 Release Note，這在日後追溯版本差異時非常有幫助。
- 安全性： 它是一個獨立的 Git 物件，包含檢查碼（Checksum），確保標籤指向的內容不被竄改。
結語：給團隊的溫馨提醒
修改已經公開的標籤屬於「修改歷史」的一環。如果你的團隊成員已經 pull 了舊標籤，請記得通知大家執行以下指令來同步遠端狀態，避免本地端殘留已失效的舊標籤：
git fetch --prune --tags
掌握這些技巧，你的 Git 紀錄將會像精品一樣整齊專業！
