Was ist das Git 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, was die Revisionsnummer in Git entspricht .

Nehmen wir an, wir arbeiten an Version 3.0.8 und jeder Bugfix hat eine eigene Revisionsnummer, die wir verwenden können, wenn wir über diesen Bugfix sprechen. Also, wenn ich den Code in Git 3.0.8 markieren, 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.

   

Gute oder schlechte Nachrichten für Sie, dieser Hash ist die Revisionsnummer. Ich hatte auch Probleme damit, als ich von SVN zu Git wechselte.

Sie können “tagging” in git verwenden, um eine bestimmte Revision als “release” für eine bestimmte Version zu markieren, sodass Sie leicht auf diese Revision verweisen können. Schaut euch diesen Blog-Beitrag an .

Der Schlüssel zum Verständnis ist, dass Git keine Revisionsnummern haben kann – denke an die dezentrale Natur. Wenn Benutzer A und B sich beide für ihre lokalen Repositorys entscheiden, wie kann git dann eine sequenzielle Revisionsnummer zuweisen? A hat keine Kenntnis von B, bevor sie die Änderungen des anderen drücken / ziehen.

Eine andere Sache, die man sich ansehen sollte, ist die vereinfachte Verzweigung für Bugfix-Zweige:

Beginnen Sie mit einem Release: 3.0.8. Dann, nach dieser Veröffentlichung, mach folgendes:

git branch bugfixes308 

Dies wird einen Zweig für Bugfixes erstellen. Kasse der Filiale:

 git checkout bugfixes308 

Machen Sie nun alle gewünschten Bugfix-Änderungen.

 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:

 git merge bugfixes308 

Auf diese Weise haben Sie einen separaten release-spezifischen Bugfix-Zweig, aber Sie ziehen immer noch die Bugfix-Änderungen in Ihren Haupt-Devtrunk.

Mit modernem Git (1.8.3.4 in meinem Fall) und nicht mit Zweigen können Sie tun:

 $ git rev-list --count HEAD 68 

Der Befehl git describe erzeugt einen etwas menschlicheren Namen, der sich auf ein bestimmtes Commit bezieht. Zum Beispiel aus der Dokumentation:

Mit etwas wie git.git aktuellen Baum, bekomme ich:

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

dh der aktuelle Kopf meines “Parent” -Verzweigs basiert auf v1.0.4, aber da es darüber hinaus einige Commits hat, hat describe 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 in etwa einer SVN- “Revisionsnummer” gleichwertig angesehen werden.

Die anderen Poster haben Recht, es gibt keine “Revisionsnummer”.

Ich denke, der beste Weg ist, Tags für “Releases” zu verwenden!

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

Zeige die “aktuelle Revision” von “HEAD” wird simuliert mit:

git rev-list HEAD | wc -l

Aber was ist, wenn der Client mir sagt, dass es einen Fehler in “Revision” 1302 gibt?

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 }}\"'

mit git show-rev-number 1302 wird dann der Hash für die “revision” gedruckt 🙂

Ich habe vor einiger Zeit einen Blogbeitrag über diese “Technik” gemacht.

Git hat nicht das gleiche Konzept von Revisionsnummern wie Subversion. Stattdessen wird jeder mit einem Commit erstellte Snapshot durch eine SHA1-Prüfsumme markiert. Warum? Es gibt mehrere Probleme mit einem ausgeführten revno in einem verteilten Versionskontrollsystem:

Erstens, da die Entwicklung überhaupt nicht linear ist, ist das Anhängen einer Zahl eher schwierig als ein Problem, das auf eine Weise zu lösen ist, die Ihren Bedarf als Programmierer befriedigt. Der Versuch, dies durch Hinzufügen einer Nummer zu beheben, könnte schnell problematisch werden, wenn sich die Nummer nicht wie erwartet verhält.

Zweitens können Revisionsnummern auf verschiedenen Maschinen erzeugt werden. Dies macht die Synchronisation von Zahlen viel schwieriger – insbesondere da die Konnektivität in einer Richtung ist; Möglicherweise haben Sie nicht einmal Zugriff auf alle Computer mit dem Repository.

Drittens ist die Identität eines Commits (was das Commit ist) in git, das von dem nun nicht mehr existierenden OpenCM-System als Pionierarbeit geleistet wurde, gleichbedeutend mit seinem Namen (der SHA-ID). Dieses Konzept der Namensgebung = Identität ist sehr stark. Wenn Sie mit einem Commit-Namen in der Hand sitzen, identifiziert er auch das Commit auf fälschungssichere Weise. Dies wiederum ermöglicht es Ihnen, alle Ihre Commits mit dem Befehl git fsck auf den ersten initialen Fehler zu überprüfen.

Jetzt, da wir einen DAG (Directed Azyklic Graph) von Revisionen haben und diese den aktuellen Baum bilden, brauchen wir einige Werkzeuge, um Ihr Problem zu lösen: Wie unterscheiden wir verschiedene Versionen? Zuerst können Sie einen Teil des Hashs weglassen, wenn ein gegebenes Präfix, 1516bd , Ihr Commit eindeutig identifiziert. Aber das ist auch ziemlich erfunden. Stattdessen besteht der Trick darin, Tags und / oder Zweige zu verwenden. Ein Tag oder eine Verzweigung ist mit einem “gelben Stick it note” vergleichbar, den Sie an eine gegebene commit SHA1-ID anhängen. Tags sind im Wesentlichen dazu gedacht, sich nicht zu bewegen, während ein Zweig sich bewegt, wenn neue Commits an seinen HEAD gemacht werden. Es gibt Möglichkeiten, sich auf ein Commit um ein Tag oder eine Verzweigung zu beziehen, siehe die man-Seite von git-rev-parse.

Wenn Sie an einem bestimmten Codeabschnitt arbeiten müssen, werden in der Regel Änderungen vorgenommen, die als Zweig mit dem Namen eines Sprichworts verwendet werden sollten. Erstellen Sie viele Zweige (20-30 pro Programmierer ist nicht unbekannt, mit 4-5 veröffentlicht für andere zu arbeiten) ist der Trick für effektive Git. Jede Arbeit sollte als eigene Verzweigung beginnen und dann beim Testen zusammengeführt werden. Unveröffentlichte Zweige können komplett neu geschrieben werden und dieser Teil der Zerstörung der Geschichte ist eine Kraft von git.

Wenn die Veränderung akzeptiert wird, gefriert sie etwas und wird zur Archäologie. An diesem Punkt können Sie es markieren, aber häufiger wird ein Verweis auf das bestimmte Commit in einem Bug Tracker oder Issue Tracker über die sha1 Summe gemacht. Tags sind tendenziell für Versionsbumps und Verzweigungspunkte für Wartungszweige (für alte Versionen) reserviert.

Wenn Sie interessiert sind, habe ich Versionsnummern automatisch von Git-Infos hier unter dem Format verwaltet

 ..-b 

Wo Build ist die Gesamtzahl der Commits. Sie werden den interessanten Code im 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) 

Eine Bash-function:

 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 

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

Dies habe ich in meinem Makefile gemacht, basierend auf anderen Lösungen. Hinweis: Dies gibt Ihrem Code nicht nur eine Revisionsnummer, sondern hängt auch den Hash an, mit dem Sie das Release 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 

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

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

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

Das Problem mit dem Git Hash als Build Nummer ist, dass es nicht monoton ansteigt. OSGi schlägt vor, einen Zeitstempel für die Build-Nummer zu verwenden. Es sieht so aus, als könnte die Anzahl der Commits für die Verzweigung anstelle der Subversions- oder der Forforce-Änderungsnummer verwendet werden.

Ich möchte nur einen anderen möglichen Ansatz erwähnen – und das ist, indem ich git git-notes (1) benutze, das seit 1.6.6 ( Note to Self-Git ) existiert (ich benutze git Version 1.7.9.5).

Im Grunde habe ich git svn , um ein SVN-Repository mit linearer Historie (kein Standardlayout, keine Verzweigungen, keine Tags) zu klonen, und ich wollte Revisionsnummern im geklonten git Repository vergleichen. Dieser Git Clone hat standardmäßig keine Tags, daher kann ich git describe nicht verwenden. Die Strategie hier würde wahrscheinlich nur für lineare Geschichte funktionieren – nicht sicher, wie es sich bei Fusionen ergeben würde usw .; aber hier ist die Grundstrategie:

  • Frag git rev-list nach einer Liste aller Commit-Historien
    • Da rev-list standardmäßig in “umgekehrter chronologischer Reihenfolge” ist, verwenden wir den Schalter --reverse , um eine Liste der Commits zu erhalten, die zuerst nach dem ältesten sortiert werden
  • Verwenden Sie bash Shell zu
    • Erhöhen Sie eine Counter-Variable bei jedem Commit als Revisionszähler,
    • Generiere und füge eine “temporäre” Git Note für jedes Commit hinzu
  • Durchsuchen Sie das Protokoll anschließend mit git log mit --notes , wodurch auch eine Commit-Notiz --notes wird, die in diesem Fall die “Revisionsnummer” wäre.
  • Wenn du fertig bist , lösche die temporären Notizen ( NB: Ich bin mir nicht sicher, ob diese Notizen festgeschrieben sind oder nicht; sie werden nicht wirklich im git status )

Nehmen wir als Erstes an, dass git eine Standardposition für Notizen hat – Sie können aber auch eine Referenz (erence) für Notizen angeben, die sie in einem anderen Verzeichnis unter .git speichern würde; zum Beispiel, während Sie in einem git Repo-Ordner sind, können Sie git notes get-ref aufrufen git notes get-ref zu sehen, welches Verzeichnis das sein wird:

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

--ref Sie, dass Sie, wenn Sie notes add mit einer --ref notes add , diese Referenz später auch wieder verwenden müssen – andernfalls können Fehler wie ” Keine Notiz gefunden für Objekt XXX … ” auftreten.

Für dieses Beispiel habe ich gewählt, den Verweis der Notizen “linrev” (für die lineare Revision) aufzurufen – dies bedeutet auch, dass es unwahrscheinlich ist, dass das Verfahren bereits vorhandene Notizen beeinträchtigt. Ich benutze auch den --git-dir Schalter, da ich ein git Neuling bin, hatte ich einige Probleme, es zu verstehen – also möchte ich mich “für später erinnern” :) ; und ich benutze auch --no-pager , um den Launch von less zu unterdrücken, wenn ich git log benutze.

Angenommen, Sie befinden sich in einem Verzeichnis mit einem Unterordner myrepo_git der ein git Repository ist. könnte man 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 einer vollständig linearen Geschichte 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 immer noch die richtigen Revisionsnummern erhalten werden - YMMV mit einem anderen Kontext, obwohl ...

Hoffe, das hilft jemandem,
Prost!


EDIT: Ok, hier ist es ein bisschen einfacher, mit git Alias ​​für die oben genannten Schleifen, genannt setlinrev und unsetlinrev ; Wenn Sie in Ihrem git-Repository-Ordner sind, beachten Sie ( Beachten Sie die gemeine bash Escape-function , 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 

... so können Sie einfach git setlinrev bevor Sie versuchen, Logs mit linearen Revisionsnotizen git setlinrev ; 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.

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

                  Revision : ${version.revision}      Hash : ${version.hash}      Branch : ${version.branch}          Date : ${version.date}  Version : ${version} version = ${version}  

Das Ergebnis sieht folgendermaßen 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 schmutzige Flag ist hier, wenn Dateien beim Generieren der Versionsnummer nicht festgeschrieben wurden. Normalerweise müssen Sie beim Erstellen / Packen Ihrer Anwendung jede Codeänderung im Repository vornehmen.

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

Etwas wie das:

commit passiert um 11:30:25 am 19 aug 2013 würde als 6886bbb7be18e63fc4be68ba41917b48f02e09d7_19aug2013_113025 zeigen

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

Das Erstellen eines kommentierten Tags in Git ist einfach. Der einfachste Weg ist die Angabe von -a, wenn Sie den Befehl tag 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 Grundlagen – Tagging

Nach langem Recherchieren in den Online-Repositories stellte ich fest, dass in Git kein Unterschied zwischen einer Revisionsnummer und einer Commit-Nummer besteht.