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

Imagina que has enviado una serie de commits a un repositorio público. Otras personas han traído esos commits y han empezado a trabajar encima de ellos. Ahora, si vuelves atrás y corriges, modificas o restableces cualquiera de esos commits ya enviados, en la práctica estás cambiando los cimientos sobre los que se apoya su trabajo.

La próxima vez que intenten enviar 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 hayas enviado 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 traído 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, haz que se vea exactamente como mi rama local". Esto puede hacer que otras personas pierdan su trabajo si habían enviado commits que tú no habías traído antes de forzar el envío.

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.