Usando git para controlar las versiones semánticas

En git me gustaría "marcar" ciertos commits. Por ejemplo, me gustaría "marcar" confirmaciones que rompan la API REST del software, de modo que pueda recordar dar con la versión principal no. (Yo uso versiones semánticas ).

Idealmente, debería poder emitir un command git para ver si alguna confirmación desde la última versión / label contiene una "marca", porque entonces sé que la próxima versión no. debe chocar con el no principal.

La "marca" no es una label (en términos de git), ya que las tags son únicas. Anticipo que podría haber varias "marcas" idénticas desde la última versión, para indicar que la API está rota.

La solución actual es escribir "MAJOR:" o "MENOR:" en los posts de confirmación.

¿Hay alguna sugerencia sobre cómo puedo usar git para esto?

Es cierto que los nombres de las tags deben ser únicos, pero hay un número infinito de nombres de tags únicos que comienzan con mark/ , como mark/1 , mark/2 , y así sucesivamente. O bien, puede usar nombres de reference que no estén en refs/tags/ ; o podría usar las "notas" de Git, aunque es más fácil detectar si una label u otra reference es un antepasado de una confirmación y un descendiente de otra:

 highmark=$(git for-each-ref --format='%(refname)' refs/marks | wc -l) nextmark=$((highmark + 1) git update-ref refs/marks/m$nextmark HEAD 

(Esto supone que nunca se borrará, con git update-ref -d , cualquiera de estas marcas; si realiza el cálculo de "marca máxima" debe encontrar el número más alto existente en lugar de simplemente contar). Para probar si mark $ N está "entre" la label T1 y HEAD:

 if git merge-base --is-ancestor T1 refs/marks/m$N && git merge-base --is-ancestor refs/marks/m$N HEAD; then ... mark N is at or beyond tag T1 and at or before HEAD ... else ... mark N is not between those two points (inclusive) ... fi 

Alternativamente, puede almacenar, dentro o fuera del repository, y si está dentro del repository, en un blob simple, un blob es el formatting interno de Git para datos de file sin procesar, un file que simplemente contiene los identificadores hash de todas las confirmaciones "marcadas". El file en sí se puede almacenar en una confirmación labelda o referenceda de otro modo que puede, pero no tiene que ser, en cualquier twig; o puede labelr el blob en sí mismo. Por ejemplo:

 git show marks > /tmp/all-marks # extract existing marks git rev-parse HEAD >> /tmp/all-marks # add a new mark git tag -f marks $(git hash-object -w --stdin < /tmp/all-marks) 

Si almacena el blob bajo un commit, puede mantener un historial de marcas haciendo nuevos commits para cada nuevo file actualizado de "IDs marcadas". Esto es en cierto modo similar a la forma en git notes funcionan las git notes , pero en lugar de escribir files cuyos nombres son los ID de confirmaciones, simplemente está escribiendo un file llamado "marcas" (almacenado a través de un tree al que apunta el compromiso , que la reference de la marca, ya sea una label como refs/tags/marks , como en el ejemplo de label anterior, o una reference como refs/marks , como las references de la serie m anterior, pero solo con una reference). Dado que cada confirmación tiene un puntero principal, puede save la confirmación anterior, que guarda el tree anterior, que guarda el blob / marcas-file anterior, e incluso puede ejecutar git log en estas confirmaciones, para ver quién actualizó las marcas, cuando , etc.


1 Bueno, finito, pero limitado solo por espacio de disco y patrones de nombre. El patrón propuesto aquí, contando decimales dentro de los nombres de files en un solo espacio de nombres, solo puede contar hasta 10 254 en los filesystems Unix-ish típicos, con su límite de 255 bytes de nombre-componente-longitud. En términos prácticos, es probable que no desee ir más allá de mil o más antes de hacer los nombres jerárquicos, por ejemplo, refs/marks/123/456/789 una vez que se encuentre en unos pocos millones de compromisos marcados.

Los sistemas operativos también imponen longitudes de ruta máximas, pero se quedarán sin ID de confirmación mucho antes de llegar a esos: 2 160 es solo 1 461 501 637 330 902 918 203 684 832 716 283 019 655 932 542 976, o aproximadamente 1.462 sexdecillion en el corto Nomenclatura de escala . Peor aún, la probabilidad de que se produzca una colisión hash es muy alta después de unos pocos trillones de objects, por lo que solo debemos contar hasta 10 18 .