El peligro de reescribir el historial en un repositorio público

Imagina que has hecho push de una serie de commits a un repositorio público. Otras personas han hecho pull de esos commits y han empezado a trabajar a partir de ellos. Ahora, si vuelves atrás y corriges, reviertes o restableces cualquiera de esos commits, en la práctica estás cambiando los cimientos sobre los que se apoya su trabajo.

La próxima vez que intenten hacer push de sus cambios, recibirán un error porque el historial de su rama local ya no coincide con el historial de la rama remota. Tendrán que reconciliar manualmente los historiales divergentes, y eso puede ser un proceso confuso y bastante frustrante.

La regla de oro es: nunca reescribas historial público. Cuando ya hayas hecho push de un commit a un repositorio público, considéralo grabado en piedra. Si necesitas arreglar algo, usa git revert para crear un commit nuevo que deshaga los cambios, en vez de intentar modificar el commit existente.

Si no queda más remedio que reescribir el historial (por ejemplo, para eliminar datos sensibles que se incluyeron en un commit por accidente), avisa primero a las personas con las que colaboras. Asegúrate de que todo el mundo ha hecho pull de los últimos cambios y sabe lo que va a pasar. Después, cuando hayas reescrito el historial, cada persona tendrá que restablecer sus ramas locales para que coincidan con el nuevo historial del remoto.

Una cosa más: ten cuidado con git push --force. Este comando sobrescribe la rama remota con tu rama local, ignorando cualquier conflicto. Es como decir: "me da igual lo que haya en el remoto, déjalo exactamente igual que mi rama local". Esto puede hacer que otras personas pierdan su trabajo si habían subido commits que tú aún no habías traído antes del push forzado.

La opción --force tiene usos legítimos, pero úsala solo cuando entiendas bien las consecuencias. Si no lo tienes claro, es mejor usar git push --force-with-lease, que al menos te avisará si la rama remota tiene cambios que no esperabas.