リビジョン番号に相当するGitは何ですか？

職場ではSVNを使用していますが、個人的なプロジェクトではGitを使用することにしました。だから私は昨日Gitをインストールしましたが、Gitで相当するリビジョン番号は何だろうと思います。

たとえば、バージョン3.0.8で作業していて、すべてのバグ修正に独自のリビジョン番号があり、このバグ修正について話すときに使用できるとします。では、Gitのコードに3.0.8のタグを付けると、リビジョン番号やその他のより詳細な種類のIDとして何を使用できますか？ハッシュは人間にとって使いやすいものではありません。

あなたにとって良いニュースか悪いニュースか、そのハッシュはリビジョン番号です。SVNからgitに切り替えたときにも問題が発生しました。

gitで「タグ付け」を使用すると、特定のリビジョンを特定のバージョンの「リリース」としてタグ付けでき、そのリビジョンを簡単に参照できます。こちらのブログ投稿をご覧ください。

理解しておくべき重要なことは、gitはリビジョン番号を持つことができないということです-分散した性質について考えてください。ユーザーAとBが両方ともローカルリポジトリにコミットしている場合、Gitはどのように合理的な連続リビジョン番号を割り当てることができますか？Aは、互いの変更をプッシュ/プルするまで、Bについては知りません。

もう1つ注目すべき点は、バグ修正ブランチの単純化されたブランチです。

リリース：3.0.8から始めます。次に、そのリリース後、次のようにします。

git branch bugfixes308

これにより、バグ修正用のブランチが作成されます。ブランチをチェックアウトします。

git checkout bugfixes308

次に、必要なバグ修正を行います。

git commit -a

それらをコミットし、masterブランチに切り替えます。

git checkout master

次に、これらの変更を他のブランチから取得します。

git merge bugfixes308

そうすることで、リリース固有のバグ修正ブランチが別にありますが、バグ修正の変更をメインの開発トランクに引き込んでいます。

最新のGit（私の場合は1.8.3.4）でブランチを使用しないと、次のことができます。

$ git rev-list --count HEAD
68

このgit describeコマンドは、特定のコミットを参照する、少し人間が理解できる名前を作成します。たとえば、ドキュメントから：

git.git current treeのようなもので、私は得ます：

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

つまり、「親」ブランチの現在のヘッドはv1.0.4に基づいていますが、その上にいくつかのコミットがあるため、describeは追加のコミット数（「14」）とそのコミットの省略されたオブジェクト名を追加しました最後にそれ自体（「2414721」）。

特定のリリースにタグを付けるために、わかりやすい名前のタグを使用している限り、これはSVNの「リビジョン番号」とほぼ同等と見なすことができます。

他のポスターは正しいです、「改訂番号」はありません。

「リリース」にタグを使用するのが最善の方法だと思います。

しかし、私は以下を利用して偽のリビジョン番号を作成しました（クライアントがSubversionで使用するのと同じようにgitからのリビジョンを増やしたいので、リビジョンと進行状況を確認するためだけに）。

これを使用してシミュレートされた「HEAD」の「現在のリビジョン」を表示します。

git rev-list HEAD | wc -l

しかし、クライアントから「リビジョン」1302にバグがあると言われたらどうなるでしょうか。

このために、以下を〜/ .gitconfigの[alias]セクションに追加しました：

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

を使用git show-rev-number 1302すると、「リビジョン」のハッシュが出力されます:)

少し前に、その "テクニック"に関するブログ投稿（ドイツ語）を作成しました。

Gitには、サブバージョンと同じリビジョン番号の概念はありません。代わりに、コミットで作成された各スナップショットは、SHA1チェックサムによってタグ付けされます。どうして？分散バージョン管理システムでのrevnoの実行にはいくつかの問題があります。

まず、開発はまったく線形ではないため、プログラマーとしてのニーズを満たす方法で解決する問題として、数値の付加はかなり困難です。数値を追加してこれを修正しようとすると、数値が期待どおりに動作しない場合にすぐに問題が発生する可能性があります。

次に、リビジョン番号が異なるマシンで生成される可能性があります。これにより、特に接続が一方向であるため、数値の同期がはるかに困難になります。リポジトリがあるすべてのマシンにアクセスできない場合もあります。

第3に、gitでは、現在は機能しなくなったOpenCMシステムによって開拓され、コミットのID（コミットとは）はその名前（SHA ID）と同じです。このネーミング=アイデンティティの概念は非常に強力です。コミット名を手元に置いておくと、偽造できない方法でコミットが識別されます。これにより、すべてのコミットを最初の最初のコミットに戻し、git fsckコマンドによる破損を確認できます。

これで、リビジョンのDAG（有向非巡回グラフ）があり、これらが現在のツリーを構成しているため、問題を解決するためにいくつかのツールが必要です。異なるバージョンを区別するにはどうすればよいですか。まず、与えられたプレフィックス（1516bdなど）がコミットを一意に識別する場合は、ハッシュの一部を省略できます。しかし、これもかなり不自然です。代わりに、コツはタグやブランチを使用することです。タグまたはブランチは、特定のコミットSHA1-idに添付する「黄色いスティックイットノート」に似ています。本質的に、タグは移動しないことを意味しますが、ブランチがそのHEADに新しいコミットが行われると移動します。タグまたはブランチの周りのコミットを参照する方法があります。git-rev-parseのmanページを参照してください。

通常、特定のコード部分で作業する必要がある場合、その部分は変更中であり、そのため、それは言っているトピック名を持つブランチである必要があります。たくさんのブランチを作成する（プログラマあたり20-30は前例のないことではなく、他の人が作業するために4-5が公開されている）のは効果的なgitのコツです。すべての作業は独自のブランチとして開始し、テスト時にマージする必要があります。未公開のブランチは完全に書き直すことができ、歴史を破壊するこの部分はgitの力です。

変更がマスターに受け入れられると、多少フリーズして考古学になります。その時点でタグを付けることができますが、多くの場合、特定のコミットへの参照は、sha1 sumを介してバグトラッカーまたは課題トラッカーで行われます。タグは、（古いバージョンの）メンテナンスブランチのバージョンバンプおよびブランチポイント用に予約される傾向があります。

興味があれば、私はここの git infosからバージョン番号を自動的に管理しました

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

ここで、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]*\).*/\1/")
MINOR      = $(shell echo $(VERSION) | sed "s/[0-9]*\.\([0-9]*\).*/\1/")
PATCH      = $(shell echo $(VERSION) | sed "s/[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/")
# 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)

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}
}

のようなものを出力します

$ git_rev
2:0f8e14e:20130220

あれは

commit_count:last_abbrev_commit:date_YYmmdd

コミットのSHA1ハッシュは、 Subversionリビジョン番号と同等です。

これは、他のソリューションに基づいてメイクファイルで行ったことです。これにより、コードにリビジョン番号が付与されるだけでなく、リリースを再作成できるハッシュが追加されます。

# 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

ビルド番号としてgitハッシュを使用する場合の問題は、単調に増加しないことです。OSGiは、ビルド番号にタイムスタンプを使用することをお勧めします。ブランチへのコミット数は、subversionまたはperforceの変更番号の代わりに使用できるようです。

Gitからバージョン情報を取得し、タグ付けを簡素化するためのPowerShellユーティリティをいくつか書いた

関数：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
}

各コミットには一意のハッシュがあります。それ以外はgitにリビジョン番号はありません。さらに使いやすくするには、自分でコミットにタグを付ける必要があります。

別の可能なアプローチに注意したいのですが、これはgit git-notes（1）を使用することであり、v 1.6.6以降に存在します（Self-Gitへの注意）（gitバージョン1.7.9.5 を使用しています）。

基本的に、私git svnは線形履歴（標準レイアウトなし、ブランチなし、タグなし）でSVNリポジトリーを複製するために使用し、複製されたgitリポジトリーのリビジョン番号を比較したいと考えました。このgitクローンにはデフォルトでタグがないため、を使用できませんgit describe。ここでの戦略は、線形履歴に対してのみ機能する可能性があります-マージなどでどうなるかはわかりません。しかし、ここに基本的な戦略があります：

• 掲載git rev-listのすべてのリストの履歴をコミット
  • 以来rev-list、「新しい順」にデフォルトである、我々は、その使用したい--reverse最初の最も古い順にソートコミットのリストを取得するようにスイッチを
• bashシェルを使用して
  • リビジョンカウンターとして各コミットのカウンター変数を増やし、
  • コミットごとに「一時的な」git noteを生成して追加する
• 次に、git logwith を使用してログを参照します。これにより--notes、コミットのメモもダンプされます。この場合、「リビジョン番号」になります。
• 完了したら、一時的なメモを消去します（注：これらのメモがコミットされているかどうかはわかりません。実際には表示されませんgit status）

最初に、メモgitのデフォルトの場所があることに注意しましょう。ただし、メモのref（erence）を指定することもできます。これにより、の下の別のディレクトリに保存され.gitます。たとえば、gitrepoフォルダーにいる間は、を呼び出しgit notes get-refて、どのディレクトリになるかを確認できます。

$ git notes get-ref
refs/notes/commits
$ git notes --ref=whatever get-ref
refs/notes/whatever

注意する事は、あなたの場合ということであるnotes addと--refそうでない場合はあなたのようなエラーが出ることがあり、「 - 、あなたはまた、その後再びその参照を使用する必要がありませノートは、オブジェクトXXXが見つかりません...」。

この例でrefは、ノートの「linrev」（線形リビジョンの場合）を呼び出すことを選択しました。これは、手順が既存のノートに干渉する可能性が低いことも意味します。私もこの--git-dirスイッチを使用しています。git初心者なので、理解に問題がありました:)。「後で覚えておきたい」と思います。また、を使用--no-pagerするless場合のの生成を抑制するためにも使用しgit logます。

したがって、リポジトリであるサブフォルダmyrepo_gitを含むディレクトリにいると しgitます。できること：

### check for already existing notes:

$ git --git-dir=./myrepo_git/.git notes show
# error: No note found for object 04051f98ece25cff67e62d13c548dacbee6c1e33.
$ git --git-dir=./myrepo_git/.git notes --ref=linrev show
# error: No note found for object 04051f98ece25cff67e62d13c548dacbee6c1e33.

### iterate through rev-list three, oldest first,
### create a cmdline adding a revision count as note to each revision

$ ix=0; for ih in $(git --git-dir=./myrepo_git/.git rev-list --reverse HEAD); do \
  TCMD="git --git-dir=./myrepo_git/.git notes --ref linrev"; \
  TCMD="$TCMD add $ih -m \"(r$((++ix)))\""; \
  echo "$TCMD"; \
  eval "$TCMD"; \
done

# git --git-dir=./myrepo_git/.git notes --ref linrev add 6886bbb7be18e63fc4be68ba41917b48f02e09d7 -m "(r1)"
# git --git-dir=./myrepo_git/.git notes --ref linrev add f34910dbeeee33a40806d29dd956062d6ab3ad97 -m "(r2)"
# ...
# git --git-dir=./myrepo_git/.git notes --ref linrev add 04051f98ece25cff67e62d13c548dacbee6c1e33 -m "(r15)"

### check status - adding notes seem to not affect it:

$ cd myrepo_git/
$ git status
# # On branch master
# nothing to commit (working directory clean)
$ cd ../

### check notes again:

$ git --git-dir=./myrepo_git/.git notes show
# error: No note found for object 04051f98ece25cff67e62d13c548dacbee6c1e33.
$ git --git-dir=./myrepo_git/.git notes --ref=linrev show
# (r15)

### note is saved - now let's issue a `git log` command, using a format string and notes:

$ git --git-dir=./myrepo_git/.git --no-pager log --notes=linrev --format=format:"%h: %an: %ad:  >>%s<< %N" HEAD
# 04051f9: _user_: Sun Apr 21 18:29:02 2013 +0000:  >>test message 15 << (r15)
# 77f3902: _user_: Sun Apr 21 18:29:00 2013 +0000:  >>test message 14<< (r14)
# ...
# 6886bbb: _user_: Sun Apr 21 17:11:52 2013 +0000:  >>initial test message 1<< (r1)

### test git log with range:

$ git --git-dir=./myrepo_git/.git --no-pager log --notes=linrev --format=format:"%h: %an: %ad:  >>%s<< %N" HEAD^..HEAD
# 04051f9: _user_: Sun Apr 21 18:29:02 2013 +0000:  >>test message 15 << (r15)

### erase notes - again must iterate through rev-list

$ ix=0; for ih in $(git --git-dir=./myrepo_git/.git rev-list --reverse HEAD); do \
  TCMD="git --git-dir=./myrepo_git/.git notes --ref linrev"; \
  TCMD="$TCMD remove $ih"; \
  echo "$TCMD"; \
  eval "$TCMD"; \
done
# git --git-dir=./myrepo_git/.git notes --ref linrev remove 6886bbb7be18e63fc4be68ba41917b48f02e09d7
# Removing note for object 6886bbb7be18e63fc4be68ba41917b48f02e09d7
# git --git-dir=./myrepo_git/.git notes --ref linrev remove f34910dbeeee33a40806d29dd956062d6ab3ad97
# Removing note for object f34910dbeeee33a40806d29dd956062d6ab3ad97
# ...
# git --git-dir=./myrepo_git/.git notes --ref linrev remove 04051f98ece25cff67e62d13c548dacbee6c1e33
# Removing note for object 04051f98ece25cff67e62d13c548dacbee6c1e33

### check notes again:

$ git --git-dir=./myrepo_git/.git notes show
# error: No note found for object 04051f98ece25cff67e62d13c548dacbee6c1e33.
$ git --git-dir=./myrepo_git/.git notes --ref=linrev show
# error: No note found for object 04051f98ece25cff67e62d13c548dacbee6c1e33.

したがって、少なくともブランチのない完全に線形の履歴の特定のケースでは、リビジョン番号はこのアプローチと一致しているように見えます-さらに、このアプローチではgit logリビジョン範囲を使用しながら、正しいリビジョン番号を取得できるようです-YMMVただし、コンテキストは異なります...

これが誰かを助けることを願って、
乾杯！

編集：OK、ここでは少し簡単gitです、上記のループのエイリアスはsetlinrevandと呼ばれunsetlinrevます。gitリポジトリフォルダーで次の操作を行います（_{厄介なbashエスケープに注意してください。＃16136745-セミコロンを含むGitエイリアスを追加するも参照してください}）：

cat >> .git/config <<"EOF"
[alias]
  setlinrev = "!bash -c 'ix=0; for ih in $(git rev-list --reverse HEAD); do \n\
      TCMD=\"git notes --ref linrev\"; \n\
      TCMD=\"$TCMD add $ih -m \\\"(r\\$((++ix)))\\\"\"; \n\
      #echo \"$TCMD\"; \n\
      eval \"$TCMD\"; \n\
    done; \n\
    echo \"Linear revision notes are set.\" '"

  unsetlinrev = "!bash -c 'ix=0; for ih in $(git rev-list --reverse HEAD); do \n\
      TCMD=\"git notes --ref linrev\"; \n\
      TCMD=\"$TCMD remove $ih\"; \n\
      #echo \"$TCMD\"; \n\
      eval \"$TCMD 2>/dev/null\"; \n\
    done; \n\
    echo \"Linear revision notes are unset.\" '"
EOF

...したがってgit setlinrev、線形リビジョンノートを含むログを作成する前に、単純に呼び出すことができます。そしてgit unsetlinrev完了したら、それらのメモを削除します。git repoディレクトリ内の例：

$ git log --notes=linrev --format=format:"%h: %an: %ad:  >>%s<< %N" HEAD^..HEAD
04051f9: _user_: Sun Apr 21 18:29:02 2013 +0000:  >>test message 15 <<

$ git setlinrev
Linear revision notes are set.
$ git log --notes=linrev --format=format:"%h: %an: %ad:  >>%s<< %N" HEAD^..HEAD
04051f9: _user_: Sun Apr 21 18:29:02 2013 +0000:  >>test message 15 << (r15)
$ git unsetlinrev
Linear revision notes are unset.

$ git log --notes=linrev --format=format:"%h: %an: %ad:  >>%s<< %N" HEAD^..HEAD
04051f9: _user_: Sun Apr 21 18:29:02 2013 +0000:  >>test message 15 <<

シェルがこれらのエイリアスを完了するのにかかる時間は、リポジトリ履歴のサイズによって異なります。

Antビルドプロセスを持っている人のために、このターゲットを使用してgit上のプロジェクトのバージョン番号を生成できます。

<target name="generate-version">

    <exec executable="git" outputproperty="version.revisions">
        <arg value="log"/>
        <arg value="--oneline"/>
    </exec>

    <resourcecount property="version.revision" count="0" when="eq">
        <tokens>
            <concat>
                <filterchain>
                    <tokenfilter>
                        <stringtokenizer delims="\r" />
                    </tokenfilter>
                </filterchain>
            <propertyresource name="version.revisions" />
            </concat>
        </tokens>
    </resourcecount>
    <echo>Revision : ${version.revision}</echo>

    <exec executable="git" outputproperty="version.hash">
        <arg value="rev-parse"/>
        <arg value="--short"/>
        <arg value="HEAD"/>
    </exec>
    <echo>Hash : ${version.hash}</echo>


    <exec executable="git" outputproperty="version.branch">
        <arg value="rev-parse"/>
        <arg value="--abbrev-ref"/>
        <arg value="HEAD"/>
    </exec>
    <echo>Branch : ${version.branch}</echo>

    <exec executable="git" outputproperty="version.diff">
        <arg value="diff"/>
    </exec>

    <condition property="version.dirty" value="" else="-dirty">
        <equals arg1="${version.diff}" arg2=""/>
    </condition>

    <tstamp>
        <format property="version.date" pattern="yyyy-mm-dd.HH:mm:ss" locale="en,US"/>
    </tstamp>
    <echo>Date : ${version.date}</echo>

    <property name="version" value="${version.revision}.${version.hash}.${version.branch}${version.dirty}.${version.date}" />

    <echo>Version : ${version}</echo>

    <echo file="version.properties" append="false">version = ${version}</echo>

</target>

結果は次のようになります。

generate-version:
    [echo] Generate version
    [echo] Revision : 47
    [echo] Hash : 2af0b99
    [echo] Branch : master
    [echo] Date : 2015-04-20.15:04:03
    [echo] Version : 47.2af0b99.master-dirty.2015-04-20.15:04:03

ダーティフラグは、バージョン番号の生成時にコミットされていないファイルがある場合に使用されます。通常、アプリケーションをビルド/パッケージ化するときは、すべてのコード変更をリポジトリに含める必要があるためです。

コミットのSHA-1 IDに加えて、サーバーの日付と時刻が役に立ちましたか？

このようなもの：

2013年8月19日11:30:25に発生したコミットは6886bbb7be18e63fc4be68ba41917b48f02e09d7_19aug2013_113025と表示されます

Gitマニュアルによると、タグはこの問題に対する素晴らしい答えです。

Gitでの注釈付きタグの作成は簡単です。最も簡単な方法は、tagコマンドを実行するときに-aを指定することです。

$ git tag -a v1.4 -m 'my version 1.4'

$ git tag
v0.1
v1.3
v1.4

2.6 Gitの基本-タグ付けを確認する

次のコマンドを使用して、gitからバージョンとリビジョンを取得しています。

git describe --always --tags --dirty

戻る

• タギングを使用しない場合、リビジョンとしてハッシュをコミット（例gcc7b71f）
• タグ上にあるときのバージョンとしてのタグ名（たとえばv2.1.0、リリースに使用）
• タグ名、最後のタグ以降のリビジョン番号、タグの後のハッシュのコミット（例v5.3.0-88-gcc7b71f）
• 上記と同じですが、作業ツリーにローカルの変更がある場合は「ダーティ」タグ（例v5.3.0-88-gcc7b71f-dirty）

参照：https : //www.git-scm.com/docs/git-describe#Documentation/git-describe.txt

Visual Studioのビルド後のイベント

echo  >RevisionNumber.cs static class Git { public static int RevisionNumber =
git  >>RevisionNumber.cs rev-list --count HEAD
echo >>RevisionNumber.cs ; }

使用を検討する

git-rev-label

Gitリポジトリのリビジョンに関する情報をのような形式で提供しますmaster-c73-gabc6bec。テンプレート文字列またはファイルに環境変数とGitからの情報を入力できます。プログラムのバージョンに関する情報を提供するのに便利です：ブランチ、タグ、コミットハッシュ、コミット数、ダーティステータス、日付と時刻。最も有用なことの1つは、マージされたブランチを考慮せずにコミット数をカウントすることです-最初の親のみ。