有没有办法将 GitVersion 配置为使用缩短的（比如 6 个字符长）哈希作为版本编号？
即;
1.2.3-unstable645 Branch:'develop' Sha:'a682956dccae752aa24597a0f5cd939f93614509'
变成
1.2.3-unstable645 Branch:'develop' Sha:'a68295'
熵应该意味着额外的字符（过去，比如 6，带有1.6^10*7 排列）没有提供重要的标识，但如果需要显示，会使版本更短。
【问题讨论】：
标签： git semantic-versioning gitversion
熵应该意味着额外的字符（过去，比如 6，具有 1.6^10*7 排列）没有提供重要的标识，但如果需要显示，会使版本更短
不确定您的数学，但开发人员通常只使用 Git 哈希的前六位、八位或十二位数字作为标识符。对于任何给定的小型回购，冲突都不太可能发生，但definitely possible。我见过一些工具使用较短的版本仅用于显示目的，但在内部，它们使用完整的 40 个字符的哈希值。
如果您正在构建 SemVer 字符串，您可以将分支名称和提交哈希以缩短或完整形式嵌入：
1.2.3-unstable645+develop.a68295
我的偏好一直是使用完整的哈希：
1.2.3-unstable645+develop.a682956dccae752aa24597a0f5cd939f93614509
我也见过使用前六位和后六位数字的方案：
1.2.3-unstable645+develop.a68295-614509
回到你的数学问题... SHA-1 发出一个 160 位（20 字节）的哈希，需要 40 字节才能以十六进制完全显示。对于输入的每次变化，该算法相当擅长在所有 160 位上分配位变化。仅使用哈希中的 6 个字符意味着您只能获得 3 个字节（24 位）的哈希值，因此：
2^160 ~= 1.461502e+48
2^24 ~= 1.677722e+7
这是一个相当大的碰撞概率增加。
你真的需要多少位数？事实证明，这个数字取决于 your 存储库中的提交历史记录。 Git 命令具有允许您匹配最短匹配唯一前缀的功能，而不必指定整个哈希。在您的历史记录中只有一次提交，那么它可能是一个数字，但是提交堆积起来，这个数字总是会增加。一些高活跃度的 repo（例如 Linux 内核）需要至少 11 位数字来唯一标识它们包含的每个提交，但这个数字会随着时间的推移而继续增加。
所有这一切的主要内容是，那里的存储库将在其哈希的前 N 位中发生哈希冲突，其中 N
【讨论】：
GitVersion 发出断言版本号的许多不同部分，每个部分都可用于形成所需的版本号，但是，缩短的 sha 不是其中之一。以下是当前断言的所有变量：
{
"Major":0,
"Minor":21,
"Patch":0,
"PreReleaseTag":"",
"PreReleaseTagWithDash":"",
"PreReleaseLabel":"",
"PreReleaseNumber":"",
"BuildMetaData":"",
"BuildMetaDataPadded":"",
"FullBuildMetaData":"Branch.hotfix/0.21.1.Sha.57e16a787815c5e27c3a0edbf5224b3df64f1a69",
"MajorMinorPatch":"0.21.0",
"SemVer":"0.21.0",
"LegacySemVer":"0.21.0",
"LegacySemVerPadded":"0.21.0",
"AssemblySemVer":"0.21.0.0",
"FullSemVer":"0.21.0",
"InformationalVersion":"0.21.0+Branch.hotfix/0.21.1.Sha.57e16a787815c5e27c3a0edbf5224b3df64f1a69",
"BranchName":"hotfix/0.21.1",
"Sha":"57e16a787815c5e27c3a0edbf5224b3df64f1a69",
"NuGetVersionV2":"0.21.0",
"NuGetVersion":"0.21.0",
"CommitsSinceVersionSource":0,
"CommitsSinceVersionSourcePadded":"0000",
"CommitDate":"2017-07-14"
}
假设您使用某种形式的构建脚本，您可以手动缩短断言的 sha，然后将其与其他必需的变量组合以获得所需的版本号。
【讨论】：