tipos - ¿qué tipo de sistema control de versiones es git?

Construya la secuencia cuando usa el control de versión distribuida

Question

En este momento, estamos usando Perforce para el control de versiones. Tiene la característica útil de un número de cambio estrictamente creciente que podemos usar para referirnos a construcciones, por ejemplo, "obtendrás la corrección de errores si tu construcción es al menos 44902".

Me gustaría cambiar a usar un sistema distribuido (probablemente git) para facilitar la bifurcación y el trabajo desde casa. (Ambos son perfectamente posibles con Perforce, pero el flujo de trabajo de git tiene algunas ventajas.) Así que, aunque el "desarrollo tributario" se distribuiría y no se referiría a una secuencia de revisión común, mantendríamos un repo master git que todos los cambios serían Necesito alimentarme antes de que se cree una construcción.

¿Cuál es la mejor manera de preservar los ID de construcción estrictamente crecientes? La forma más directa en que puedo pensar es tener algún tipo de enlace post-commit que se activa siempre que el repositorio maestro se actualice, y registra (el hash de) el nuevo objeto de árbol (¿o el objeto de confirmación?) Soy nuevo en git) con una base de datos centralizada que entrega identificadores. (Digo "base de datos", pero probablemente lo haría con etiquetas git, y simplemente busco el siguiente número de etiqueta disponible o algo así. Así que la "base de datos" sería realmente .git / refs / tags / build-id /. )

Esto es viable, pero me pregunto si existe una manera más fácil, ya implementada, o estándar / de "mejores prácticas" para lograr esto.

Answer 1

Deberías investigar git describe . Proporciona una cadena única que describe la rama actual (o cualquier ID de confirmación pasada) en términos de la última etiqueta anotada, el número de confirmaciones desde esa etiqueta y una identificación de confirmación abreviada del jefe de la sucursal.

Es de suponer que tiene una única rama que realiza liberaciones controladas de compilación desactivadas. En este caso, etiquetaría una confirmación temprana con un formato de etiqueta conocido y luego usaría git describe con la opción --match para describir el HEAD actual relativo a una etiqueta conocida. Luego puede usar el resultado de git describe como está o si realmente quiere un solo número, puede usar una expresión regular para cortar el número de la etiqueta.

Suponiendo que nunca rebobinas la rama, el número de confirmaciones siguientes siempre identificará un punto único en el historial de la sucursal.

ej. (usando bash o similar)

# make an annotated tag to an early build in the repository:
git tag -a build-origin "$some_old_commitid"

# describe the current HEAD against this tag and pull out a build number
expr "$(git describe --match build-origin)" : ''build-origin-/([0-9]*/)-g''

Answer 2

Usaría "Etiquetas" Crea una etiqueta siempre que tengas una compilación exitosa (o incluso sin éxito), y podrás identificar esa compilación para siempre. No es exactamente lo mismo, pero proporciona esos números de compilación, al tiempo que proporciona los beneficios del desarrollo distribuido.

Answer 3

git tag puede ser suficiente para lo que necesita. Escoja un formato de etiqueta que, de otro modo, todos aceptarán no usar.

Nota: cuando etiqueta localmente, un git push no actualizará las etiquetas en el servidor. Use git push --tags para eso.

Answer 4

En segundo lugar la sugerencia de usar git describe . Siempre que tenga una política de control de versiones en su sano juicio y no haga nada loco con su repositorio, git describe siempre será monótono (al menos tan monótona como sea posible, cuando su historial de revisión es un DAG en lugar de un árbol) y único.

Una pequeña demostración:

git init
git commit --allow-empty -m''Commit One.''
git tag -a -m''Tag One.'' 1.2.3
git describe    # => 1.2.3
git commit --allow-empty -m''Commit Two.''
git describe    # => 1.2.3-1-gaac161d
git commit --allow-empty -m''Commit Three.''
git describe    # => 1.2.3-2-g462715d
git tag -a -m''Tag Two.'' 2.0.0
git describe    # => 2.0.0

El resultado de git describe consta de los siguientes componentes:

1. La etiqueta más nueva accesible desde el compromiso que está pidiendo que describa
2. El número de confirmaciones entre la confirmación y la etiqueta (si no es cero)
3. La identificación (abreviada) de la confirmación (si # 2 no es cero)

# 2 es lo que hace que la salida sea monótona, la # 3 es lo que la hace única. # 2 y # 3 se omiten, cuando el compromiso es la etiqueta, haciendo que git describe también adecuado para lanzamientos de producción.

Answer 5

Como probablemente sepa, git calcula un hash (un número) que identifica de manera única un nodo del historial. Usando estos, aunque no están aumentando estrictamente, parece que sería lo suficientemente bueno. (Mejor aún, siempre corresponden a la fuente, por lo que si tienes el hash, tienes el mismo código.) Son números grandes, pero la mayoría puedes salir con 6 dígitos de los principales.

Por ejemplo,

Ese error fue reparado en 064f2ea ...

Answer 6

Con Mercurial puede usar el siguiente comando:

# get the parents id, the local revision number and the tags
[yjost@myhost:~/my-repo]$ hg id -nibt
03b6399bc32b+ 23716+ default tip

Ver hg identificar

Answer 7

Se podría generar un número monótonamente creciente correspondiente al compromiso actual con

git log --pretty=oneline | wc -l

que devuelve un solo número. También puede agregar el sha1 actual a ese número, para agregar unicidad.

Este enfoque es mejor que git describe , porque no requiere que agregue ninguna etiqueta, y maneja automáticamente las fusiones.

Podría tener problemas con el rebasado, pero la rebase es una operación "peligrosa" de todos modos.

Answer 8

    git rev-list BRANCHNAME --count

esto es mucho menos intensivo en recursos que

    git log --pretty=oneline | wc -l