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

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 less 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 repository maestro se actualice, y registra (el hash de) el nuevo object de tree (¿o el object de confirmación?) Soy nuevo en git) con una database centralizada que entrega identificadores. (Digo "database", pero probablemente lo haría con tags git, y simplemente busco el siguiente número de label disponible o algo así. Así que la "database" 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.

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 repository, git describe siempre será monótono (al less tan monótona como sea posible, cuando su historial de revisión es un DAG en lugar de un tree) 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 label más nueva accesible desde el compromiso que está pidiendo que describa
  2. El número de confirmaciones entre la confirmación y la label (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 label, haciendo que git describe también adecuado para lanzamientos de producción.

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 label, y maneja automáticamente las fusiones.

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

  git rev-list BRANCHNAME --count 

esto es mucho less intensivo en resources que

  git log --pretty=oneline | wc -l 

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

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

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

Es de suponer que tiene una única twig que realiza liberaciones controladas de compilation desactivadas. En este caso, labelría una confirmación temprana con un formatting de label conocido y luego usaría git describe con la opción –match para describir el HEAD actual relativo a una label 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 label.

Suponiendo que nunca rebobinas la twig, 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' 

Usaría "Etiquetas" Crea una label siempre que tengas una compilation exitosa (o incluso sin éxito), y podrás identificar esa compilation para siempre. No es exactamente lo mismo, pero proporciona esos numbers de compilation, al time que proporciona los beneficios del desarrollo distribuido.

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 numbers grandes, pero la mayoría puedes salir con 6 dígitos de los principales.

Por ejemplo,

Ese error fue reparado en 064f2ea …

Con Mercurial puede usar el siguiente command:

 # 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