我们如何进行版本控制？
我们有一个基于NetBeans平台的SDK发行版。由于SVN修订版是简单的数字，因此我们可以使用它们来扩展我们的插件和SDK构建的版本号。
可能的解决方案：
使用Hudson的内部版本号（问题：您必须检查Hudson才能进行关联到实际的Git版本）
手动升级该版本以实现夜间稳定运行（问题：学习曲线，人为错误）
如果其他人遇到了类似的问题并解决了问题，我们d喜欢听听。
#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
评论
同意-如果需要的话，应该很容易实现夜间标签编号的自动化，无论如何，要手动升级到稳定版本是可行的。
–没用
2012年3月28日19:00
小改进：git describe --long --tags --dirty --always。 “ dirty”会告诉您“ describe”完成后是否发生了局部更改（这意味着它无法完全描述存储库的状态）。 “始终”表示没有标签时也不会出错。它将回退到仅提交哈希。因此，您可以获取76001f2-dirty作为示例。显然，看到“肮脏”意味着有人搞砸了。
–麦克·韦勒
2013年3月14日13:00
最后生成标签时如何工作。通常，您希望以后的版本具有产品的下一版本。但是在这种情况下，他们将始终被迫使用最新版本。只有最终交付的内部版本具有正确的编号。
–void.pointer
15年8月20日在21:34
@ void.pointer：当然，此版本号回答了以下问题：“此提交基于哪个版本？”不是“此提交将在哪个版本中？”但是，您可以自由地解释标签。例如，如果将HEAD标记为v2.5，则可以将其解释为2.5发行周期的开始，然后标记v2.5-release或任何您喜欢的名称。
–琼·普迪（Jon Purdy）
15年8月20日在22:44
另一个小改进。如果您还希望拥有其他标签，但使用特定模式的标签进行修订生成，则可以使用--match选项，如下所示：git describe --long --tags --dirty --always --match'v [0-9] \。[0-9]'
–亚历山大·阿梅尔金（Alexander Amelkin）
16年6月27日在15:13
#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 评论
-1完全不叫作ad hominem攻击而破坏了一个好的答案。
–Jörg W Mittag
2012年3月29日，0：52
谁说这是混血男孩投票赞成你。可能容易有人喜欢一点礼貌。
– Mark Booth
2012年3月29日在18:19
仅供参考，我刚刚编辑了答案。
–基思·汤普森（Keith Thompson）
2012年6月5日在2:38
git describe输出标签名，除非传递了--long或自最后一个标签以来已有提交，所以已经很干净了。如果您不更改默认值，它将完全满足您的要求。
– strcat
2015年1月25日在4:36
评论
您能否让hudson（不是jenkins？）服务器在每次成功构建后自动添加git标签？这将具有额外的优势，因为它可以使未进行标记的git commit确实存在构建问题或测试失败，因此可以很清楚地清除它们。参见stackoverflow.com/questions/677436/…
附带说明，您可以通过跟踪构建时间将构建计数添加到标签中。
不确定是否可行，但是在每次构建之前从git导出到svn repo怎么样？然后只需从svn存储库中进行构建-如果我们需要集中式存储，请改用它。