¿Cuál es el equivalente de Git para el número de revisión?

https://stackoverflow.com/questions/4120001

29-09-2019
|

Pregunta

Use SVN en el trabajo, pero para mis proyectos personales que decidió usar Git. Así que he instalado Git ayer, y me pregunto ¿cuál es el número Revisión equivalente en Git .

digamos que el trabajo de Let en la versión 3.0.8 y cada corrección de errores tiene su propio número de revisión que podemos utilizar cuando hablamos de esta corrección de errores. Así que si puedo etiquetar el código en Git 3.0.8 a lo que entonces puedo usar como un número de revisión o algún otro tipo más detallado de identificación? Encuentro el hash no es tan fácil de usar para los seres humanos.

Solución

Buenas o malas noticias para usted, que hash es el número de revisión. También tuve problemas con esto cuando hice el cambio desde SVN a GIT.

Se puede usar "etiquetar" en git tag a un determinado número de revisión como la "liberación" para una versión específica, por lo que es fácil para referirse a esa revisión. Echa un vistazo a este entrada de blog .

La clave para entender es que git no puede tener números de revisión - pensar en la naturaleza descentralizada. Si los usuarios A y B son ambos comprometiendo a sus repositorios locales, ¿cómo puede GIT razonablemente asignar un número de revisión secuencial? A no tiene conocimiento de B antes de empujar / tirar los cambios del otro.

Otra cosa a tener en cuenta es simplificar la ramificación de las ramas de corrección de errores:

Comenzar con un comunicado de: 3.0.8. Entonces, después de que la liberación, hacer esto:

git branch bugfixes308

Esto creará una rama de corrección de errores. Pedido de la rama:

git checkout bugfixes308

Ahora hace ninguna corrección de errores cambios que desee.

git commit -a

Commit, y de vuelta al interruptor de la rama principal:

git checkout master

A continuación, tirar en esos cambios con respecto a la otra rama:

git merge bugfixes308

De esta manera, usted tiene una rama específica de corrección de errores de liberación separado, pero todavía se está tirando de los cambios de corrección de errores en su tronco principal prog.

Otros consejos

Con Git moderna (1.8.3.4 en mi caso) y no la utilización de saltos que puede hacer:

$ git rev-list --count HEAD
68

El git describe comando crea un nombre legible por un poco más humana que se refiere a una específica comprometerse. Por ejemplo, a partir de la documentación:

Con algo como árbol actual git.git, me sale:
[torvalds@g5 git]$ git describe parent
v1.0.4-14-g2414721
es decir. el actual jefe de mi sucursal "padre" se basa en v1.0.4, pero ya que tiene un par de confirmaciones encima de eso, ha añadido describir el número de confirmaciones adicionales ( "14") y un nombre de objeto abreviado para el comprometa ( "2414721") en el extremo.

Como siempre y cuando utilice etiquetas con sensatez nombrados para etiquetar comunicados particulares, esto puede ser considerado más o menos equivalente a un SVN "número de revisión".

Los otros carteles están en lo cierto, no hay "-número de revisión".

creo que la mejor manera es utilizar etiquetas para "comunicados"!

Pero me hizo uso de los siguientes para los números falsa de revisión (sólo para clientes vean las revisiones y el progreso, ya que quería tener las mismas revisiones crecientes de Git, ya que donde el uso de la subversión ).

Mostrar la "versión actual" de "HEAD" se simula mediante el uso de lo siguiente:

git rev-list HEAD | wc -l

Pero, ¿y si el cliente me dice que hay un error en la "revisión" 1302?

Para esto añade lo siguiente a la sección [alias] de mi ~ / .gitconfig:

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

usando git show-rev-number 1302 se imprimirá en el de hash para la "revisión":)

Me hizo una blog (en alemán) acerca de eso "técnica" hace algún tiempo.

Git no tiene el mismo concepto de los números de revisión como la subversión. En vez cada instantánea dada hecha con un COMMIT es etiquetado por una suma de comprobación SHA1. ¿Por qué? Hay varios problemas con un revno se ejecuta en un sistema de control de versiones distribuido:

En primer lugar, puesto que el desarrollo no es lineal en absoluto, la unión de un número es bastante duro como un problema a resolver de una manera que satisfaga sus necesidades como programador. Tratar de solucionar este problema mediante la adición de un número rápidamente podría convertirse en un problema cuando el número no se comporta como se espera.

En segundo lugar, los números de revisión se puede generar en diferentes máquinas. Esto hace que la sincronización de números mucho más difícil - sobre todo porque la conectividad es unidireccional; Ni siquiera se puede tener acceso a todas las máquinas que tiene el repositorio.

En tercer lugar, en Git, algo por primera vez por el sistema OpenCM ahora difunto, el Identidad de una confirmación (lo que el commit es) es equivalente a su Nombre (SHA carné de identidad). Este = nombrar identidad concepto es muy fuerte. Cuando uno se sienta con un nombre comprometerse en la mano sino que también identifica el commit de una forma infalsificable. Esto a su vez permite comprobar todas sus confirmaciones de nuevo a la primera inicial para la corrupción con el comando git fsck.

Ahora, ya que tenemos un DAG (Dirigido acíclicos Gráfico) de las revisiones y éstos constituyen el árbol actual, necesitamos algunas herramientas para resolver su Problema: ¿Cómo discriminamos diferentes versiones. En primer lugar, se puede omitir parte del hash si un prefijo dado, 1516bd por ejemplo, identifica su confirmación. Pero esto es también bastante artificiales. En cambio, el truco es usar etiquetas y o ramas. Una etiqueta o una rama es similar a un "palo que la nota amarilla" se adjunta a un determinado comprometerse SHA1-id. Las etiquetas son, en esencia, destinados a ser que no se mueve mientras que una rama se moverá cuando se hacen nuevos compromete a la cabeza. Hay maneras de referirse a un compromiso en torno a una etiqueta o una rama, ver la página del manual de git-rev-parse.

Por lo general, si tiene que trabajar en una pieza de código específica, esa pieza es sometidos a cambios y debe ser, como tal, una rama con un nombre de tema diciendo. La creación de un montón de ramas (20-30 por programador no es insólito, con un poco de 4-5 publicado por los demás a trabajar) es el truco para git eficaz. Cada pieza de trabajo debe comenzar como su propia rama y luego se fusionó en cuando se pone a prueba. ramas no publicados pueden ser reescritos por completo y esta parte de la destrucción de la historia es una fuerza de git.

Cuando el cambio es aceptado en master que algo se congela y se convierte en la arqueología. En ese punto, puede etiquetar, pero más a menudo se comprometen se hace una referencia a lo particular en un gestor de fallos o seguimiento de incidencias a través de la suma SHA1. Etiquetas tienden a ser reservados para los golpes de versión y puntos de ramificación de las ramas de mantenimiento (para las versiones antiguas).

Si usted está interesado números de versión, que gestiona automáticamente desde git informaciones aquí bajo el formato

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

donde la construcción es el número total de confirmaciones. Verá el código interesante en el Makefile . Aquí está la parte correspondiente para acceder a la parte diferente del número de versión:

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)

Una función de 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}
}

salidas algo así como

$ git_rev
2:0f8e14e:20130220

Es decir

commit_count:last_abbrev_commit:date_YYmmdd

El SHA1 hash de la cometen es el equivalente a un número Subversion revisión.

Esto es lo que hice en mi makefile apoyan en otras soluciones. Nota no sólo da su código un número de revisión, sino que también añade el hash que le permite recrear la liberación.

# 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

El problema de usar el hash git como el número de compilación es que no es monótona creciente. OSGi sugiere el uso de un sello de tiempo para el número de compilación. Parece que el número de commit en la rama podría ser utilizado en lugar del número de cambio de la subversión o por fuerza.

Me escribió algunas utilidades PowerShell para recuperar información de la versión de Git y simplificar el etiquetado

funciones: Get-LastVersion, Get-Revisión, 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
}

Cada cometer tiene un hash único. Aparte de eso no hay números de revisión en git. Vas a tener que compromete la etiqueta usted mismo si quieres más facilidad de uso.

Sólo me gustaría señalar otro posible enfoque - y que es mediante el uso de git Git-notas (1) , que existe desde v 1.6.6 ( Nota al uno mismo -. Git ) (estoy usando git versión 1.7.9.5)

Básicamente, he usado git svn para clonar un repositorio SVN con historia lineal (sin diseño estándar, sin ramas, sin etiquetas), y quería comparar los números de revisión en el repositorio git clonado. Este clon de git no dispone de etiquetas por defecto, así que no puedo usar git describe. La estrategia aquí es probable que trabajar sólo para la historia lineal - no está seguro de cómo iba a salir con fusiones, etc .; pero aquí es la estrategia básica:

Haga git rev-list para la lista de todos comprometerse historia
- Desde rev-list es por defecto en "orden cronológico inverso", que haría uso de su interruptor --reverse para obtener la lista de confirmaciones ordenadas según la más antigua primero
Uso bash Shell para
- aumentar una variable de contador en cada cometer como un contador de revisión,
- generar y poner una nota git "temporal" para cada comprometerse
A continuación, busque el registro mediante git log con --notes, que también volcar una nota de cometer, que en este caso sería el "número de revisión"
Cuando haya terminado, borrar las notas temporales ( Nota: No estoy seguro de si estas notas están comprometidos o no; en realidad no muestran en git status )

En primer lugar, vamos a notar que git tiene una ubicación predeterminada de notas - pero también se puede especificar un ref (rencia) para las notas - que almacenarlos en un directorio diferente bajo .git; por ejemplo, mientras que en una carpeta git de recompra, puede llamar git notes get-ref para ver qué directorio que va a ser:

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

Lo que hay que hacer notar es que si notes add con un --ref, también debe utilizar después de que la referencia de nuevo - de lo contrario puede obtener errores como " No se encontraron resultados para nota objeto XXX ... " .

En este ejemplo, he optado por llamar a la ref de la notas "linrev" (para la revisión lineal) - esto también significa que no es probable que el procedimiento va a interferir con las notas ya existentes. También estoy usando el interruptor --git-dir, ya que al ser un novato git, tuve algunos problemas para comprender que - por lo que me gustaría "recordar para más adelante" :); y yo también uso --no-pager para suprimir el desove de less cuando se utiliza git log.

Por lo tanto, asumiendo que usted está en un directorio, con una subcarpeta myrepo_git que es un repositorio git; se podría hacer:

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

Por lo tanto, al menos en mi caso específico de la historia totalmente lineal sin ramas, los números de revisión parecen coincidir con este enfoque - y, además, parece que este planteamiento permitirá el uso de git log con rangos de revisiones, mientras que sigue recibiendo la derecha números de revisión - YMMV con un contexto diferente, aunque ...

Espero que esto ayude a alguien, España Saludos!

EDIT: Ok, aquí es un poco más fácil, con el alias git para los bucles anteriores, llamada setlinrev y unsetlinrev; cuando se encuentra en su carpeta del repositorio git, hacer (_{Nota del bash desagradable escapar, véase también # 16136745 - Añadir un alias de Git que contienen un punto y coma}):

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

... por lo que puede simplemente invocar git setlinrev antes de tratar de hacer registro de la participación de notas de revisión lineales; y git unsetlinrev para eliminar esas notas cuando haya terminado; un ejemplodesde el interior del directorio de repositorio git:

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

El tiempo que tomaría la cáscara para completar estos alias, dependerá del tamaño de la historia del repositorio.

Para las personas que tienen una Ant proceso de construcción, se puede generar un número de versión para una proyecto sobre git con este objetivo:

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

El resultado es similar al siguiente:

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

La bandera sucia es aquí cuando se tiene el archivo (s) que no esté comprometido cuando se genera el número de versión. Porque por lo general, cuando se genera / empaquetar la aplicación, cada modificación del código tiene que estar en el repositorio.

Junto con el SHA-1 Identificación de la confirmación, fecha y hora de la hora del servidor habrían ayudado?

Algo como esto:

commit ocurrió en 11:30:25 el 19 ago 2013 equivaldrían mostrar como 6886bbb7be18e63fc4be68ba41917b48f02e09d7_19aug2013_113025

Desde el manual de Git, las etiquetas son una brillante respuesta a este problema:

Creación de una etiqueta anotada en Git es sencillo. La forma más fácil es   especifique -a cuando se ejecuta el comando de la etiqueta:

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

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

2.6 Fundamentos de Git - Etiquetado

Estamos utilizando este comando para obtener la versión y revisión de git:

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

Devuelve

cometer de hash como la revisión cuando no se utiliza el etiquetado (por ejemplo gcc7b71f)
nombre de etiqueta como la versión cuando en una etiqueta (por ejemplo v2.1.0, que se utiliza para las versiones)
nombre de la etiqueta, número de revisión desde la última etiqueta y comprometerse de hash cuando después de una etiqueta (por ejemplo v5.3.0-88-gcc7b71f)

Post caso de construcción para Visual Studio

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

Considere utilizar

`git-rev-label`

Entrega información sobre Git revisión del repositorio en formato como master-c73-gabc6bec. Puede llenar cadena de plantilla o un archivo con las variables de entorno y la información de Git. Útil para proporcionar información sobre la versión del programa: rama, la etiqueta, se comprometen hachís, compromete cuentan, estado sucio, fecha y hora. Una de las cosas más útiles es el recuento de las confirmaciones, que no toman en cuenta fusionaron ramas -. Sólo primer padre

< img src = "https://gitlab.com/kyb/git-rev-label/raw/master/demo/demo-part2-walk-over-commits.gif" alt>

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow