tag - ¿Cuáles son las consecuencias prácticas de reescribir la historia de GIT?

git tag

Question

Nuestro proyecto ha estado usando git durante una semana aproximadamente, y todos lo estamos disfrutando mucho (usarlo en un grupo de colaboración apretado resulta ser una experiencia de git bastante diferente). Para mantener las cosas tan simples como sea posible, no hacemos ninguna modificación de base o historial. Pero cometimos algunos errores en la primera semana. Se hicieron algunas confirmaciones que no deberían haberse hecho, y logramos fusionar una rama de características en la rama de integración incorrecta (1.1 en lugar de 1.0). Y no nos enteramos de estas cosas hasta que pasaron mucho tiempo en nuestra historia.

Ahora veo muchas advertencias sobre la reescritura de la historia, pero no estoy realmente seguro de entender los peligros involucrados. Utilizamos un repositorio simple compartido, y todas las ramas se insertan allí para realizar copias de seguridad.

Yo esperaría que si reescribe el historial (por ejemplo, elimine un compromiso), la lista completa de los compromisos subsiguientes "perderá" ese compromiso (y tal vez no se compile / trabaje). También esperaría que si esto sucediera, realmente podría elegir arreglar esto en la parte superior de la historia (y dejar esa parte de la historia como no compilable).

• Si reescribo la historia (y todo compila / funciona en todas las ramas afectadas), ¿mis compañeros de trabajo deberán realizar algún comando especial? (En otras palabras, ¿"sabrán que lo he hecho" si lo hice bien?)
• ¿Los usuarios con cambios locales que no conozco serán elegibles para fallas de fusión en git pull?
• ¿Me falta algo esencial aquí?

Cualquier referencia a artículos / tutoriales sobre este tema también sería muy agradable.

Answer 1

Como se mencionó en los otros comentarios de respuesta, en la práctica cada confirmación es única y el historial de reescritura hará nuevas confirmaciones.

Puedes pensar que es cortar las ramas de un árbol y luego hacer crecer nuevas al instante. Incluso pueden parecer iguales pero no lo son. Sí, magia vudú. En esta analogía, revertir sería casi como soportar una rama caída con un tronco, por lo que crecerá a su manera sin caerse.

Eso nos lleva a un par de buenas razones para reescribir la historia :

• Adelgace un repositorio privado antes de hacerlo público: por ejemplo, cree una nueva sucursal privada local, pruebe, pruebe, reescriba, presione.
• Elimine los datos confidenciales de un repositorio privado antes de hacerlo público.

Aquellos ya revelan lo que Greg ya dijo: la reescritura de la historia podría arruinar a todos si el repositorio es público. Por lo tanto, también abogo por evitar hacerlo a toda costa, incluso en repositorios privados, solo para mantener el buen hábito: por lo tanto, se debe evitar la reescritura del historial a toda costa ^{(esto significa simplemente dar suficiente consideración antes de hacerlo: ponerle peso a los profesionales y contras!)}

Y hay al menos otra razón filosófica y pasada por alto: la historia reescrita es la pérdida de datos . Es cierto que un historial de git con revert puede parecer más desordenado que un reset . Pero si se escribe correctamente, todo ese "lío" se puede ocultar en ramas separadas y aún podemos ver exactamente en qué punto se realizó la reversión. E incluso con razones o pruebas de por qué se hizo.

De vuelta a la analogía del árbol, incluso si elimina el registro de soporte, la rama revertida mostrará las curvas sinuosas en crecimiento, ¡y es hermosa!

Answer 2

La lectura requerida es Problemas con la reescritura del historial en el Manual del usuario de Git.

Si reescribo la historia (y todo compila / funciona en todas las ramas afectadas), ¿mis compañeros de trabajo tendrán que hacer algún comando especial (es decir, "sabrán que lo he hecho" si lo hice bien?)?

Lo sabrán, y Git les dirá en términos claros que algo anda mal. Reciben mensajes de error inesperados y, en el proceso de tratar de resolver los conflictos de fusión resultantes, pueden revertir inadvertidamente confirmaciones anteriores. Este problema crea un mensaje real, y si tiene curiosidad por ver qué sucede, siempre puede intentarlo en una copia temporal de sus repositorios.

¿Los usuarios con cambios locales que no conozco serán elegibles para fallas de fusión en git pull?

Absolutamente, ver más arriba.

¿Me falta algo esencial aquí?

¡Evite reescribir la historia a (casi) todos los costos!