¿Git registra el historial de cabezas de ramas?

Question

Las cabezas de bifurcación y las etiquetas de Git son punteros a commits, y estos punteros se pueden mover implícitamente (después de commit) o explícitamente (después de branch -m).

¿Git registra el historial del estado de estos punteros?

Veo por lo menos dos razones para esto:

• para ver el estado de la cesión temporal hace dos días, incluyendo, cuando señalaron los directores de las sucursales.
• Para asegurarse de que no se pierda ningún historial porque alguien movió un encabezado de tal manera que algunos commits se vuelvan inalcanzables.

Tenga en cuenta que lo anterior es posible en Mercurial porque almacena el nombre de la rama en cada confirmación.

De nuevo, en Git, ¿el contenido de .git/refs/version está controlado, o hay alguna forma de hacerlo?

(Estoy tratando de decidirme por Mercurial o Git para un equipo, y quiero asegurarme de que se registren todos los cambios en el repositorio compartido, incluidos los refs. No me importa lo que los desarrolladores hagan a sus privados repos.)

Gracias.

Answer 1

No están versionadas, pero la función reflog conserva un historial local que puede utilizar para deshacer errores. Sin embargo, si alguien "rebobina" una cabecera de rama para descartar algunas confirmaciones desde el final, será inmediatamente obvio cuando otro desarrollador intente actualizar su extracción de esa rama, porque Git se negará a realizar ese cambio localmente a menos que se use --force. Simplemente puede volver a enviar los commits al repositorio compartido en ese punto.

Answer 2

Existen extensiones para servidores Git empresariales como Gerrit que versionarán el historial de sucursal. Si una rama se elimina o se actualiza de forma no rápida (push -f) , respaldará la versión anterior bajo una referencia especial para que puedan restaurarse si es necesario y no se podará con la recolección de elementos no utilizados. Los administradores de Gerrit aún pueden eliminar confirmaciones seleccionadas si es necesario por razones legales.

Answer 3

Hay dos maneras:

git reflog 

y:

git log -g 

equivalente con el primer caso:

git log --oneline -g