让我们想象在blerp上维护git命令行工具。此工具具有（隐藏的）--version选项，该选项返回其version（让我们说0.1.2）和另一个--commit，它返回它的提交编号建成。
版本和提交号都在代码库上进行了硬编码。
现在我制作一个错误修正，然后提交并重建我的程序。我仍然会看到0.1.2，尽管这个新版本与原来的0.1.2不同。只有提交会告诉我它不一样0.1.2。这个bugfix值得一个不同的版本号吗？
一个解决方案是每次提交时，我都会增加硬编码版本号（这意味着每次提交时总是修改最少2个文件）。这是一个绑定解决方案，当开发人员处理不同的活动分支时，它不起作用。如果Bob使用版本foo中的功能0.1.2，则Alice会使用相同版本的功能bar。他们如何增加版本号？ Bob可以使用奇数和Alice使用偶数。如果Eve在第三个功能上工作怎么办？
另一种解决方案是使用Git标签自动生成版本号。脚本可以找到以v开头的最接近的标记，例如v0.1.2，并使用标记名称作为版本号加上当前提交的前n位数（v0.1.2 (build 4acd21)）。如果工作目录是干净的，这很有效。可以想象在构建号之前添加*以指示工作目录不干净。此解决方案的主要问题是，如果有人导出源，则无法构建 blerp 。
有哪些替代方案可以解决这个问题？
答案 0 :(得分：28)
Alexey Kiselev和Dario已经暗示了答案，但我会尝试详细解释。
版本控制方案有两种类型：
人们根据需要使用different schemes，但semantic versioning被GitHub的共同创始人Tom Preston-Werner广泛使用和撰写。
语义版本控制遵循X.Y.Z
或更具可读性[major].[minor].[patch]-[build/beta/rc]
E.g。 1.2.0-beta
major or X可以递增。
minor or Y会递增。
patch or Z会增加。
使用标签：
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-是提交号，0c4f33f是提交哈希的缩写。 g前缀代表"git"。
可以使用以下方式查看完整的详细信息：
git show v1.0.5-beta
答案 1 :(得分：12)
请看一下git describe命令。此命令显示标记设置后的最新标记和提交量。它也可以显示存储库的肮脏。
正如您所提到的，如果没有安装git存储库（.git文件夹）和git，此命令将无法正常工作。但是，如果没有git，安装所有其他工具，那么今天几乎是不可想象的开发人员。
答案 2 :(得分：3)
正如您所说，版本控制问题通常使用branch和tags（如semantic versioning模式）在git中解决。
更好的方法是使用git仅跟踪代码库中的更改，忽略（使用.gitignore文件）构建文件并维护一个干净的存储库。
构建结果（预编译/编译文件，可执行文件，分发文件，拉链，exe ... ）可能依赖于环境变量（平台，系统拱等），并且应该保持独立注册表。
如果代码库非常庞大且难以维护，也许您应该考虑将其划分为较小的组件（或git submodule），以避免在开发时出现交叉依赖。
答案 3 :(得分：3)
修订号应由您维护，而不是由git维护。因为，与SVN相反，您在每次提交时都没有增加的修订版号，没有开箱即用的方法可以对您的版本进行上下文化。
答案 4 :(得分：1)
在项目目录（或您想要的位置）build_number 中创建文件并将其值 1 放在此文件中
转到 git dir 并在 .git/hooks/（不带 .sample）中创建名为“pre-commit”的文件
把这段代码放在那里
#!/bin/sh
currentbuildnumber=cat build_number 让 "currentbuildnumber++"
printf $currentbuildnumber > build_number currentbranch=git branch | tr -cd "[:alpha:]" git log $currentbranch --pretty=format:"%h - %an,
%ar : %s, Build: $currentbuildnumber"
为我工作:) 享受！