gpt4 book ai didi

git - 如何在 Git 中管理版本号?

转载 作者:IT王子 更新时间:2023-10-29 01:18:17 26 4
gpt4 key购买 nike

让我们想象一下 blerp命令行工具维护于 .此工具具有( stash 的)--version 选项,该选项返回其 version (比方说 0.1.2)和另一个 --commit,它返回构建它的提交编号。

版本和提交号都硬编码在代码库中。

现在我修复了一个错误,然后提交并重建我的程序。我仍然会看到 0.1.2,尽管这个新版本与原来的 0.1.2 不同。只有提交会告诉我它不是同一个 0.1.2。该错误修复值得不同的版本号吗?

一个解决方案是,每次提交时,我都会增加硬编码版本号(这意味着每次提交总是至少修改 2 个文件)。这是一个绑定(bind)解决方案,当开发人员在不同的事件分支上工作时它不起作用。如果 Bob 使用 0.1.2 版本的功能 foo,而 Alice 使用相同版本的功能 bar,他们如何增加版本数字? Bob 可以使用奇数,Alice 使用偶数。如果 Eve 开发第三个功能怎么办?

另一种解决方案是使用 Git 标签自动生成版本号。脚本可以找到最接近的以v开头的标签,例如v0.1.2,并使用标签名称作为版本号加上当前提交的前n位数字(v0.1.2(构建 4acd21))。如果工作目录是干净的,这很有效。可以想象在内部版本号之前添加一个 * 以指示工作目录不干净。此解决方案的主要问题是,如果有人导出源代码,它将无法构建 blerp

有什么可能的替代方案可以解决这个问题?

最佳答案

Alexey KiselevDario 已经暗示了答案,但我会尝试详细解释。

版本控制

有两种版本控制方案:

  1. 内部版本号:这可以在一天内递增多次(例如修订控制号)
  2. 发布版本:更改频率较低(例如语义版本控制)

人们根据需要使用 different schemes,但 semantic versioning 的使用相当广泛,并且由 GitHub 的联合创始人 Tom Preston-Werner 编写。

语义版本控制

语义版本控制遵循 X.Y.Z

的模式

或者更具可读性的是[major].[minor].[patch]-[build/beta/rc]

例如1.2.0-beta

major 或 X 如果软件有重大变化,例如向后不兼容的 API 版本,则可以递增。

如果引入向后兼容的 API,

minor 或 Y 会递增。

补丁或 Z 在错误修复后递增。

我们如何使用 Git 实现这一点?

通过使用标签:

Git 中的标签可用于添加版本号。

git tag -a "v1.5.0-beta" -m "version v1.5.0-beta"

将 v1.5.0-beta 的版本标记添加到您当前的 Git 存储库。此后的每个新提交都将通过附加提交编号和提交哈希来自动递增标记。这可以使用 git describe 命令查看。

v1.5.0-beta-1-g0c4f33f 这里的-1-是commit number,0c4f33f是commit's hash的缩写。 g 前缀代表 “git”

可以使用以下方式查看完整的详细信息:

git show v1.5.0-beta

关于git - 如何在 Git 中管理版本号?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37814286/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com