git Git如何管理版本号？

How to manage the version number in Git?

提问by nowox

Let's imagine the blerpcommand line tool maintained on git. This tool has the (hidden) --versionoption which returns its version(let's say 0.1.2) and another --commitwhich returns the commit number from which it was built.

让我们想象一下在git 上维护的blerp命令行工具。这个工具有一个（隐藏）选项，它返回它的版本（比方说），另一个返回它构建时的提交号。--version0.1.2--commit

Both the version and the commit number are hard-coded on the code base.

版本和提交号都是在代码库上硬编码的。

Now I make a bugfix then commit and rebuild my program. I will still see 0.1.2although this new version differ from the original 0.1.2. Only the commit will tell me that it is not the same 0.1.2. Is that bugfix worth a different version number?

现在我做了一个错误修正，然后提交并重建我的程序。0.1.2尽管这个新版本与原始 0.1.2 不同，但我仍然会看到。只有提交会告诉我它与 0.1.2 不同。那个错误修复值得不同的版本号吗？

One solution is that each time a make a commit, I increase the hard-coded version number (which implies to always modify a minimum of 2 files for each commit). This is a binding solution and it does not work when the developers are working on different active branches. If Bob works on feature foofrom the version 0.1.2and Alice works on feature barfrom the same version. How do they increase their version number? Bob can use the odd and Alice the even. What if Eve works on a third feature?

一种解决方案是，每次提交时，我都会增加硬编码版本号（这意味着每次提交至少要修改 2 个文件）。这是一个绑定解决方案，当开发人员在不同的活动分支上工作时它不起作用。如果 Bobfoo处理版本中的功能，0.1.2而 Alicebar处理相同版本中的功能。他们如何增加他们的版本号？Bob 可以使用奇数，Alice 可以使用偶数。如果 Eve 从事第三个功能会怎样？

Another solution can be to use the Git tags to automatically generate the version number. A script can find the closest tag starting with vsuch as v0.1.2and use the tag name as the version number plus the first n digits of the current commit (v0.1.2 (build 4acd21)). This works well if the working directory is clean. One can imagine to add a *before the build number to indicate the working directory is not clean. The main problem with this solution is if somebody export the sources, it won't be able to build blerp.

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

What possible alternative can solve this issue?

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

回答by aaryan

Alexey Kiselev and Dario already hinted towards the answer, but I will try to explain it in detail.

Alexey Kiselev 和 Dario 已经暗示了答案，但我将尝试详细解释。

Versioning Schemes

版本控制方案

There are two types of versioning schemes:

有两种类型的版本控制方案：

1. Internal version number: This can be incremented many times in a day (e.g. revision control number)
2. Released version: This changes less often (e.g. semantic versioning)

1. 内部版本号：这可以在一天内增加多次（例如修订控制号）
2. 已发布版本：此更改较少（例如语义版本控制）

People use different schemesas per their need, but semantic versioningis fairly widely used and authored by Tom Preston-Werner, co-founder of GitHub.

人们根据自己的需要使用不同的方案，但语义版本控制得到了相当广泛的使用，由 GitHub 的联合创始人 Tom Preston-Werner 撰写。

Semantic Versioning

语义版本控制

Semantic versioning follows the pattern of X.Y.Z

语义版本控制遵循以下模式 X.Y.Z

Or more readable would be [major].[minor].[patch]-[build/beta/rc]

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

E.g. 1.2.0-beta

例如 1.2.0-beta

major or Xcan be incremented if there are major changes in software, like backward-incompatible API release.

major or X如果软件发生重大变化，例如向后不兼容的 API 版本，则可以增加。

minor or Yis incremented if backward compatible APIs are introduced.

minor or Y如果引入了向后兼容的 API，则递增。

patch or Zis incremented after a bug fix.

patch or Z在错误修复后增加。

How do we achieve this using Git?

我们如何使用 Git 实现这一目标？

By using tags:

通过使用标签：

Tags in Git can be used to add a version number.

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

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

adds a version tag of v1.5.0-beta to your current Git repository. Every new commit after this will auto-increment tag by appending commit number and commit hash. This can be viewed using the git describecommand.

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

v1.5.0-beta-1-g0c4f33fhere -1-is the commit number and 0c4f33fthe abbreviation of commit's hash. The gprefix stands for "git".

v1.5.0-beta-1-g0c4f33f这-1-是提交编号和0c4f33f提交哈希的缩写。该g前缀代表"git"。

Complete details can be viewed using:

可以使用以下方法查看完整的详细信息：

git show v1.0.5-beta

git show v1.0.5-beta

回答by Alexey Kiselev

Please, have a look at git describecommand. This command shows you the latest tag and an amount of commits made after the tag was set. It also possible to show the dirtiness of the repository.

请看一下git describe命令。此命令向您显示最新标签以及在设置标签后所做的提交量。还可以显示存储库的肮脏程度。

As you mentioned this command wouldn't work without the git repository (.git folder) and git installed. But it's almost unimaginable developer today without git but with all other tools installed.

正如您所提到的，如果没有 git 存储库（.git 文件夹）和 git 安装，此命令将无法工作。但是今天没有 git 但安装了所有其他工具的开发人员几乎是不可想象的。

回答by Dario

As you say, versioning issues are usually solved in git using branchand tags(like semantic versioningpattern).

正如您所说，版本控制问题通常在 git 中使用branchand解决tags（如语义版本控制模式）。

The better way is to use gitto track only changes in the codebase, ignoring (using .gitignorefile) builds files and maintaining a clean repository.

更好的方法是使用git仅跟踪代码库中的更改，忽略（使用.gitignore文件）构建文件并维护干净的存储库。

Builds results (pre/compiled files, executables files, distribution files, zips, exe...) could depend of environments variables (platform, system arch, etc) and should be keep separate in a registry.

构建结果（预/编译文件、可执行文件、分发文件、zip、exe...）可能取决于环境变量（平台、系统架构等），并且应该在注册表中分开保存。

If the codebase very big and hard to maintain, maybe you should considerate to divide it in smaller components (or git submodule) to avoid cross-dependencies at development time.

如果代码库非常大且难以维护，也许您应该考虑将其划分为较小的组件（或git submodule）以避免开发时的交叉依赖。

回答by everton

Revision numbers should be maintained by you, not by git. As, opposed to SVN, you don't have a incremental revision number growing on each commit, there's no way out of the box to git to contextualize what your version is.

修订号应该由你维护，而不是由 git 维护。与 SVN 不同的是，每次提交时您都没有递增的修订号，因此 git 无法开箱即用地将您的版本置于上下文中。