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打、切换、推送和删除的操作指南的详细内容，更多关于Git Tag打、切换、推送和删除的资料请关注脚本之家其它相关文章！