리비전 번호에 대한 Git 등가물은 무엇입니까?

리비전 번호에 대한 Git 등가물은 무엇입니까?

우리는 직장에서 SVN을 사용하지만, 개인적인 프로젝트를 위해 Git을 사용하기로 결정했습니다.그래서 어제 Git을 설치했는데, Git에 해당하는 리비전 번호가 무엇인지 궁금합니다.

버전 3.0.8에서 작업하고 모든 버그 수정에는 이 버그 수정에 대해 설명할 때 사용할 수 있는 자체 수정 번호가 있다고 가정해 보겠습니다.그렇다면 Git의 코드를 3.0.8에 태그를 지정하면 수정 번호나 기타 더 자세한 종류의 식별 정보로 사용할 수 있는 것은 무엇입니까?저는 해시가 인간에게 그다지 사용자 친화적이지 않다고 생각합니다.

분기를 사용하지 않고 최신 Git(내 경우 1.8.3.4)를 사용하면 다음을 수행할 수 있습니다.

$ git rev-list --count HEAD
68

그러나 이것은 모든 종류의 문제를 가지고 있으며 복제하기가 쉽지 않거나 필요한 경우 커밋 해시로 돌아가기가 쉽지 않을 수 있습니다.그러니 그것을 피하거나 힌트로만 사용하세요.

좋은 소식이든 나쁜 소식이든, 그 해시는 수정 번호입니다.SVN에서 git로 전환할 때도 문제가 있었습니다.

태그 지정' git을 사용하여 특정 버전을 특정 버전의 "릴리스"로 태그 지정할 수 있으므로 해당 버전을 쉽게 참조할 수 있습니다.이 블로그 게시물을 확인하십시오.

이해해야 할 중요한 것은 git이 개정 번호를 가질 수 없다는 것입니다. 분산된 특성에 대해 생각해 보십시오.사용자 A와 B가 모두 로컬 리포지토리에 커밋하는 경우, Git가 어떻게 순차적인 개정 번호를 합리적으로 할당할 수 있습니까?A는 서로의 변화를 밀고 당기기 전에 B에 대해 전혀 알지 못합니다.

또한 버그 수정 분기를 위한 단순화된 분기 기능도 제공합니다.

버전 3.0.8부터 시작합니다.그런 다음 릴리스 후 다음 작업을 수행합니다.

git branch bugfixes308

이렇게 하면 버그 수정을 위한 분기가 생성됩니다.분기 체크아웃:

git checkout bugfixes308

이제 원하는 버그 수정을 수행합니다.

git commit -a

해당 항목을 커밋하고 마스터 분기로 다시 전환합니다.

git checkout master

그런 다음 다른 분기에서 변경 사항을 끌어옵니다.

git merge bugfixes308

이렇게 하면 별도의 릴리스별 버그 수정 분기가 있지만 버그 수정 변경 사항을 메인 개발 트렁크에 추가할 수 있습니다.

이 명령은 특정 커밋을 참조하는 보다 사용자가 읽을 수 있는 이름을 만듭니다.예를 들어 설명서에서 다음을 참조하십시오.

git.git 전류 트리와 같은 것을 사용하면 다음과 같이 얻을 수 있습니다.

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

즉, 현재 "부모" 지점의 헤드는 v1.0.4를 기반으로 하지만, 여기에 몇 개의 커밋이 있기 때문에, description은 추가 커밋 수("14")와 커밋 자체에 대한 약어 개체 이름("2414721")을 마지막에 추가했습니다.

명명된 태그를 사용하여 특정 릴리스에 태그를 지정하는 한, 이는 SVN "개정 번호"와 거의 동일한 것으로 간주할 수 있습니다.

다른 포스터가 맞습니다. "개정 번호"는 없습니다.

"출시"에 태그를 사용하는 것이 가장 좋은 방법이라고 생각합니다!

하지만 저는 다음과 같은 수정 번호를 가짜 수정 번호로 사용했습니다(단, 클라이언트가 git에서 subversion까지 사용하는 것과 동일하게 수정 사항을 증가시키기를 원했기 때문에 수정 사항과 진행 상황을 보기 위해 사용한 것입니다).

다음을 사용하여 "HEAD"의 "현재 리비전"이 시뮬레이션되었음을 나타냅니다.

git rev-list HEAD | wc -l

하지만 고객이 "revision" 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에는 몇 가지 문제가 있습니다.

첫째, 개발이 전혀 선형적이지 않기 때문에 프로그래머로서 당신의 요구를 충족시킬 수 있는 방식으로 숫자를 붙이는 것은 해결하기 어려운 문제입니다.숫자를 추가하여 이 문제를 해결하려고 하면 숫자가 예상대로 작동하지 않을 때 문제가 발생할 수 있습니다.

둘째, 수정 번호는 다른 컴퓨터에서 생성될 수 있습니다.이는 특히 연결이 단방향이기 때문에 번호 동기화를 훨씬 어렵게 만듭니다. 저장소가 있는 모든 컴퓨터에 액세스하지 못할 수도 있습니다.

셋째, 현재는 없어진 OpenCM 시스템에 의해 다소 개척된 git는 커밋의 정체성(커밋이 무엇인지)이 이름(SHAID)과 같습니다.이러한 명명 = ID 개념은 매우 강력합니다.커밋 이름을 손에 들고 앉아 있으면 커밋을 용서할 수 없는 방식으로 식별할 수도 마찬가지입니다.이를 통해 처음 커밋에 대한 모든 커밋을 다시 확인하여 처음 커밋의 손상 여부를 확인할 수 있습니다.git fsck지휘권

이제 DAG(방향 비순환 그래프) 수정본이 있고 이러한 수정본이 현재 트리를 구성하므로 문제를 해결하기 위한 몇 가지 도구가 필요합니다.어떻게 다른 버전을 구별합니까?첫째, 1516bd가 말하는 특정 접두사가 커밋을 고유하게 식별하는 경우 해시의 일부를 생략할 수 있습니다.하지만 이것 또한 다소 꾸며진 것입니다.대신 태그 및/또는 분기를 사용하는 것이 요령입니다.태그 또는 분기는 지정된 커밋 SHA1-id에 부착하는 "노란색 막대 노트"와 유사합니다.태그는 기본적으로 이동하지 않는 반면, 분기는 HEAD에 대한 새 커밋이 이루어질 때 이동합니다.태그 또는 분기 주변의 커밋을 참조하는 방법이 있습니다. git-rev-parse의 man 페이지를 참조하십시오.

일반적으로 특정 코드 조각을 작업해야 하는 경우 해당 조각은 변경 중이므로 해당 항목 이름을 가진 분기여야 합니다.많은 지점을 만드는 것(프로그래머당 20-30개, 다른 사람들이 작업할 수 있도록 4-5개 게시)이 효과적인 깃의 비결입니다.모든 작업은 자체 분기로 시작하여 테스트할 때 병합되어야 합니다.출판되지 않은 분기는 완전히 다시 작성될 수 있으며 역사를 파괴하는 이 부분은 기트의 힘입니다.

변화가 마스터로 받아들여지면 어느 정도 얼어붙고 고고학이 됩니다.이 시점에서 태그를 지정할 수 있지만, 더 자주 특정 커밋에 대한 참조가 bug tracker 또는 issue tracker에서 sha1 sum을 통해 이루어집니다.태그는 버전 범프용으로 예약되고 유지관리 분기(이전 버전의 경우)의 분기점용으로 예약되는 경향이 있습니다.

관심이 있으시다면 여기 git infos에서 버전 번호를 자동으로 관리했습니다.

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

여기서 build는 총 커밋 수입니다.에서 흥미로운 코드를 볼 수 있습니다.버전 번호의 다른 부분에 액세스하기 위한 관련 부분은 다음과 같습니다.

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 해시는 하위 버전 수정 번호와 동일합니다.

이것은 제가 다른 솔루션을 기반으로 한 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

git 해시를 빌드 번호로 사용할 때의 문제는 단조롭게 증가하지 않는다는 것입니다.OSGi는 빌드 번호에 타임스탬프를 사용할 것을 제안합니다.하위 버전 또는 강제 변경 번호 대신 분기에 대한 커밋 수를 사용할 수 있습니다.

Git에서 버전 정보를 검색하고 태그 지정을 단순화하기 위한 PowerShell 유틸리티를 작성했습니다.

함수: Get-LastVersion, Get-Next MajorVersion, Get-Next MinorVersion, TagNext MajorVersion, TagNext MinorVersion:

# 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에 개정 번호가 없습니다.더 사용하기 쉽게 하려면 커밋에 태그를 지정해야 합니다.

가능한 접근법에 은 저는다가접에주근싶목다습고 - 것입다니사는하용니그은것하른법능한▁using다▁-를 사용하는 것입니다.git git-notes(1), v1.6.6 이후 존재함(자체에 대한 참고 - Git)(사용 중)git버전 1.7.9.5).

기본적으로, 저는 사용했습니다.git svn 기록 레이아웃, 없음)이입니다. 된 SVN 저장소의 .git저소장 이에 클는기태이없사수없용다습에니깃로할므으가론그로본으적▁doesn없수▁use니▁by를 사용할 수 .git describe여기서 전략은 선형 이력에만 적용될 가능성이 높지만 병합 등을 통해 어떻게 나올지는 확실하지 않습니다. 하지만 기본 전략은 다음과 같습니다.

• 물어보다git rev-list모든 커밋 기록 목록
  • 때부터rev-list기본적으로 "시간순 정렬"이며, 우리는 그것을 사용합니다.--reverse가장 first로 합니다.
• 사용하다bash에 껍질을 벗기다.
  • 각 커밋의 카운터 변수를 리비전 카운터로 늘립니다.
  • 각 커밋에 대해 "임의" 깃 노트를 생성하고 추가합니다.
• 그런 다음 다음 다음을 사용하여 로그를 탐색합니다.git log와 함께--notesnumber", "", "commit", "commit", "commit note"가 됩니다
• 완료되면 임시 노트를 지웁니다(NB: 해당 노트가 커밋되었는지 여부를 잘 모르겠습니다. 에 표시되지 않습니다).

먼저, 다음과 같은 점에 유의합니다.git. 가 "" " " " 를 . 그러나 사용자는 다음을 지정할 수 있습니다.ref(erence) 노트의 경우 - 아래의 다른 디렉토리에 저장합니다..git를 들어, 때, 있는에예동.git 폴더,은 repo를 부를 수 .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.

분기가 완전 에, 이 과 일치하는 것처럼 . 은 따서적어분특경우한정이력, 수번이접보근방다니입는것일로으식호과는정하치라의형선전완는없도기가▁using▁so▁with▁allow▁will▁seem▁approach다▁numbers,▁that▁this▁-보▁seems를 사용할 수 있을 것으로 보입니다. 추가적으로, 이 접근 방식은 다음을 허용할 것으로 보입니다.git log수정 범위를 사용하면서도 정확한 수정 번호를 얻을 수 있습니다. YMMV는 다른 맥락이지만...

이게 누군가에게 도움이 되길 바랍니다.
건배!

---

네, 집편: 네는, 서조금더다로 더 .git루프에 인 위의루대별칭한됨, 출호프에됨setlinrev그리고.unsetlinrevgit 저장소 폴더에서 ()_{Note the nasty bash escaping, see also #16136745 - Add a Git alias containing a semicolon}를 수행합니다.

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 setlinrevnote를 에; 선형개정노로포수시고려전에기하도그리고하행그를함는트하를▁before▁involving그▁and;▁trying리고▁revision전.git unsetlinrev완료되면 해당 노트를 삭제합니다. gitrepo 디렉토리 내부의 예:

$ 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 빌드 프로세스를 사용하는 사용자는 다음 대상을 사용하여 프로젝트 on 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

버전 번호를 생성할 때 파일이 커밋되지 않은 경우 더티 플래그가 여기에 있습니다.일반적으로 응용프로그램을 빌드/패키지화할 때 모든 코드 수정 사항이 저장소에 있어야 하기 때문입니다.

이 명령을 사용하여 git에서 버전 및 개정판을 가져옵니다.

git describe --always --tags --dirty

돌아옵니다

• 하지 않을 태를사지않예경해수커버밋로합다니전으정를시우는하용그예▁as:(:gcc7b71f)
• 태그에 있을 때 버전으로 태그 이름을 지정합니다(예:v2.1.0릴리스에 사용됨)
• 이름, 및 경우 를 커밋합니다: 태이름, 마막태이그예수, 정후커해뒤시다에밋니를합태그호번및).v5.3.0-88-gcc7b71f)
• "", " 수로이항" "정예가" "위니" "됩다" "가추" "태그" "우와" "작경" "는" "업" "" "에" "정" "컬" "리" "수" "트" "▁if" "수" "예" ":" "▁a" "dirty" "▁same" "▁plus" "▁tag" "▁the" "e" "▁"" """ "▁as" "▁has" "▁mod" "v5.3.0-88-gcc7b71f-dirty)

참고 항목: https://www.git-scm.com/docs/git-describe#Documentation/git-describe.txt

커밋의 SHA-1 ID와 함께 서버 시간의 날짜와 시간이 도움이 되었습니까?

이와 같은 것:

2013년 8월 19일 11:30:25에 발생한 커밋은 6886bb7be18e63fc4be68ba41917b48f02e09d7_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 Basics 확인 - 태그 지정

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-gabc6becGit의 환경 변수와 정보로 템플릿 문자열 또는 파일을 채울 수 있습니다.분기, 태그, 커밋 해시, 커밋 횟수, 더티 상태, 날짜 및 시간 등 프로그램 버전에 대한 정보를 제공하는 데 유용합니다.가장 유용한 것 중 하나는 병합된 분기(첫 번째 상위 항목만)를 고려하지 않고 커밋 수입니다.

언급URL : https://stackoverflow.com/questions/4120001/what-is-the-git-equivalent-for-revision-number