如何使用Git实现数字版本控制方案？

#1 楼

使用标签来标记带有版本号的提交：

git tag -a v2.5 -m 'Version 2.5'

将标签向上推送-默认情况下未完成：

git push --tags

然后使用describe命令：

git describe --tags --long

这将为您提供以下格式的字符串：

v2.5-0-gdeadbee
^    ^ ^^
|    | ||
|    | |'-- SHA of HEAD (first seven chars)
|    | '-- "g" is for git
|    '---- number of commits since last tag
|
'--------- last tag

#2 楼

对我来说，这已经涉及了一些项目。到目前为止，我最好的解决方案是生成这样的版本号：

xy <提交数> .r

通常由我们的构建系统使用一些静态文件或标记的组合生成，以获取主要版本号git rev-list HEAD | wc -l（比使用git log更快）和git rev-parse HEAD。原因如下：


我们需要具有显式进行高层版本控制的功能（即iexy）
进行并行开发时，我们永远不需要生成相同的版本数字。
我们想轻松地跟踪版本的来源。
合并平行线时，我们希望新版本的解析度高于任何一个分支。

数字2对于大多数人来说是看不见的，但是它确实很重要，并且对于分布式源代码控制来说确实很困难。 SVN通过为您提供一个修订号来帮助您实现这一目标。事实证明，提交计数已尽可及，同时也神奇地解决了＃4。在存在分支的情况下，它仍然不是唯一的，在这种情况下，我们添加了哈希，它也巧妙地解决了＃3。

其中大部分是为了适应通过Python的pip进行部署。这保证了pip install在并行开发过程中可能会有些奇怪（即来自不同分支机构的人员的软件包会混合在一起，但以确定性的方式），但是合并后，一切都会整理出来。除非存在公开的rebase或amend，否则这对于上面的要求非常有效。

如果您想知道，由于有些奇怪，我们选择将r放在散列前面Python包装如何处理版本号中的字母（即ae小于0，这将使“ 1.3.10.a1234” <“ 1.3.10” <“ 1.3.10.1234”）。

评论

---

顺便说一句，您如何处理在签入之前确定git-hash的鸡肉问题？您是否使用了某种形式的.gitignore或其他技巧？

–kfmfe04
2012年11月16日23:58

---

我没有在签入后很长的程序包生成时间之前，我不会使用哈希。不同的语言有不同的注入方式。对于Python，我使用'./setup.py egg_info -b“。$ {BUILD_VERSION}” sdist'。对于C和C ++，我在编译时使用'CFLAGS = -D“ $ {BUILD_VERSION}”“定义了一个宏。对于Go，我在链接时使用'go install -ldflags appmodule.BuildVersion“ -X。$ {BUILD_VERSION}”“定义符号。

–杰森
2013年6月12日23:12

---

这应该是最好的答案。

–艾尔文纳巴德
18-09-5在23:46

---

很好的答案

– haelix
18/09/18在15:00

---

您如何处理被删除的分支。那数字不下来吗？

–马太
20/09/18'6:51

---

#3 楼

这可能有点矫kill过正，但我​​会让您知道我们如何做到。

我们使用的分支结构与此非常相似。

Hudson建立了我们的“ develop”分支，并从0开始递增构建号。
构建号为每个项目都唯一，并在版本控制中被标记。原因是这样，例如，您可以准确地分辨出哪个开发分支内部版本42来自（每个项目可以并行具有多个开发分支，因为每个项目可以有多个团队在项目的不同方面工作）。

当我们确定某个特定的内部版本足以发布时，触发该内部版本的提交将被标记有发行版本号，该版本号由行销决定。这意味着开发团队不在乎最终版本号是什么，市场营销部门可以自由选择合适的版本号。最终版本号和内部版本号都包含在已发布的产品中。

示例：2.1.0内部版本1337

这意味着对于特定的产品版本，您可以知道这是最后一个致力于此工作的团队，如果需要，您可以查询git以获得导致发布的所有提交以诊断问题。

#4 楼

在签入时，通过存储的目录树中所有文件的SHA1散列哈希来识别版本。此哈希值与父签入值的哈希值一起存储，以便可以读取完整的历史记录。

通过GIT-VERSION看一下使用'git-describe'的过程-GEN以及如何在标记发行版时通过构建过程添加它。

这里是一个不错的博客，提供了如何获取所需内容的示例：

http://cd34.com/blog/programming/using-git-to-generate-an-automatic-version-number/

#5 楼

乔恩·普迪（Jon Purdy）有正确的想法。 git flow也使这些分支的实际管理变得容易，而分支管理是转移到git的一个论据。

让我们从git的基本概况入手，因为您来自svn-到-git透视图。在git中考虑以下内容：上面，将master分支到develop（由\表示），并将develop分支到feature分支。我们将那些分支合并起来（由/表示），并沿着分支提交（-）。 （如果没有提交，但合并在右侧，则有.指示器显示下一个-是下一个提交。）

很容易。如果我们的主版本中有修复程序，该怎么办？

master--...............-.....-..............-
        \             /     /              /
         ---develop---------............../
                            \            /
                             --feature---

以上，develop从master分支而来。通过从master分支，修复并合并回到master中，修复了在master中发现的错误。然后，我们将master合并到develop中，然后将develop合并到feature2中，这会将来自hotfix的新代码滚动到这些分支中。

当您将feature2合并回develop时，其历史包括develop和hotfix。同样，将develop合并到feature2中，并使用来自master的新代码，因此将develop合并回master不会发生任何麻烦，因为它基于当时master中的提交，就像您当时从master分支一样。 br />
所以这是另一种方法。

master--...............-.....-................-...........-.........-
        \             /     /                / \         /|        /
         \           /     /                /   -hotfix-- V       /
          ---develop---------............../..............-...----
                             \            / \             V   /
                              --feature---   --feature2...----

您的1.0版本被标记了— 1.0.1，1.0.2，1.0.3等。
/>
现在这是一个窍门：您在1.0中发现了一个bug，它会影响1.1、1.2和1.3。你是做什么的？

您从最新或最早维护的版本中分支并对其进行修复。然后，将新的hotfix分支合并到1.3-并合并到1.2，1.1和1.0。不要从每个维护版本分支中分支；不要将1.0合并到master或将master合并回1.0。取一个hotfix分支并将其合并到所有版本分支中。如果有冲突，它将告诉您。查看您的代码以确保更改正确（git diff是您的朋友）。

现在，特定的更改将应用​​到所有地方。血统是分支的，但是还可以。这不是偶然的。将1.3头标记为1.3.17，将其合并到从1.3分支的每个进行中的功能中，然后继续。

git flow扩展名可以帮助您管理这些维护，功能和修补程序分支。一旦降低了工作流程，这将是微不足道的，并且会从源代码管理中消除大量麻烦。

我已经在编程团队中看到了这一点，但是我并没有像我自己是一名程序员，所以我仍然自己负责日常工作流程。

#6 楼

“关键字”扩展部分的第7.2节“ Git属性”中的Pro Git包含一个使用污迹和清除过滤器生成RCS样式关键字的好示例。您可以使用相同的技术将some-version-string嵌入代码中，并根据您的规则进行格式化和计算。您仍然可以使用git describe作为凝视点，但是您可以转换为任何更合适的形式并从v2.5-14-feebdaed中获取，例如，清理2.5.14