修订号的 Git 等价物是什么？

What is the Git equivalent for revision number?

提问by Radek

We use SVN at work, but for my personal projects I decided to use Git. So I installed Git yesterday, and I wonder what is the revision numberequivalent in Git.

我们在工作中使用 SVN，但对于我的个人项目，我决定使用 Git。所以我昨天安装了 Git，我想知道Git 中等效的修订号是多少。

Let's say we work on version 3.0.8 and every bug fix has its own revision number we can use when we talk about this bug fix. So if I tag the code in Git to 3.0.8 what then I can use as a revision number or some other more detailed kind of identification? I find the hash not so user friendly for humans.

假设我们在 3.0.8 版本上工作，并且每个错误修复都有自己的修订号，我们可以在谈论此错误修复时使用它。因此，如果我将 Git 中的代码标记为 3.0.8，那么我可以将其用作修订号或其他一些更详细的标识？我发现哈希对人类来说不太友好。

采纳答案by makdad

Good or bad news for you, that hash IS the revision number. I also had trouble with this when I made the switch from SVN to git.

对您来说是好消息还是坏消息，散列是修订号。当我从 SVN 切换到 git 时，我也遇到了这个问题。

You can use "tagging" in git to tag a certain revision as the "release" for a specific version, making it easy to refer to that revision. Check out this blog post.

您可以在 git 中使用“标记”将某个修订标记为特定版本的“发布”，以便于引用该修订。看看这篇博文。

The key thing to understand is that git cannot have revision numbers - think about the decentralized nature. If users A and B are both committing to their local repositories, how can git reasonably assign a sequential revision number? A has no knowledge of B before they push/pull each other's changes.

要理解的关键是 git 不能有修订号 - 考虑分散的性质。如果用户 A 和 B 都提交到他们的本地存储库，git 如何合理分配顺序修订号？A 在推/拉彼此的更改之前不知道 B。

Another thing to look at is simplified branching for bugfix branches:

另一件要注意的事情是错误修复分支的简化分支：

Start with a release: 3.0.8. Then, after that release, do this:

从一个版本开始：3.0.8。然后，在发布之后，执行以下操作：

git branch bugfixes308

This will create a branch for bugfixes. Checkout the branch:

这将为错误修正创建一个分支。结帐分支：

git checkout bugfixes308

Now make any bugfix changes you want.

现在进行任何您想要的错误修复更改。

git commit -a

Commit them, and switch back to the master branch:

提交它们，然后切换回 master 分支：

git checkout master

Then pull in those changes from the other branch:

然后从另一个分支中提取这些更改：

git merge bugfixes308

That way, you have a separate release-specific bugfix branch, but you're still pulling the bugfix changes into your main dev trunk.

这样，您就有了一个单独的特定于版本的错误修复分支，但您仍然将错误修复更改拉入主开发主干。

回答by max

With modern Git (1.8.3.4 in my case) and not using branches you can do:

使用现代 Git（在我的情况下为 1.8.3.4）并且不使用分支，您可以执行以下操作：

$ git rev-list --count HEAD
68

回答by Greg Hewgill

The git describecommand creates a slightly more human readable name that refers to a specific commit. For example, from the documentation:

该git describe命令创建了一个稍微更易读的名称，用于引用特定的提交。例如，从文档：

With something like git.git current tree, I get:

[torvalds@g5 git]$ git describe parent
v1.0.4-14-g2414721

i.e. the current head of my "parent" branch is based on v1.0.4, but since it has a few commits on top of that, describe has added the number of additional commits ("14") and an abbreviated object name for the commit itself ("2414721") at the end.

使用 git.git current tree 之类的东西，我得到：

[torvalds@g5 git]$ git describe parent
v1.0.4-14-g2414721

即我的“父”分支的当前负责人基于 v1.0.4，但由于它在此之上有一些提交，describe 添加了额外提交的数量（“14”）和提交的缩写对象名称本身（“2414721”）在最后。

As long as you use sensibly named tags to tag particular releases, this can be considered to be roughly equivalent to a SVN "revision number".

只要您使用合理命名的标签来标记特定版本，就可以认为这大致相当于 SVN 的“修订号”。

回答by OderWat

The other posters are right, there is no "revision-number".

其他海报是对的，没有“修订号”。

I think the best way is to use Tags for "releases"!

我认为最好的方法是使用标签进行“发布”！

But I made use of the following to fake revision numbers(just for clients to see revisions and the progress, as they wanted to have the same increasing revisions from git as they where use to by subversion).

但是我使用以下内容来伪造修订号（仅供客户查看修订和进度，因为他们希望从 git 中获得与 subversion 所使用的相同的增加修订）。

Show the "current revision" of "HEAD" is simulated by using this:

显示“HEAD”的“当前版本”是通过使用这个来模拟的：

git rev-list HEAD | wc -l

git rev-list HEAD | wc -l

But what if the client tells me that there is a bug in "revision" 1302 ?

但是，如果客户告诉我“修订版” 1302 中存在错误怎么办？

For this I added the following to the [alias] section of my ~/.gitconfig:

为此，我在 ~/.gitconfig 的 [alias] 部分添加了以下内容：

show-rev-number = !sh -c 'git rev-list --reverse HEAD | nl | awk \"{ if(\\$1 == "$0") { print \\$2 }}\"'

show-rev-number = !sh -c 'git rev-list --reverse HEAD | nl | awk \"{ if(\\$1 == "$0") { print \\$2 }}\"'

using git show-rev-number 1302will then print the hashfor the "revision" :)

git show-rev-number 1302然后使用将打印“修订版”的哈希值:)

I made a Blog Post (in german)about that "technique" some time ago.

前段时间我发表了一篇关于该“技术”的博客文章（德语）。

回答by I GIVE CRAP ANSWERS

Git does not have the same concept of revision numbers as subversion. Instead each given snapshot made with a commit is tagged by a SHA1 checksum. Why? There are several problems with a running revno in a distributed version control system:

Git 没有与 subversion 相同的修订号概念。相反，通过提交制作的每个给定快照都由 SHA1 校验和标记。为什么？在分布式版本控制系统中运行revno有几个问题：

First, since development is not linear at all, the attachment of a number is rather hard as a problem to solve in a way which will satisfy your need as a programmer. Trying to fix this by adding a number might quickly become problematic when the number does not behave as you expect.

首先，由于开发根本不是线性的，因此作为一个能够满足您作为程序员需求的方式来解决数字附加问题是相当困难的。尝试通过添加数字来解决此问题可能会很快成为问题，因为该数字的行为与您预期的不一样。

Second, revision numbers may be generated on different machines. This makes synchronization of numbers much harder - especially since connectivity is one-way; you may not even have access to all machines that has the repository.

其次，修订号可能会在不同的机器上生成。这使得数字同步变得更加困难——尤其是因为连接是单向的；您甚至可能无法访问所有具有存储库的机器。

Third, in git, somewhat pioneered by the now defunct OpenCM system, the identityof a commit (what the commit is) is equivalent to its name(the SHA id). This naming = identityconcept is very strong. When you sit with a commit name in hand it also identifies the commit in an unforgeable way. This in turn lets you check all of your commits back to the first initial onefor corruption with the git fsckcommand.

第三，在 git 中，有些是由现已解散的 OpenCM 系统开创的，提交的身份（提交是什么）等同于它的名称（SHA id）。这个命名=身份的概念非常强。当你拿着一个提交名称坐在那里时，它也会以一种不可伪造的方式识别提交。这反过来又可以让您检查所有提交回到第一个初始提交是否使用git fsck命令损坏。

Now, since we have a DAG (Directed Acyclic Graph) of revisions and these constitute the current tree, we need some tools to solve yourproblem: How do we discriminate different versions. First, you can omit part of the hash if a given prefix, 1516bdsay, uniquely identifies your commit. But this is also rather contrived. Instead, the trick is to use tags and or branches. A tag or branch is akin to a "yellow stick it note" you attach to a given commit SHA1-id. Tags are, in essence, meant to be non-moving whereas a branch will move when new commits are made to its HEAD. There are ways to refer to a commit around a tag or branch, see the man page of git-rev-parse.

现在，由于我们有一个 DAG（有向无环图）修订版，这些构成了当前树，我们需要一些工具来解决您的问题：我们如何区分不同的版本。首先，如果给定的前缀1516bd唯一标识您的提交，则您可以省略散列的一部分。但这也是相当人为的。相反，诀窍是使用标签和/或分支。标签或分支类似于您附加到给定提交 SHA1-id 的“黄色便笺”。标签本质上是不移动的，而当对其 HEAD 进行新提交时，分支将移动。有多种方法可以引用标记或分支周围的提交，请参阅 git-rev-parse 的手册页。

Usually, if you need to work on a specific piece of code, that piece is undergoing changesand should as such be a branch with a saying topic name. Creating lots of branches (20-30 per programmer is not unheard of, with some 4-5 published for others to work on) is the trick for effective git. Every piece of work should start as its own branch and then be merged in when it is tested. Unpublished branches can be rewritten entirely and this part of destroying history is a force of git.

通常，如果你需要处理一段特定的代码，那段代码正在发生变化，因此应该是一个带有主题名称的分支。创建大量分支（每个程序员 20-30 个分支并非闻所未闻，其中 4-5 个发布给其他人使用）是有效 git 的诀窍。每一项工作都应该作为自己的分支开始，然后在测试时合并。未发布的分支可以完全重写，这部分破坏历史是 git 的力量。

When the change is accepted into masterit somewhat freezes and becomes archeology. At that point, you can tag it, but more often a reference to the particular commit is made in a bug tracker or issue tracker via the sha1 sum. Tags tend to be reserved for version bumps and branch points for maintenance branches (for old versions).

当这种变化被接受为大师时，它有点冻结并成为考古学。在这一点上，您可以标记它，但更常见的是在错误跟踪器或问题跟踪器中通过 sha1 sum 对特定提交进行引用。标签往往是为版本颠簸和维护分支（旧版本）的分支点保留的。

回答by Sebastien Varrette

If you're interested, I managed version numbers automatically from git infos hereunder the format

如果你有兴趣，我从这里的git infos格式中自动管理版本号

<major>.<minor>.<patch>-b<build>

where build is the total number of commits. You'll see the interesting code in the Makefile. Here is the relevant part to access the different part of the version number:

其中 build 是提交的总数。您将在Makefile. 这是访问版本号不同部分的相关部分：

LAST_TAG_COMMIT = $(shell git rev-list --tags --max-count=1)
LAST_TAG = $(shell git describe --tags $(LAST_TAG_COMMIT) )
TAG_PREFIX = "latex-tutorial-v"

VERSION  = $(shell head VERSION)
# OR try to guess directly from the last git tag
#VERSION    = $(shell  git describe --tags $(LAST_TAG_COMMIT) | sed "s/^$(TAG_PREFIX)//")
MAJOR      = $(shell echo $(VERSION) | sed "s/^\([0-9]*\).*//")
MINOR      = $(shell echo $(VERSION) | sed "s/[0-9]*\.\([0-9]*\).*//")
PATCH      = $(shell echo $(VERSION) | sed "s/[0-9]*\.[0-9]*\.\([0-9]*\).*//")
# total number of commits       
BUILD      = $(shell git log --oneline | wc -l | sed -e "s/[ \t]*//g")

#REVISION   = $(shell git rev-list $(LAST_TAG).. --count)
#ROOTDIR    = $(shell git rev-parse --show-toplevel)
NEXT_MAJOR_VERSION = $(shell expr $(MAJOR) + 1).0.0-b$(BUILD)
NEXT_MINOR_VERSION = $(MAJOR).$(shell expr $(MINOR) + 1).0-b$(BUILD)
NEXT_PATCH_VERSION = $(MAJOR).$(MINOR).$(shell expr $(PATCH) + 1)-b$(BUILD)

回答by siznax

A Bash function:

一个 Bash 函数：

git_rev ()
{
    d=`date +%Y%m%d`
    c=`git rev-list --full-history --all --abbrev-commit | wc -l | sed -e 's/^ *//'`
    h=`git rev-list --full-history --all --abbrev-commit | head -1`
    echo ${c}:${h}:${d}
}

outputs something like

输出类似

$ git_rev
2:0f8e14e:20130220

That is

那是

commit_count:last_abbrev_commit:date_YYmmdd

回答by Richard Fearn

The SHA1 hash of the commitis the equivalent to a Subversion revision number.

提交的SHA1 哈希等效于 Subversion 修订号。

回答by Ralph Williamson

This is what I did in my makefile based on others solutions. Note not only does this give your code a revision number, it also appends the hash which allows you to recreate the release.

这是我根据其他解决方案在我的 makefile 中所做的。请注意，这不仅为您的代码提供了修订号，而且还附加了允许您重新创建版本的哈希值。

# Set the source control revision similar to subversion to use in 'c'
# files as a define.
# You must build in the master branch otherwise the build branch will
# be prepended to the revision and/or "dirty" appended. This is to
# clearly ID developer builds.
REPO_REVISION_:=$(shell git rev-list HEAD --count)
BUILD_BRANCH:=$(shell git rev-parse --abbrev-ref HEAD)
BUILD_REV_ID:=$(shell git rev-parse HEAD)
BUILD_REV_ID_SHORT:=$(shell git describe --long --tags --dirty --always)
ifeq ($(BUILD_BRANCH), master)
REPO_REVISION:=$(REPO_REVISION_)_g$(BUILD_REV_ID_SHORT)
else
REPO_REVISION:=$(BUILD_BRANCH)_$(REPO_REVISION_)_r$(BUILD_REV_ID_SHORT)
endif
export REPO_REVISION
export BUILD_BRANCH
export BUILD_REV_ID

回答by toeb

I wrote some PowerShell utilities for retrieving version information from Git and simplifying tagging

我编写了一些 PowerShell 实用程序，用于从 Git 检索版本信息并简化标记

functions: Get-LastVersion, Get-Revision, Get-NextMajorVersion, Get-NextMinorVersion, TagNextMajorVersion, TagNextMinorVersion:

函数：Get-LastVersion、Get-Revision、Get-NextMajorVersion、Get-NextMinorVersion、TagNextMajorVersion、TagNextMinorVersion：

# Returns the last version by analysing existing tags,
# assumes an initial tag is present, and
# assumes tags are named v{major}.{minor}.[{revision}]
#
function Get-LastVersion(){
  $lastTagCommit = git rev-list --tags --max-count=1
  $lastTag = git describe --tags $lastTagCommit
  $tagPrefix = "v"
  $versionString = $lastTag -replace "$tagPrefix", ""
  Write-Host -NoNewline "last tagged commit "
  Write-Host -NoNewline -ForegroundColor "yellow" $lastTag
  Write-Host -NoNewline " revision "
  Write-Host -ForegroundColor "yellow" "$lastTagCommit"
  [reflection.assembly]::LoadWithPartialName("System.Version")

  $version = New-Object System.Version($versionString)
  return $version;
}

# Returns current revision by counting the number of commits to HEAD
function Get-Revision(){
   $lastTagCommit = git rev-list HEAD
   $revs  = git rev-list $lastTagCommit |  Measure-Object -Line
   return $revs.Lines
}

# Returns the next major version {major}.{minor}.{revision}
function Get-NextMajorVersion(){
    $version = Get-LastVersion;
    [reflection.assembly]::LoadWithPartialName("System.Version")
    [int] $major = $version.Major+1;
    $rev = Get-Revision
    $nextMajor = New-Object System.Version($major, 0, $rev);
    return $nextMajor;
}

# Returns the next minor version {major}.{minor}.{revision}
function Get-NextMinorVersion(){
    $version = Get-LastVersion;
    [reflection.assembly]::LoadWithPartialName("System.Version")
    [int] $minor = $version.Minor+1;
    $rev = Get-Revision
    $next = New-Object System.Version($version.Major, $minor, $rev);
    return $next;
}

# Creates a tag with the next minor version
function TagNextMinorVersion($tagMessage){
    $version = Get-NextMinorVersion;
    $tagName = "v{0}" -f "$version".Trim();
    Write-Host -NoNewline "Tagging next minor version to ";
    Write-Host -ForegroundColor DarkYellow "$tagName";
    git tag -a $tagName -m $tagMessage
}

# Creates a tag with the next major version (minor version starts again at 0)
function TagNextMajorVersion($tagMessage){
    $version = Get-NextMajorVersion;
    $tagName = "v{0}" -f "$version".Trim();
    Write-Host -NoNewline "Tagging next majo version to ";
    Write-Host -ForegroundColor DarkYellow "$tagName";
    git tag -a $tagName -m $tagMessage
}