版本的故事（二）版本的诞生

研发人员不断修改代码，在代码库上形成一个 Commit 链条，每一个 Commit 记录了所有文件在某一时刻的状态，这个状态称为一个“快照”。在所有提交中，我们认为其中一些提交具有特殊的意义，比如我们完成了里程碑任务，这时可以发布版本了。对于这些特殊的提交，我们创建一个标签（Tag）与之关联。这个标签，我们称之为“基线”。创建标签的工作，我们称之为“基线化”。

代码基线标志着版本的诞生，代码基线就是这个版本的“出生证”。发布版本的时候必须创建 Tag，我们用 Tag 名称作为版本号，编译构建的时候把版本号烙印在发布包的某个地方（最容易辨认的地方就是文件名）。以后无论这个二进制包走到哪里，无论经过多少年，我们都可以根据它的名称知道它的版本号，根据版本号找到这张出生证，知道这个版本的来历，查阅它的身世家谱。版本一旦发布，这个出生证就是不能变更的，既不能修改，也不能删除。否则版本就会成为一个没有身份、来历不明的可疑分子。

我们必须在出生证上写些什么，创建 Tag 的时候可以加一句注释：

# 切换到主分支，我们一般在主分支发布版本
$ git checkout master

# 创建标签，记录标签信息
$ git tag -a 1.0.0 -m "完成云主机维护功能发布测试版"

使用 Github、GitLab 这样的代码管理平台，我们可以在页面上记录更多的信息。以下是在 GitLab 平台创建 Tag 的界面，可以为这个 Tag 编写一个完整的说明，记叙发布目的、完成功能、修复缺陷、遗留问题，还可以使用 Markdown 语法：

这样一来，这张”出生证“的信息就更加完整了。

现在这个版本有了“出生证”，随着工作的推进，它还需要有另一些证：

1. 如果它通过了测试证明是一个合格的版本，要发一个“合格证”；
2. 它和它的朋友们组成一个集体，通过集成测试，成为一个“产品”，要发一个“毕业证”；
3. 运维把它拿到环境上部署，要发一个“上岗证”。

后面会写一系列的文章说明这些“证”的作用和内容。但是在这之前，我们先要说一说“版本号”是个什么概念，怎样给版本起一个既好听、又有意义的名字。