Si un commit anterior contiene un cambio no deseado en un archivo, puedes revertir el cambio de ese archivo en tu rama actual y guardar el resultado en un nuevo commit. Esto mantiene los commits posteriores en su lugar y preserva sus ediciones cuando el parche inverso todavía encaja. En macOS, usa Terminal desde el repositorio; revisa el parche primero, especialmente si el trabajo posterior afectó a las mismas líneas.
Elige el cambio de historial adecuado
Este procedimiento añade un commit que cancela el cambio del commit de destino en una ruta específica. No borra ese archivo del commit antiguo, por lo que la versión anterior permanece en el historial. Este enfoque evita reescribir el historial de la rama y suele ser adecuado cuando el commit ya se ha compartido o cuando commits posteriores dependen de él. Git describe git revert como la acción de registrar un nuevo commit que invierte un commit anterior, pero no ofrece una opción integrada para revertir solo una ruta de un commit existente. En su lugar, los pasos siguientes generan el parche de esa ruta y lo aplican a la inversa. Git: Documentación de git-revert
Si el cambio del archivo debe eliminarse del propio commit histórico, se trata de una tarea de reescritura del historial, que habitualmente se gestiona con un rebase interactivo. Reescribir cambia los identificadores de los commits y puede perturbar a los colaboradores que hayan basado su trabajo en los commits antiguos. Esta guía cubre el enfoque aditivo, que es más seguro.
Revertir el cambio del commit de destino en un archivo
Abre Terminal, ve al repositorio y comprueba el árbol de trabajo antes de cambiar nada. Reemplaza TARGET con el ID del commit y path/to/file con la ruta relativa a la raíz del repositorio. El ejemplo utiliza un archivo de parche temporal en el directorio /tmp de macOS; elige un nombre temporal diferente si ese archivo ya existe.
git status --short
git show --stat --oneline TARGET
git diff TARGET^ TARGET -- "path/to/file" > /tmp/remove-file-change.patch
El diff compara el commit de destino con su primer padre y limita el resultado a la ruta indicada. En el caso de un commit normal (que no sea de fusión), esto representa el cambio de ese commit en el archivo. Confirma que el resumen identifique el commit deseado y que el parche no esté vacío. Puedes inspeccionarlo con less /tmp/remove-file-change.patch; presiona q para salir. Git documenta las diferencias entre commits con una limitación de ruta opcional. Git: Documentación de git-diff
Antes de aplicarlo, asegúrate de no tener ediciones no relacionadas preparadas (staged) o sin preparar (unstaged) en el archivo de destino. El parche inverso modifica la copia de trabajo, por lo que un árbol de trabajo limpio es el punto de partida más sencillo. Si tienes trabajo local útil, haz un commit o apártalo de forma segura primero; no lo sobrescribas con un comando de restauración.
Comprueba si el parche inverso encaja y luego aplícalo:
git apply --reverse --check /tmp/remove-file-change.patch
git apply --reverse /tmp/remove-file-change.patch
--reverse aplica el diff hacia atrás, mientras que --check comprueba si se puede aplicar sin modificar los archivos. De forma predeterminada, git apply hace que falle todo el parche si algunos fragmentos (hunks) no encajan, en lugar de aplicar solo las partes que sí lo hacen. Si la comprobación falla, detente e inspecciona el archivo y el parche. Es posible que ediciones posteriores se superpongan con el cambio de destino, por lo que Git no puede determinar de forma segura qué se debe eliminar. Resuelve el contenido deseado manualmente o utiliza un flujo de trabajo de reescritura de historial si es esencial conservar una secuencia histórica editada con precisión. No añadas --reject a la ligera: puede aplicar solo las partes coincidentes y dejar atrás los fragmentos rechazados. Git: Documentación de git-apply
Revisar y hacer commit del resultado
Inspecciona exactamente qué ha cambiado antes de prepararlo en el área de stage. git diff muestra las ediciones del árbol de trabajo; utiliza la ruta de nuevo para centrar la revisión. Si el resultado es correcto, prepara ese archivo en el stage y comprueba el diff preparado antes de crear un nuevo commit.
git diff -- "path/to/file"
git add -- "path/to/file"
git diff --cached -- "path/to/file"
git status --short
git commit -m "Remove file change from earlier commit"
Las comillas protegen la ruta de la interpretación del shell, y -- marca el final de las opciones. Son especialmente útiles para nombres que contienen espacios o metacaracteres del shell. El commit registra el índice preparado; revisar git diff --cached verifica el contenido exacto que está a punto de confirmarse. Git: Documentación de git-commit
Después de hacer el commit, comprueba git status --short e inspecciona el nuevo commit con git show --stat --oneline HEAD. Si el commit original añadió el archivo, revertir su parche puede eliminarlo; esto es lo esperado si no es necesario que permanezca ningún contenido posterior. Si commits posteriores añadieron contenido útil a ese archivo, esas adiciones deberían permanecer cuando el parche inverso se aplica limpiamente; revisa el archivo final y el diff para confirmarlo.
Casos que requieren atención especial
Un commit de fusión (merge commit) tiene múltiples padres, y su cambio depende del padre con el que se compare. TARGET^ significa el primer padre; es posible que no represente el cambio que pretendías eliminar. Identifica el padre correcto y compara contra él explícitamente antes de aplicar nada. Los cambios de nombre, los archivos binarios y los archivos que se hayan movido desde entonces también pueden hacer que un parche limitado por ruta no sea adecuado; comprueba el diff y detente si no describe el cambio de archivo deseado. Para reversiones específicas de fusiones, la documentación de git revert explica la elección del padre de la línea principal (mainline) y sus consecuencias. Git: Documentación de git-revert
El punto de control de confianza es el parche revisado: debe mostrar únicamente el cambio del commit de destino en la ruta prevista. Si no se puede aplicar limpiamente al archivo actual, no lo fuerces. Reconstruye el archivo actual deseado con cuidado, y luego prepara y haz commit solo después de revisar el resultado completo.