Cuando trabajamos con Git, es común que al avanzar en nuestro código terminemos con muchos cambios mezclados en un solo commit. Esto puede dificultar el seguimiento, la explicación y, en caso necesario, el deshacer modificaciones específicas. Para mantener un historial limpio y organizado, es muy útil dividir esos cambios en múltiples commits más pequeños y coherentes. Aquí es donde entra en juego la opción -p o --patch de Git, que nos permite seleccionar de forma interactiva qué partes de los cambios queremos incluir en cada commit.
La opción -p funciona mostrando los cambios en forma de parches, que son fragmentos de diferencias entre el estado actual y el último commit. Estos parches se parecen a lo que vemos con el comando git diff, donde las líneas eliminadas aparecen con un signo menos a la izquierda y las líneas añadidas con un signo más. Cuando una línea se modifica, veremos un menos y un más consecutivos, indicando qué se ha quitado y qué se ha añadido en su lugar.
Al ejecutar git add -p, Git nos presenta cada uno de estos parches uno a uno y nos pregunta qué queremos hacer con ellos. La interfaz puede parecer un poco compleja al principio, ya que ofrece varias opciones para decidir si incluir o no ese fragmento en el próximo commit. Por ejemplo, podemos aceptar el parche actual con y, rechazarlo con n, aceptar todos los cambios restantes del archivo con a, o saltar el resto del archivo con d. También podemos navegar entre parches con opciones como j o g, y salir con q, confirmando lo que hayamos seleccionado hasta ese momento.
Un detalle muy interesante es que cuando un parche contiene múltiples modificaciones, podemos dividirlo aún más usando la opción s. Esto nos permite ir seleccionando cada cambio pequeño dentro de un mismo parche, para tener un control aún más fino sobre qué incluir en el commit. Así, podemos construir commits muy específicos y claros, que facilitan la revisión y el mantenimiento del código.
Sin embargo, hay que tener cuidado con los archivos nuevos que hemos creado. Git no nos ofrecerá incluirlos automáticamente con git add -p, porque no hay un estado previo con el que comparar esos archivos. Por eso, es necesario añadirlos manualmente con git add nombre_del_archivo para que formen parte del staging area y puedan ser incluidos en el commit.
Después de seleccionar los cambios con git add -p, podemos comprobar qué está listo para el commit con git status. Veremos que algunos fragmentos están en el staging area, listos para ser confirmados, mientras que otros permanecen en el working directory, sin incluir. Para ver exactamente qué cambios hemos preparado para el commit, podemos usar git diff --staged, que nos muestra los parches que ya están en el área de preparación. Por otro lado, git diff sin opciones nos muestra los cambios que aún no hemos añadido.
Si en algún momento nos arrepentimos de haber incluido un cambio en el staging area, podemos usar git restore -p para quitarlo selectivamente. Esta opción funciona de forma similar a git add -p, pero en sentido contrario, permitiéndonos retirar fragmentos específicos del área de preparación sin afectar el resto.
En definitiva, el flag -p de Git es una herramienta poderosa para quienes queremos mantener un historial de commits limpio y bien organizado, facilitando la revisión y el mantenimiento del código. Solo hay que prestar atención a los archivos nuevos y asegurarse de añadirlos manualmente para no dejar cambios fuera del commit. Así, podemos construir commits claros, precisos y fáciles de entender para nosotros y para quienes revisen nuestro trabajo.