¿Cómo se logra un esquema de versionamiento numérico con Git?

Utilice etiquetas para marcar los confirmados con los números de versión:

git tag -a v2.5 -m 'Version 2.5'

Insertar etiquetas en sentido ascendente, esto no se hace de forma predeterminada:

git push --tags

Luego use el comando :

git describe --tags --long

Esto le da una cadena del formato:

v2.5-0-gdeadbee
^    ^ ^^
|    | ||
|    | |'-- SHA of HEAD (first seven chars)
|    | '-- "g" is for git
|    '---- number of commits since last tag
|
'--------- last tag

Esto ha surgido en algunos proyectos para mí. La mejor solución que he tenido hasta ahora es generar un número de versión como este:

x.y. < número de confirmaciones > .r < git-hash >

Normalmente, nuestro sistema de compilación lo genera utilizando una combinación de algún archivo o etiqueta estática para obtener los números de revisión principales, git rev-list HEAD | wc -l (que fue más rápido que usar git log ) y git rev-parse HEAD . El razonamiento fue el siguiente:

1. Necesitábamos la posibilidad de que el control de versiones de alto nivel ocurriera explícitamente (es decir, x.y)
2. Cuando ocurría el desarrollo paralelo, NUNCA necesitábamos generar el mismo número de versión.
3. Queríamos rastrear fácilmente de dónde venía una versión.
4. Cuando se fusionaron las líneas paralelas, queríamos que la nueva versión se resolviera más alto que cualquiera de las ramas.

El número 2 es invisible para la mayoría de las personas, pero es realmente importante y realmente es difícil con el control de fuente distribuido. SVN ayuda con esto dándole un solo número de revisión. Resulta que un conteo de compromiso es lo más cercano que puedes obtener, mientras que mágicamente también resuelves el # 4. En presencia de sucursales, esto todavía no es único, en cuyo caso agregamos el hash, que también resuelve perfectamente el # 3.

La mayor parte de esto fue para adaptarse a la implementación a través de pip de Python. Esto garantizó que pip install podría ser un poco extraño durante el desarrollo paralelo (es decir, los paquetes de personas en diferentes sucursales se mezclarían, pero de una manera determinista), pero después de las combinaciones, todo se solucionó. Salvo la presencia de una revisión o modificación expuesta, esto funcionó bastante bien para los requisitos anteriores.

En caso de que se lo pregunte, decidimos poner la r delante del hash debido a algunas rarezas con la forma en que el empaque de Python maneja las letras en los números de versión (es decir, son menos de 0, lo que haría que "1.3.10. a1234 "<" 1.3.10 "<" 1.3.10.1234 ").

Las versiones se identifican mediante el hashing del hash SHA1 de todos los archivos en el árbol de directorio almacenado en el momento del registro. Este hash se almacena junto con los hashes de los registros principales para que se pueda leer el historial completo.

Eche un vistazo al proceso de uso de 'git-describe' mediante GIT-VERSION-GEN y cómo puede agregar esto a través de su proceso de compilación cuando etiquete su lanzamiento.

Aquí hay un buen blog que da un ejemplo de cómo obtener lo que quieres:

enlace

Esto podría ser un poco excesivo, pero te diré cómo lo hacemos.

Utilizamos una estructura de bifurcación muy similar a esto .

Hudson construye nuestras ramas de "desarrollo" e incrementa los números de compilación a partir de 0. El número de compilación es único para cada proyecto y se etiqueta en el control de versión. La razón es para que pueda saber exactamente de qué desarrollo se desarrolló la construcción de la sucursal 42, por ejemplo (cada proyecto puede tener varias sucursales de desarrollo en paralelo, porque cada proyecto puede tener varios equipos trabajando en diferentes aspectos del proyecto).

Cuando decidimos que una compilación en particular es lo suficientemente buena como para ser lanzada, la confirmación que desencadenó esa compilación se etiqueta con un número de versión de lanzamiento, que se decide por marketing. Esto significa que a los equipos de desarrollo no les importa cuál es el número de la versión final y el marketing es libre de barajar los números de versión según lo crea conveniente. El número de versión final y el número de compilación están presentes en el producto lanzado.

Ejemplo: 2.1.0 build 1337

Esto significa que, para un lanzamiento de un producto específico, puedes decir cuál fue el último equipo que trabajó en él y puedes consultar a git para obtener todos los compromisos previos al lanzamiento para diagnosticar un problema si es necesario.

Pro Git en sección 7.2 "Atributos de Git" en la parte de expansión "Palabra clave" contiene un buen ejemplo del uso de filtros de borrones y limpieza para generar palabras clave de estilo RCS. Puede utilizar la misma técnica para incrustar some-version-string en el código, formateado y calculado de acuerdo con sus reglas . Aún puede usar git describe como punto de partida, pero tiene la posibilidad de transformarse a cualquier forma más apropiada y obtener de v2.5-14-feebdaed, por ejemplo, limpio 2.5.14