Por qué un PR de GitHub parece menor al ocultar espacios
Un cambio pequeño puede perderse entre líneas rojas y verdes si el formateador también modifica toda la sangría. La novedad anunciada por GitHub el 22 de octubre evita repetir una elección habitual: ahora la preferencia personal de espacios puede mantenerse entre pull requests.
Una preferencia que llega al siguiente PR
En Files changed → Settings → Whitespace changes se puede elegir Always show, Always hide o Hide for this diff only. La preferencia guardada es personal y se aplica entre PR. Al ocultar espacios aparece Hide whitespace junto a All commits; su X los muestra temporalmente sin cambiar la preferencia.
Los recuentos de archivos y las estadísticas reflejan el diff mostrado. Un número menor no implica que el autor haya retirado cambios. El filtro activo puede explicar por qué dos personas ven cifras distintas en la misma propuesta.
Encontrar la línea bajo el formato
Creamos un ejemplo JavaScript que calcula un precio con impuestos. La nueva versión redondea a dos decimales y cambia la sangría de dos a cuatro espacios. La imagen contiene la salida real de git diff local; no es una pantalla de GitHub.
El diff normal muestra juntas la fórmula y la devolución como líneas sustituidas. Con git diff -w, la fórmula queda como contexto y resalta la devolución modificada. Es más fácil pensar en el redondeo, los valores negativos y las pruebas existentes, aunque esa claridad no demuestra que el cambio sea correcto.
Cuando el espacio sí cambia el resultado
La sangría de Python, la estructura de YAML y los espacios dentro de cadenas pueden tener significado. Pasar de "Hello world" a "Helloworld" cambia el texto visible. -w controla la comparación de espacios; no interpreta el programa.
En este segundo ejemplo deliberadamente sencillo, -w no produce ningún diff. La imagen registra la ejecución. No prueba que GitHub compare siempre igual que Git local, pero explica por qué conviene volver a mostrar los espacios donde afecten al significado.
Más ancho para un archivo nuevo
En split view, los archivos nuevos y eliminados ocupan ahora ambas columnas. Al no existir una versión anterior que colocar enfrente, el ancho adicional reduce los saltos de línea en tipos o nombres de pruebas largos.
En un PR que mezcle formato y comportamiento, puede servir leer primero la lógica filtrada y después recuperar los espacios para revisar cadenas y estructura. Separar los commits de formato también comunica mejor la intención. La preferencia ahorra clics; comprender el cambio sigue siendo la tarea central.
Fuentes oficiales
GitHub Docs · Reviewing proposed changes
Verificado el 23 de octubre de 2026 con el anuncio y la documentación de Git; ambos ejemplos se ejecutaron localmente.