Secuenciación de compilación al utilizar el control de versiones distribuido

Question

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

Me gustaría pasar al uso de un sistema distribuido (probablemente git) para que sea más fácil realizar sucursales y trabajar desde casa.(Ambas cosas son perfectamente posibles con Perforce, pero el flujo de trabajo de git tiene algunas ventajas). Entonces, aunque el "desarrollo tributario" se distribuiría y no se referiría a una secuencia de revisión común, aún mantendríamos un repositorio de git maestro en el que se guardarían todos los cambios. necesita alimentar antes de crear una compilación.

¿Cuál es la mejor manera de preservar los identificadores de compilación estrictamente crecientes?La forma más sencilla que se me ocurre es tener algún tipo de gancho posterior a la confirmación que se active cada vez que se actualice el repositorio maestro y registre (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 distribuye identificadores.(Digo "base de datos", pero probablemente lo haría con etiquetas git y simplemente buscaría el siguiente número de etiqueta disponible o algo así.Entonces la "base de datos" realmente sería .git/refs/tags/build-id/.)

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

Answer 1

Apoyo la sugerencia de usar git describe.Siempre que tenga una política de versiones sensata y no haga ninguna locura con su repositorio, git describe siempre será monótono (al menos tan monótono como puedas ser, cuando tu historial de revisiones 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

La salida de git describe consta de los siguientes componentes:

1. La etiqueta más nueva a la que se puede acceder desde la confirmación que solicita describir
2. El número de confirmaciones entre la confirmación y la etiqueta (si es distinto de cero)
3. La identificación (abreviada) de la confirmación (si el número 2 no es cero)

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

Answer 2

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 sha1 actual a ese número para agregar singularidad.

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 rebase, pero el rebase es una operación "peligrosa" de todos modos.

Answer 3

    git rev-list BRANCHNAME --count

esto requiere muchos menos recursos que

    git log --pretty=oneline | wc -l

Answer 4

git tag puede ser suficiente para lo que necesitas.Elija un formato de etiqueta que todos acepten no utilizar de otro modo.

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

Answer 5

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 ID de confirmación abreviada del encabezado de la rama.

Es de suponer que tiene una única rama desde la que realiza lanzamientos de compilación controlados.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 en relación con la etiqueta conocida.Luego puede usar el resultado de git describe tal cual o si realmente desea un solo número, puede usar una expresión regular para eliminar el número de la etiqueta.

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

p.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 6

Yo usaría "Etiquetas". Cree una etiqueta cada vez que tenga una compilación exitosa (o incluso fallida) y podrá identificar esa compilación para siempre.No es exactamente lo mismo, pero proporciona esos números de compilación y, al mismo tiempo, brinda los beneficios del desarrollo distribuido.

Answer 7

Como probablemente sepas, git calcula un hash (un número) que identifica de forma única un nodo del historial.Usarlos, aunque no son estrictamente crecientes, parece ser suficiente.(Aún mejor, ellos siempre corresponden a la fuente, por lo que si tienes el hash, tienes el mismo código). Son números grandes, pero en su mayoría puedes arreglártelas con aproximadamente 6 de los dígitos iniciales.

Por ejemplo,

Ese error se solucionó en 064f2ea...

Answer 8

Con Mercurial puedes 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