git中的tag与版本发布
前言
在我们的个人开发项目中, 往往会通过版本号来管理软件的发布。
比如对于go语言, 包的版本是通过Git标签(Git tags)来定义的。当你准备发布一个新版本时,你可以创建一个新的Git标签,并将这个标签推送到你的远程仓库。
而对于前端Js/Ts等领域, 除了通过Git标签(Git tags)来管理版本号外, 还需要使用npm来管理, 以便与npm的发布。
至于其它语言, 也都大同小异。
操作
基本步骤如下:
Make changes (做出改变)
Commit those changes (提交这些更改)
Make sure Travis turns green (确保测试通过)
如果你配置的有你所使用的测试框架的远程 ci 配置的话,就推送到仓库让其自动触发自动测试–直到通过。
若没有的话,就在本地手动执行你的测试脚本–直到通过。
总之,不论哪种,都需要保证测试通过。 因为我们’必须要保证’我们打 tag 的版本,‘必须、一定’是可用的。Bump version in package.json (在 package.json 对版本信息做相应的变更,一般与我们本次要打的 tag 的版本信息保持一致)
conventional-changelog (生成变更日志)
Commit package.json and CHANGELOG.md files (提交 package.json 和 CHANGELOG.md 文件)
因此,上述操作是为了确保打标签时的程序版本一定是可以正常使用的,以及确保我们的 Tag 版本变更这个 commit 中,只有这两种文件的新增 (即 CHANGELOG.md 和 package.json)–因为对于大型项目来说 package.json 文件是可能有多个的。
Tag (标签–这个时候我们就可以打上标签了,一般与 package.json 中的标签版本保持一致)
Push (推–推送到远端存储)
那么, 看基本的逻辑步骤并理解后, 你可以参考以下详细操作来尝试管理自己的项目发布。 当然,这是一种常见的工作流程,用于确保你的代码库中的每个版本都是可用的,并且有详细的变更日志。以下是每一步的详细操作指令:
做出改变:在你的本地环境中对代码进行修改。这可能涉及到添加新功能,修复错误,或者进行一些重构。
1
2# 使用你喜欢的编辑器打开文件并进行修改
vim your-file.js提交这些更改:一旦你对修改满意,你需要将这些更改提交到你的本地git仓库。
1
2
3
4
5# 添加所有修改过的文件到暂存区
git add .
# 提交这些更改,附带一条有意义的提交信息
git commit -m "Your meaningful commit message"确保测试通过:在提交更改之前,你需要确保所有的测试都能通过。这可以在你的本地环境中完成,也可以通过CI/CD工具(如Travis CI)在远程环境中完成。
1
2
3
4
5# 在本地运行测试
npm test
# 如果所有测试通过,那么就可以将更改推送到远程仓库
git push origin your-branch-name在 package.json 对版本信息做相应的变更:你需要更新
package.json
文件中的版本号,以反映出你即将发布的新版本。1
2# 使用npm命令更新版本号,这里的1.0.0应该替换为你的目标版本号
npm version 1.0.0生成变更日志:使用
conventional-changelog
工具生成变更日志。1
2# 生成变更日志
npx conventional-changelog -p angular -i CHANGELOG.md -s提交 package.json 和 CHANGELOG.md 文件:将这两个文件的更改提交到你的本地git仓库。
1
2
3
4
5# 添加这两个文件到暂存区
git add package.json CHANGELOG.md
# 提交这些更改,附带一条有意义的提交信息
git commit -m "chore(release): 1.0.0"打标签:在git中创建一个新的标签,以表示这个新的版本。
1
2# 创建一个新的标签,这里的1.0.0应该替换为你的目标版本号
git tag 1.0.0推送到远端存储:将你的更改(包括新的标签)推送到远程git仓库。
1
2
3
4
5# 推送你的更改到远程仓库
git push origin your-branch-name
# 推送你的标签到远程仓库
git push origin 1.0.0
以上就是每一步的详细操作指令,我再补充一些信息:
- 对于分支, 如果main采取强制性禁止推送的策略, 那么我们分支的操作按照pr逻辑来做就好, 但tag还是得在main分支来直接操作。
- 在远端合并pr的操作结束后, 再对本地main分支执行pull操作, 获取最新的带CHANGELOG.md的这次提交。
- 然后, 我们对对应的main本地分支进行打tag操作, 并推送到远程仓库。
- 那么说下原因
- Git标签(tags)不能通过Pull Request合并。标签和分支在Git中是不同的概念。分支通常用于开发新的特性或修复错误,而标签通常用于标记特定的提交,如发布的版本。
- 当你创建一个Pull Request时,你是请求将一个分支的更改合并到另一个分支。然而,标签并不包含任何更改,它只是一个指向特定提交的引用,所以它不能被合并。
- 如果你想在主分支上创建一个标签,你需要先切换到主分支,然后创建标签,最后推送标签到远程仓库。这个过程与你在其他分支上创建和推送标签的过程是一样的,只是你需要先切换到主分支。
- 在Git中,标签是全仓库唯一的。每个标签都对应一个特定的提交,而不是一个分支。因此,你不能在多个分支上使用同一个标签名。
- 当你创建一个标签时,Git会创建一个指向当前提交的引用。这个引用是全局的,它不属于任何特定的分支。因此,如果你试图在另一个分支上创建一个同名的标签,Git会认为你试图重定义这个标签,这通常是不被允许的。
- 如果你想在不同的分支上创建标签,你需要确保每个标签的名字都是唯一的。很少有人会这么做, 不过你可以通过在标签名中包含分支名或其他唯一的标识符来实现这一点。
- 如果你想删除一个标签,你可以使用
git tag -d
命令在本地删除标签,然后使用git push origin :refs/tags/<分支名>
命令在远程仓库删除标签。以下是具体的步骤:
在本地删除标签:在你的本地仓库中删除标签
1
2 # 在本地删除标签,这里的1.0.0应该替换为你的目标标签名
git tag -d 1.0.0在远程仓库删除标签:在你的远程仓库中删除标签
1
2 # 在远程仓库删除标签,这里的1.0.0应该替换为你的目标标签名
git push origin :refs/tags/1.0.0
重新打标签
1 | git tag -d <old-tag> |