我需要在我的 git 存储库中有版本文件。
当我们决定发布时,我有手动触发的发布过程(管道),这个过程应该做:
- 克隆回购
- 运行测试
- 计算新版本
- 用新版本更新版本文件
- 提交并推送新版本文件
- 使用新版本在 git 中创建标签/分支
现在,当我从这个标签进行克隆时,版本文件应该包含正确的版本。
如果在运行测试时 (#2) 其他人提交了对 repo 的更改,会发生什么情况,在 #6 中生成的标签是否还包含在发布过程中未测试的更改?
这个流程的逻辑是否正确,或者我有更好的方法来管理版本文件?
我需要在我的 git 存储库中有版本文件。
当我们决定发布时,我有手动触发的发布过程(管道),这个过程应该做:
现在,当我从这个标签进行克隆时,版本文件应该包含正确的版本。
如果在运行测试时 (#2) 其他人提交了对 repo 的更改,会发生什么情况,在 #6 中生成的标签是否还包含在发布过程中未测试的更改?
这个流程的逻辑是否正确,或者我有更好的方法来管理版本文件?
版本不是静态存储的,作为文件的新版本。
那是因为存储该文件的新修订的行为意味着...... Git 存储库本身有一个新的提交,需要获取,并迫使团队成员在新提交的基础上合并或重新调整他们自己的工作。
在构建交付物时,版本存储在构建时。
例如,在 Go 中,您将使用传递给 Go 链接器的标志来初始化字符串变量。
这样,在运行时,二进制文件不仅可以生成版本,还可以生成您选择记录的任何其他构建时间信息。
我通常以这种方式集成:
这样,您的程序可以显示有关其构建版本的大量信息。