平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“Git Tag打、切换、推送和删除的操作指南”来说，它看着像小点，放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序，把思路、关键写法和容易踩坑的地方讲清楚，便于大家直接对照操作。
在 Git 项目开发里，经常会遇到这样的场景：
- 项目准备上线，需记录一个稳定版本
- 后续出问题，需回到某个历史版本
- 前端、后端、运维需根据版本号部署代码
- Docker 镜像、发布包、生产环境需和代码版本对应
这个时候就会用到 Git 的 Tag。
轻松来说：
Git Tag 就是给某一次 commit 打一个固定的版本标记。
比如：
v1.0.0
v1.1.0
v2.0.0
release-2026-05-26
它能够帮助我们准确找到某个版本对应的代码。
一、Tag 是什么？
Git 里面的 Tag，能够理解为：
给某一次代码提交做一个固定标记
比如你的提交历史是这样的：
A --- B --- C --- D --- E
↑
v1.0.0
如果你在 C 这个 commit 上打了一个 v1.0.0 的 tag，那么以后不管你继续提交多少代码，v1.0.0 永远都指向 C。
后续你继续开发：
A --- B --- C --- D --- E
↑ ↑
v1.0.0 main
这时候：
main分支已经走到了Ev1.0.0还是停在C- tag 不会因为你后续修改代码而改变
二、Tag 和 Branch 的区别
很多新手容易把 Tag 和 Branch 搞混。
能够这样理解：
branch = 会继续变化的开发线
tag = 固定不变的版本快照
比如：
main 分支：一直往前开发
v1.0.0 tag：永远指向发布 v1.0.0 时的那个 commit
Branch 适合什么？
Branch 适合开发：
main
dev
feature-login
fix-order-bug
比如你要开发一个登录功能，能够新建一个分支：
git checkout -b feature-login
后面你会不断在这个分支上提交代码。
Tag 适合什么？
Tag 适合发版：
v1.0.0
v1.1.0
v2.0.0
比如你项目上线了，就能够打一个 tag：
git tag -a v1.0.0 -m "发布 v1.0.0 版本"
以后你就能够借助这个 tag 找回上线时的代码。
三、查看当前项目有哪些 Tag
查看本地所有 tag：
git tag
输出示例：
v1.0.0
v1.1.0
v1.2.0
如果 tag 很多，能够模糊搜索：
git tag -l "v1.*"
输出示例：
v1.0.0
v1.1.0
v1.2.0
四、如何打 Tag
Git 打 Tag 常用有两种方式：
- 轻量 Tag
- 附注 Tag
真实开发场景下，更建议采用 附注 Tag。
五、轻量 Tag
轻量 tag 就是轻松地给当前 commit 做一个标记。
git tag v1.0.0
结合项目来看，这个命令会给当前所在的 commit 打上 v1.0.0 标签。
查看 tag：
git tag
查看 tag 对应的信息：
git show v1.0.0
轻量 tag 比较轻松，但是没有额外的说明信息，不太适合正式发版。
六、建议方式：附注 Tag
从实现思路看，附注 Tag 能够带版本说明、新建人、新建时间等信息，更适合正式发布版本。
命令格式：
git tag -a 标签名 -m "说明信息"
比如：
git tag -a v1.0.0 -m "发布 v1.0.0：完成基础功能"
查看 tag 信息：
git show v1.0.0
输出中会包含：
- tag 名称
- tag 新建人
- tag 新建时间
- tag 说明信息
- 对应的 commit 信息
正式项目中建议采用这种方式。
七、给指定 commit 打 Tag
落到代码里，有时候你不是给当前 commit 打 tag，而是想给某个历史 commit 打 tag。
先查看提交记录：
git log --oneline
示例：
e8f9a12 修复库存调拨 bug
c3a7b91 完成库存调拨功能
a9d2c33 初始化项目
如果你想给 c3a7b91 这个 commit 打 tag：
git tag -a v1.0.0 c3a7b91 -m "发布 v1.0.0：完成库存调拨功能"
查看：
git show v1.0.0
这样 v1.0.0 就会指向 c3a7b91 这个 commit，而不是当前最新 commit。
八、打完 Tag 后，后续修改代码会影响原来的 Tag 吗？
不会。
Tag 打完之后，它会固定指向当时的 commit。
比如：
A --- B --- C
↑
v1.0.0
然后你继续开发，提交了新的代码：
A --- B --- C --- D --- E
↑ ↑
v1.0.0 main
这时候：
v1.0.0还是指向Cmain已经到了E- 后续修改不会影响
v1.0.0
若你要发布新版本，需重新打一个新 tag：
git tag -a v1.1.0 -m "发布 v1.1.0：新增订单功能"
最后可能是这样：
A --- B --- C --- D --- E
↑ ↑
v1.0.0 v1.1.0
九、推送 Tag 到远程仓库
注意：本地打完 tag 后，默认只存在本地，远程仓库是看不到的。
你需手动推送 tag。
推送指定 tag：
git push origin v1.0.0
推送所有本地 tag：
git push origin --tags
一般建议推送指定 tag，避免把本地一些测试 tag 也推上去：
git push origin v1.0.0
十、完整发版流程示例
实际处理时，假设你现在项目开发完成，准备发布 v1.0.0。
1. 查看当前状态
git status
如果有修改，先提交：
git add .
git commit -m "完成库存调拨功能"
2. 确认当前分支
git branch
或者：
git status
确认你在正确的分支上，比如 main。
3. 拉取最新代码
git pull origin main
避免本地代码落后于远程。
4. 推送代码
git push origin main
5. 打 tag
git tag -a v1.0.0 -m "发布 v1.0.0：完成库存调拨功能"
6. 推送 tag
git push origin v1.0.0
这样远程仓库就有了 v1.0.0 这个版本。
十一、如何切换到某个 Tag
切换到某个 tag：
git checkout v1.0.0
或者新版本 Git 建议用：
git switch --detach v1.0.0
切换后，你会进入一个特殊状态，叫做：
detached HEAD
中文能够理解为：
游离 HEAD 状态
这是什么意思？
意思是你现在不是在某个分支上，而是临时查看 tag 对应的代码。
十二、什么是 detached HEAD？
当你执行：
git checkout v1.0.0
Git 可能会提示：
You are in 'detached HEAD' state.
很多新手看到这个提示会害怕，其实不用怕。
它的意思是：
你现在正在查看某个固定版本，而不是在分支上继续开发
比如：
A --- B --- C --- D --- E
↑ ↑
v1.0.0 main
你切换到 v1.0.0 后，当前代码就是 C 那个版本。
这个时候适合做这些事情：
- 查看历史代码
- 对比问题
- 本地运行旧版本
- 确认某个版本是否有 bug
但是不建议直接在 detached HEAD 状态下继续开发。
十三、从 Tag 切回主分支
若你只是查看旧版本，看完后想回到主分支：
git checkout main
或者：
git switch main
如果你的主分支叫 master：
git checkout master
或者：
git switch master
十四、如果想基于某个 Tag 修改代码怎么办？
不要直接在 tag 上改。
因为 tag 是固定版本，不适合直接继续开发。
正确做法是：基于这个 tag 新建一个新分支。
比如你想基于 v1.0.0 修复 bug：
git checkout -b fix-v1.0.0-bug v1.0.0
或者：
git switch -c fix-v1.0.0-bug v1.0.0
这行命令的意思是：
从 v1.0.0 这个版本创建一个新分支 fix-v1.0.0-bug
然后你就能够在这个新分支上正常修改代码、提交代码。
git add .
git commit -m "修复 v1.0.0 版本中的库存 bug"
若修复完成后要发布补丁版本，能够再打一个新 tag：
git tag -a v1.0.1 -m "发布 v1.0.1：修复库存 bug"
git push origin fix-v1.0.0-bug
git push origin v1.0.1
十五、切换 Tag 后修改了代码怎么办？
假设你执行了：
git checkout v1.0.0
然后你不小心修改了代码。
这时候先不要慌。
查看当前状态：
git status
如果你只是误改了，不想保留：
git restore .
若你想保留这些修改，应该新建一个新分支：
git switch -c fix-from-v1.0.0
然后提交：
git add .
git commit -m "基于 v1.0.0 修复问题"
这样你的修改就不会丢失，也不会直接影响原来的 tag。
十六、查看某个 Tag 对应的代码差异
查看 tag 的详细信息：
git show v1.0.0
查看两个 tag 之间的差异：
git diff v1.0.0 v1.1.0
查看两个 tag 之间的提交记录：
git log v1.0.0..v1.1.0 --oneline
这个命令很适合用来写版本更新日志。
比如：
git log v1.0.0..v1.1.0 --oneline
输出：
e8f9a12 修复库存调拨 bug
a7c2d11 新增订单导出功能
b6d9f21 优化登录页面
十七、删除本地 Tag
若你本地 tag 打错了，能够删除。
删除本地 tag：
git tag -d v1.0.0
注意：这只会删除本地 tag，不会删除远程 tag。
十八、删除远程 Tag
若 tag 已经推送到远程仓库，也需删除远程 tag。
删除远程 tag：
git push origin --delete v1.0.0
或者：
git push origin :refs/tags/v1.0.0
建议采用第一种：
git push origin --delete v1.0.0
十九、修改已经打好的 Tag
严格来说，不建议修改已经发布的 tag。
因为 tag 一旦推送到远程，其他人可能已经采用了它。
若你确实打错了，比如 v1.0.0 指向了错误 commit，能够这样处理：
1. 删除本地错误 tag
git tag -d v1.0.0
2. 删除远程错误 tag
git push origin --delete v1.0.0
3. 重新打 tag
git tag -a v1.0.0 正确的commitId -m "发布 v1.0.0"
比如：
git tag -a v1.0.0 c3a7b91 -m "发布 v1.0.0"
4. 重新推送 tag
git push origin v1.0.0
但是需留意：如果这个 tag 已经被别人拉取过，最好通知团队成员重新同步。
二十、拉取远程 Tag
一般执行：
git fetch
就会拉取远程分支信息，但不一定拉取所有 tag。
能够单独拉取 tag：
git fetch --tags
若你想从远程拿到最新 tag，能够执行：
git fetch origin --tags
查看：
git tag
二十一、根据 Tag 部署代码
实际处理时，很多时候，服务器上线时不是直接拉 main 最新代码，而是拉某个稳定 tag。
比如上线 v1.0.0：
git fetch --tags
git checkout v1.0.0
如果你需基于 tag 新建部署分支：
git checkout -b deploy-v1.0.0 v1.0.0
然后安装依赖、构建、启动服务。
前端示例：
npm install
npm run build
后端示例：
npm install
npm run start
或者采用 Docker：
docker build -t my-app:v1.0.0 .
docker run -d --name my-app -p 3000:3000 my-app:v1.0.0
这样 Docker 镜像版本和 Git Tag 版本就对应起来了。
二十二、Tag 命名规范
常用 tag 命名：
v1.0.0
v1.1.0
v2.0.0
建议采用语义化版本号：
主版本号.次版本号.修订号
比如：
v1.2.3
含义：
1 = 主版本号，通常表示大版本升级，可能有不兼容变化
2 = 次版本号，通常表示新增功能
3 = 修订号，通常表示 bug 修复
示例：
修复 bug：
v1.0.1
新增功能：
v1.1.0
大版本升级：
v2.0.0
也能够根据日期命名：
release-2026-05-26
不过一般项目更建议：
v1.0.0
v1.1.0
v1.1.1
二十三、常用命令速查表
查看所有 tag
git tag
查看匹配的 tag
git tag -l "v1.*"
新建轻量 tag
git tag v1.0.0
新建附注 tag
git tag -a v1.0.0 -m "发布 v1.0.0"
给指定 commit 打 tag
git tag -a v1.0.0 commitId -m "发布 v1.0.0"
查看 tag 信息
git show v1.0.0
推送指定 tag
git push origin v1.0.0
推送所有 tag
git push origin --tags
拉取远程 tag
git fetch --tags
切换到 tag
git checkout v1.0.0
采用 switch 切换到 tag
git switch --detach v1.0.0
从 tag 新建新分支
git checkout -b fix-v1.0.0 v1.0.0
或者：
git switch -c fix-v1.0.0 v1.0.0
删除本地 tag
git tag -d v1.0.0
删除远程 tag
git push origin --delete v1.0.0
查看两个 tag 之间的差异
git diff v1.0.0 v1.1.0
查看两个 tag 之间的提交记录
git log v1.0.0..v1.1.0 --oneline
二十四、新手常用问题
1. 打完 tag 后，我继续修改代码，tag 会变吗？
不会。
在这个场景下，Tag 会固定指向打 tag 时的 commit。后续你继续提交代码，只会让分支往前走，不会影响原来的 tag。
2. 为什么我本地有 tag，远程仓库看不到？
因为 tag 默认不会自动推送。
需执行：
git push origin v1.0.0
或者：
git push origin --tags
3. 切换 tag 后提示 detached HEAD 是不是出错了？
不是。
这是正常现象。
表示你现在正在查看一个固定版本，而不是在某个分支上开发。
如果只是查看代码，不用管。
如果要修改代码，建议新建新分支：
git switch -c fix-from-v1.0.0
4. 能够直接在 tag 上修改代码吗？
不建议。
Tag 是固定版本标记，不适合直接继续开发。
正确方式是从 tag 新建新分支：
git checkout -b fix-v1.0.0 v1.0.0
5. tag 打错了怎么办？
如果还没推送远程：
git tag -d v1.0.0
git tag -a v1.0.0 正确commitId -m "发布 v1.0.0"
如果已经推送远程：
git tag -d v1.0.0
git push origin --delete v1.0.0
git tag -a v1.0.0 正确commitId -m "发布 v1.0.0"
git push origin v1.0.0
但是如果团队成员已经采用过这个 tag，需通知大家重新同步。
6. 如何知道当前代码是不是某个 tag？
能够执行：
git describe --tags
若当前 commit 正好在某个 tag 上，可能输出：
v1.0.0
若当前 commit 在 tag 后面，可能输出：
v1.0.0-3-gabc1234
意思是：
当前代码基于 v1.0.0 之后又多了 3 个 commit
二十五、建议的实际工作流
一个比较规范的发版流程如下所示：
# 1. 查看当前状态
git status
# 2. 提交代码
git add .
git commit -m "完成 xxx 功能"
# 3. 拉取远程最新代码
git pull origin main
# 4. 推送代码
git push origin main
# 5. 打 tag
git tag -a v1.0.0 -m "发布 v1.0.0：完成 xxx 功能"
# 6. 推送 tag
git push origin v1.0.0
如果后续发现 v1.0.0 有 bug，需修复：
# 1. 基于 v1.0.0 创建修复分支
git checkout -b fix-v1.0.0-bug v1.0.0
# 2. 修改代码后提交
git add .
git commit -m "修复 v1.0.0 中的 xxx bug"
# 3. 打补丁 tag
git tag -a v1.0.1 -m "发布 v1.0.1：修复 xxx bug"
# 4. 推送修复分支
git push origin fix-v1.0.0-bug
# 5. 推送新 tag
git push origin v1.0.1
二十六、总结
Git Tag 的核心作用就是：
给某一次 commit 做版本标记
它最常用来：
- 项目发版
- 生产部署
- 版本回滚
- 生成发布记录
- Docker 镜像版本对应
- 查看历史稳定版本
需记住几个重点：
1. tag 是固定的，后续修改代码不会影响原来的 tag
2. 本地打 tag 后，需要手动 push 到远程
3. 切换 tag 后出现 detached HEAD 是正常的
4. 不建议直接在 tag 上开发
5. 如果要基于 tag 修改代码，应该从 tag 创建新分支
6. 正式发版推荐使用附注 tag：git tag -a
最常用的几个命令：
# 打 tag
git tag -a v1.0.0 -m "发布 v1.0.0"
# 推送 tag
git push origin v1.0.0
# 查看 tag
git tag
# 切换 tag
git checkout v1.0.0
# 从 tag 创建分支
git checkout -b fix-v1.0.0 v1.0.0
# 删除本地 tag
git tag -d v1.0.0
# 删除远程 tag
git push origin --delete v1.0.0
从实现思路看，总的来说，Git Tag操作指南适合结合实际项目边做边理解。先抓住核心思路，再逐步补上细节和边界处理，最后效果会更稳定，也更容易复用。
