webentwicklung-frage-antwort-db.com.de

Was ist das Git-Äquivalent für die Revisionsnummer?

Wir verwenden SVN bei der Arbeit, aber für meine persönlichen Projekte habe ich mich für Git entschieden. Also habe ich Git gestern installiert und ich frage mich, wie die Revisionsnummer äquivalent in Git ist.

Nehmen wir an, wir arbeiten an Version 3.0.8 und jeder Bugfix hat seine eigene Revisionsnummer, die wir verwenden können, wenn wir über diesen Bugfix sprechen. Wenn ich also den Code in Git zu 3.0.8 tagge, was kann ich dann als Revisionsnummer oder eine andere, ausführlichere Art der Identifikation verwenden? Ich finde den Hash nicht so benutzerfreundlich für Menschen.

220
Radek

Gute oder schlechte Nachrichten für Sie, diese Hash-Nummer IS]. Ich hatte auch Probleme damit, als ich von SVN zu git wechselte.

Sie können "Tagging" in git verwenden, um eine bestimmte Version als "Release" für eine bestimmte Version zu kennzeichnen, sodass Sie leicht auf diese Version verweisen können. Schauen Sie sich diesen Blogbeitrag an .

Der Schlüssel zum Verständnis ist, dass git keine Revisionsnummern haben kann - denken Sie an das Dezentrale. Wenn sich Benutzer A und B beide für ihre lokalen Repositorys engagieren, wie kann git dann eine fortlaufende Revisionsnummer sinnvoll zuweisen? A hat keine Kenntnis von B, bevor er die Änderungen des anderen wechselt.

Eine andere Sache, die Sie betrachten sollten, ist die vereinfachte Verzweigung für Bugfix-Zweige:

Beginnen Sie mit einem Release: 3.0.8. Führen Sie dann nach dieser Veröffentlichung Folgendes aus:

git branch bugfixes308

Dadurch wird eine Verzweigung für Bugfixes erstellt. Kasse der Filiale:

git checkout bugfixes308

Nehmen Sie nun die gewünschten Bugfix-Änderungen vor.

git commit -a

Übernehmen Sie sie und wechseln Sie zurück zum Hauptzweig:

git checkout master

Dann ziehen Sie diese Änderungen aus dem anderen Zweig ein:

git merge bugfixes308

Auf diese Weise haben Sie einen separaten Release-spezifischen Bugfix-Zweig, ziehen jedoch weiterhin die Bugfix-Änderungen in Ihren Haupt-Dev-Trunk.

138
makdad

Mit modernem Git (in meinem Fall 1.8.3.4) und ohne Verzweigungen können Sie Folgendes tun:

$ git rev-list --count HEAD
68
149
max

Der Befehl git describe erstellt einen etwas leserlicheren Namen, der auf ein bestimmtes Commit verweist. Zum Beispiel aus der Dokumentation:

Mit so etwas wie git.git current tree bekomme ich:

[[email protected] git]$ git describe parent
v1.0.4-14-g2414721

dh der aktuelle Kopf meines "parent" -Zweigs basiert auf v1.0.4, aber da er noch ein paar Commits hat, hat die Beschreibung die Anzahl zusätzlicher Commits ("14") und einen abgekürzten Objektnamen für das Commit hinzugefügt selbst ("2414721") am Ende.

Solange Sie sinnvoll benannte Tags verwenden, um bestimmte Releases zu kennzeichnen, kann dies als ungefähr gleichwertig mit einer SVN-Revisionsnummer betrachtet werden.

95
Greg Hewgill

Die anderen Plakate stimmen, es gibt keine "Revisionsnummer".

Ich denke, der beste Weg ist, Tags für "Veröffentlichungen" zu verwenden!

Aber ich habe die folgenden verwendet, um Revisionsnummern zu fälschen (nur für Kunden, um Revisionen und den Fortschritt zu sehen, da sie die gleichen zunehmenden Revisionen von haben wollten git wie sie von Subversion verwendet werden).

Zeigen Sie, dass die "aktuelle Revision" von "HEAD" folgendermaßen simuliert wird:

git rev-list HEAD | wc -l

Aber was ist, wenn der Client mir sagt, dass ein Fehler in "Revision" 1302 vorliegt?

Dazu habe ich dem Abschnitt [alias] meiner ~/.gitconfig Folgendes hinzugefügt:

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

using git show-rev-number 1302 gibt dann den Hash für die "Revision" aus :)

Ich habe vor einiger Zeit einen Blog Post über diese "Technik" geschrieben.

67
OderWat

Git hat nicht das gleiche Konzept von Revisionsnummern wie Subversion. Stattdessen wird jeder mit einem Commit erstellte Snapshot mit einer SHA1-Prüfsumme gekennzeichnet. Warum? Es gibt mehrere Probleme mit einer laufenden Revno in einem verteilten Versionskontrollsystem:

Erstens, da die Entwicklung überhaupt nicht linear ist, ist das Anhängen einer Nummer als Problem sehr schwer zu lösen, so dass es Ihren Anforderungen als Programmierer genügt. Wenn Sie versuchen, dies durch Hinzufügen einer Nummer zu beheben, kann dies schnell problematisch werden, wenn sich die Nummer nicht wie erwartet verhält.

Zweitens können Revisionsnummern auf verschiedenen Maschinen generiert werden. Dies macht die Synchronisation von Zahlen sehr viel schwieriger - zumal die Konnektivität einseitig ist. Sie haben möglicherweise nicht einmal Zugriff auf alle Computer, auf denen sich das Repository befindet.

Drittens, in git, etwas Pionierarbeit durch das jetzt nicht mehr existierende OpenCM-System, entspricht das identity eines Commits (was das Commit ist) seinem name (der SHA id.) ). Dieses naming = identity Konzept ist sehr stark. Wenn Sie mit einem Commit-Namen in der Hand sitzen, wird auch das Commit auf unverzeihliche Weise identifiziert. Auf diese Weise können Sie alle Ihre Commits zurück zum ersten Start mit dem Befehl git fsck auf Korruption überprüfen.

Da wir nun eine DAG (Directed Acyclic Graph) von Revisionen haben und diese den aktuellen Baum darstellen, benötigen wir einige Werkzeuge, um das Ihr Problem zu lösen: Wie unterscheiden wir verschiedene Versionen? Erstens können Sie einen Teil des Hashes auslassen, wenn ein gegebenes Präfix 1516bd Ihren Commit eindeutig identifiziert. Dies ist aber auch eher einfallsreich. Stattdessen besteht der Trick darin, Tags und oder Zweige zu verwenden. Ein Tag oder ein Zweig ähnelt einem "gelben Haftnotiz", den Sie an eine gegebene Festschreibungs-SHA1-ID anhängen. Tags sind im Wesentlichen dazu gedacht, sich nicht zu bewegen, wohingegen sich ein Zweig bewegt, wenn neue Commits an seinen HEAD vorgenommen werden. Es gibt Möglichkeiten, sich auf ein Commit um ein Tag oder einen Zweig zu beziehen, siehe die Manpage von git-rev-parse.

Wenn Sie an einem bestimmten Code arbeiten müssen, handelt es sich in der Regel um Änderungen und es sollte sich dabei um einen Zweig mit einem sagenhaften Themennamen handeln. Viele Filialen zu erstellen (20-30 pro Programmierer sind keine Seltenheit, 4-5 werden veröffentlicht, damit andere daran arbeiten können) ist der Trick für effektiven Git. Jede Arbeit sollte als eigener Zweig beginnen und dann beim Testen zusammengeführt werden. Unveröffentlichte Zweige können vollständig neu geschrieben werden, und dieser Teil der Zerstörung der Geschichte ist eine Kraft des Idioten.

Wenn die Änderung angenommen in master ist, friert sie etwas ein und wird zur Archäologie. An diesem Punkt können Sie es markieren, aber öfter wird in einem Bug-Tracker oder Issue-Tracker über die Summe von sha1 ein Verweis auf das jeweilige Commit gemacht. Tags sind tendenziell für Versionshöcker und Verzweigungspunkte für Wartungszweige reserviert (für ältere Versionen).

25

Bei Interesse habe ich die Versionsnummern automatisch von git infos hier unter dem Format verwaltet 

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

dabei ist build die Gesamtanzahl der Commits. Sie sehen den interessanten Code in der Makefile . Hier ist der relevante Teil, um auf den verschiedenen Teil der Versionsnummer zuzugreifen:

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)
17

Eine Bash-Funktion:

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

gibt so etwas aus

$ git_rev
2:0f8e14e:20130220

Das ist

commit_count:last_abbrev_commit:date_YYmmdd
9
siznax

Der SHA1-Hash des Commits entspricht einer Subversion-Revisionsnummer.

8
Richard Fearn

Dies ist, was ich in meinem Makefile gemacht habe, basierend auf anderen Lösungen. Hinweis: Dies gibt Ihrem Code nicht nur eine Revisionsnummer, sondern hängt auch den Hash an, mit dem Sie die Version neu erstellen können.

# 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
6

Ich habe einige PowerShell-Dienstprogramme geschrieben, um Versionsinformationen von Git abzurufen und das Tagging zu vereinfachen

funktionen: 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
}
5
toeb

Das Problem bei der Verwendung des Git-Hash als Build-Nummer ist, dass er nicht monoton steigt. OSGi empfiehlt die Verwendung eines Zeitstempels für die Build-Nummer. Es scheint, als könnte die Anzahl der Commits für die Verzweigung anstelle der Subversion oder der Änderungsnummer verwendet werden.

4
Jim Belton

Jedes Commit hat einen eindeutigen Hash. Ansonsten gibt es keine Revisionsnummern in git. Sie müssen Commits selbst kennzeichnen, wenn Sie mehr Benutzerfreundlichkeit wünschen.

4
Core Xii

Ich möchte nur einen anderen möglichen Ansatz zur Kenntnis nehmen - und zwar mit gitgit-notes (1) , die seit v 1.6.6 existiert ( Note to Self-Git (Ich verwende git Version 1.7.9.5).

Grundsätzlich habe ich git svn verwendet, um ein SVN-Repository mit linearer Historie zu klonen (kein Standardlayout, keine Verzweigungen, keine Tags), und ich wollte die Revisionsnummern im geklonten git-Repository vergleichen. Dieser Git-Klon hat standardmäßig keine Tags, daher kann ich git describe nicht verwenden. Die Strategie hier würde wahrscheinlich nur für die lineare Geschichte funktionieren - nicht sicher, wie sie sich bei Zusammenführungen usw. entwickeln würde. aber hier ist die grundstrategie:

  • Bitten Sie git rev-list um eine Liste aller Commit-Historien
    • Da rev-list standardmäßig in "umgekehrter chronologischer Reihenfolge" ist, würden wir die --reverse-Option verwenden, um die Liste der Commits nach dem ältesten zuerst zu sortieren
  • Verwenden Sie bash Shell zu
    • für jeden Commit eine Zählervariable als Revisionszähler erhöhen,
    • für jedes Commit eine "temporäre" Git-Note erzeugen und hinzufügen
  • Durchsuchen Sie dann das Protokoll, indem Sie git log mit --notes verwenden. Dadurch wird auch die Notiz eines Commits ausgegeben, die in diesem Fall die "Revisionsnummer" wäre.
  • Wenn Sie fertig sind, löschen Sie die temporären Notizen (NB: Ich bin nicht sicher, ob diese Notizen festgeschrieben sind oder nicht; sie werden nicht wirklich in git status angezeigt).

Beachten Sie zunächst, dass git einen Standardspeicherort für Notizen hat. Sie können jedoch auch eine ref (erence) für Notizen angeben, die sie in einem anderen Verzeichnis unter .git ablegen würde. In einem git-Repo-Ordner können Sie beispielsweise git notes get-ref aufrufen, um das folgende Verzeichnis anzuzeigen:

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

Zu beachten ist, dass Sie, wenn Sie notes add mit einem --ref arbeiten, diese Referenz anschließend erneut verwenden müssen - andernfalls erhalten Sie möglicherweise Fehler wie "Kein Hinweis für Objekt XXX ...".

In diesem Beispiel habe ich mich entschieden, die ref der Notizen "linrev" (für lineare Revision) zu nennen. Dies bedeutet auch, dass die Prozedur wahrscheinlich nicht mit bereits vorhandenen Notizen interferiert. Ich verwende auch den --git-dir-Schalter, da ich ein git-Neuling war, hatte ich einige Probleme damit, ihn zu verstehen - daher möchte ich mich "für später erinnern" :); und ich benutze auch --no-pager, um das Erscheinen von less bei der Verwendung von git log zu unterdrücken.

Angenommen, Sie befinden sich in einem Verzeichnis mit einem Unterordner myrepo_git, der ein git-Repository ist. man könnte tun:

### 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.

Zumindest in meinem speziellen Fall der vollständig linearen Historie ohne Verzweigungen scheinen die Revisionsnummern mit diesem Ansatz übereinzustimmen - und außerdem scheint es, dass dieser Ansatz die Verwendung von git log mit Revisionsbereichen erlaubt, während er immer noch die richtigen Revisionsnummern erhält - YMMV mit einem anderen Kontext, obwohl ...

Hoffe das hilft jemandem,
Prost!


EDIT: Ok, hier ist es etwas einfacher, mit git-Aliasnamen für die obigen Schleifen, genannt setlinrev und unsetlinrev; Wenn Sie sich in Ihrem Git-Repository-Ordner befinden,Beachten Sie das böse bash-Escapeing, siehe auch # 16136745 - Fügen Sie einen Git-Alias ​​hinzu, der ein Semikolon enthält): 

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

... Sie können also einfach git setlinrev aufrufen, bevor Sie versuchen, ein Protokoll mit linearen Revisionshinweisen zu erstellen. und git unsetlinrev, um diese Notizen zu löschen, wenn Sie fertig sind; ein beispiel aus dem git repo verzeichnis:

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

Die Zeit, die die Shell benötigt, um diese Aliase zu vervollständigen, hängt von der Größe des Repository-Verlaufs ab. 

3
sdaau

Für Personen mit einem Ant Build-Prozess können Sie eine Versionsnummer für ein Projekt mit git mit diesem Ziel generieren:

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

Das Ergebnis sieht so aus:

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

Das Dirty-Flag ist hier, wenn Sie keine Dateien festgeschrieben haben, wenn Sie die Versionsnummer generieren. Beim Erstellen/Packen Ihrer Anwendung muss sich normalerweise jede Codeänderung im Repository befinden.

2
Fredo

Im Git-Handbuch sind Tags eine brillante Antwort auf dieses Problem:

Das Erstellen eines kommentierten Tags in Git ist einfach. Der einfachste Weg ist zu Geben Sie -a an, wenn Sie den Tag-Befehl ausführen:

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

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

Check out 2.6 Git Basics - Tagging

1
DJ Far

Neben der SHA-1-ID des Commits hätten Datum und Uhrzeit der Serverzeit geholfen?

Etwas wie das:

feststellung um 11:30:25 am 19. August 2013 würde als .__ angezeigt werden. 6886bbb7be18e63fc4be68ba41917b48f02e09d7_19aug2013_113025

1
Manoranjan Sahu

Wir benutzen diesen Befehl, um Version und Revision von git zu erhalten:

git describe --tags --exact-match 2> /dev/null || git describe --always

Es kehrt zurück

  • commit-Hash als Revision, wenn kein Tag verwendet wird (z. B. gcc7b71f)
  • tag-Name als Version auf einem Tag (z. B. v2.1.0, wird für Releases verwendet)
  • tag-Name, Revisionsnummer seit dem letzten Tag und Commit-Hash, wenn nach einem Tag (z. B. v5.3.0-88-gcc7b71f)
1
thisismydesign

Postbuildereignis für Visual Studio

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

Nach langen Recherchen in den Online-Repositories stellte ich fest, dass es logisch keinen Unterschied zwischen einer Revisionsnummer und einer Festschreibungsnummer in Git gibt.

0