git-apply y parches en bruto (advanced)

Cómo exportar un diff para crear un archivo de parche, que podemos compartir y volver a aplicar más adelante usando el comando git-apply. Muchos proyectos de software libre siguen trabajando con parches como forma de compartir sus avances, porque no quieren dar el salto a GitLab y GitHub.

Cuando trabajamos con Git, una de las herramientas más útiles para entender y compartir cambios son los diffs y los parches. Con git diff podemos comparar las modificaciones que hemos hecho en nuestro directorio de trabajo respecto a un commit anterior, aunque no estamos limitados a comparar solo con el último commit. Podemos especificar cualquier otro commit, tag o incluso un rango entre dos referencias para ver qué ha cambiado entre ellos.

Por ejemplo, si queremos ver las diferencias entre dos versiones etiquetadas, como 5.0.0 y 5.1.0, podemos usar un comando como este:

git diff 5.0.0...5.1.0

Esto nos mostrará todas las modificaciones que se han hecho desde la versión 5.0.0 hasta la 5.1.0, incluyendo cambios en archivos, líneas añadidas o eliminadas, y hasta archivos binarios modificados. Si solo queremos un resumen rápido de qué archivos han cambiado y cuántas líneas, podemos añadir la opción --stat para obtener una visión más compacta.

Pero más allá de simplemente visualizar diferencias, a menudo necesitamos compartir estos cambios con otras personas. Imaginemos que estamos atascados con un problema y queremos que un compañero nos ayude. En lugar de enviarle todo el repositorio o subir una rama, podemos exportar el diff a un archivo que contenga el parche. Esto se hace redirigiendo la salida de git diff a un archivo con extensión .patch o .diff, que son convenciones comunes para estos archivos.

Por ejemplo:

git diff > modificaciones.patch

Este archivo contiene toda la información necesaria para que otra persona pueda aplicar esos cambios en su copia del repositorio. Además, es un formato estándar que muchos editores reconocen y colorean para facilitar su lectura.

Cuando queremos aplicar un parche que hemos recibido o que hemos guardado, usamos el comando git apply. Este comando lee el contenido del archivo de parche y modifica nuestro directorio de trabajo para reflejar esos cambios. Para aplicarlo, podemos hacer:

git apply < modificaciones.patch

Esto restaurará o añadirá las modificaciones indicadas en el parche, sin necesidad de hacer un merge o un commit automático, lo que nos da flexibilidad para revisar los cambios antes de confirmarlos.

Un uso muy práctico de esta funcionalidad es cuando queremos incorporar correcciones o mejoras que alguien ha propuesto en un proyecto público, pero que aún no han sido integradas oficialmente. Por ejemplo, en plataformas como GitHub o GitLab, cada pull request o merge request puede exportarse como un archivo .diff simplemente añadiendo esa extensión al final de la URL del pull request.

Así, si tenemos la URL de un pull request, podemos descargar el diff directamente y aplicarlo con git apply. Esto nos permite probar la solución propuesta sin esperar a que se integre oficialmente en el repositorio principal.

Eso sí, hay que tener en cuenta que si el parche es muy antiguo o el código base ha cambiado mucho desde que se creó, puede que la aplicación del parche falle o genere conflictos. Por eso, siempre es recomendable revisar y probar los cambios después de aplicar un parche externo.

En definitiva, manejar diffs y parches con Git nos da una gran capacidad para comparar versiones, compartir modificaciones de forma sencilla y colaborar con otros desarrolladores, incluso cuando no tenemos acceso directo a sus repositorios o ramas. Esta técnica es especialmente útil para mantener un flujo de trabajo ágil y ordenado en proyectos colaborativos.

Lista de reproducción
  1. 1
    ¿Qué es Git?
    4 minutos
  2. 2
    Cómo instalar Git
    9 minutos
  3. 3
    Creando tu primer commit
    9 minutos
  4. 4
    Qué es el staging area
    10 minutos
  5. 5
    Cómo deshacer modificaciones de archivos
    7 minutos
  6. 6
    Cómo deshacer un commit con reset
    7 minutos
  7. 7
    Cómo revertir un commit con revert
    7 minutos
  8. 8
    Introducción a las ramas
    6 minutos
  9. 9
    Cómo crear y modificar ramas
    6 minutos
  10. 10
    Commits bajo el workflow Feature Branch
    6 minutos
  11. 11
    Cómo fusionar ramas con merge
    6 minutos
  12. 12
    Fusiones conflictivas
    9 minutos
  13. 13
    Cómo construir alias
    7 minutos
  14. 14
    Más sobre conflictos
    9 minutos
  15. 15
    Etiquetas
    7 minutos
  16. 16
    Tags anotados
    9 minutos
  17. 17
    git stash: esconder cambios
    6 minutos
  18. 18
    Introducción a remotos
    5 minutos
  19. 19
    Pusheando a un remoto
    6 minutos
  20. 20
    Clonando y haciendo pull
    6 minutos
  21. 21
    Fetch y pull rebases
    8 minutos
  22. 22
    Rebase
    7 minutos
  23. 23
    Rebase interactivo
    6 minutos
  24. 24
    Master, main y otros nombres de rama
    9 minutos
  25. 25
    git switch
    9 minutos
  26. 26
    git-restore
    10 minutos
  27. 27
    git-grep
    11 minutos
  28. 28
    Gitignore
    11 minutos
  29. 29
    El flag --patch
    9 minutos
  30. 30
    git-apply y parches en bruto (advanced)
    9 minutos
  31. 31
    Merge octopus (advanced)
    9 minutos
  32. 32
    Conventional commits
    12 minutos
  33. 33
    Merge and squash (GitLab / GitHub...)
    6 minutos
  34. 34
    git merge --squash
    7 minutos
  35. 35
    git-bisect
    8 minutos
  36. 36
    git-blame
    6 minutos
  37. 37
    git-reflog
    10 minutos
  38. 38
    Git para la Bash
    11 minutos
  39. 39
    Submódulos (parte 1)
    7 minutos
  40. 40
    Submódulos (parte 2)
    10 minutos
  41. 41
    Otros clientes Git (último episodio)
    9 minutos