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打、切换、推送和删除的资料请关注脚本之家其它相关文章!
相关文章
反向传播BP学习算法Gradient Descent的推导过程
这篇文章主要为大家介绍了反向传播BP学习算法-Gradient Descent的推导过程,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪2022-05-05
如何解决Git推送错误:Updates were rejected问题
在使用Git推送更改时,可能会遇到"Updates were rejected"错误,这通常是由于远程仓库包含了本地不存在的更新,解决这一问题的步骤包括拉取远程更改、解决冲突、提交更改及再次尝试推送,遵循正确的步骤可以有效解决冲突,保持代码库的一致性2024-10-10
抓包工具Fiddler的使用方法详解(Fiddler中文教程)
本文详细说明了抓包工具Fiddler的使用方法与各个面板的功能介绍 每个按钮都说明了他的功能,完全可以当作Fiddler的中文教程了2018-10-10


最新评论