Commit de parte de un archivo
Los bloques son casos distintos, no un único script. Elige el que encaja con tu repositorio. Sustituye ramas, rutas y VERIFIED_COMMIT antes de usarlos. Los comandos de cancelación solo corresponden a su operación activa; no ejecutes ambas alternativas.
Respuesta breve
Git crea el commit con el contenido del índice. Prepara solo la corrección y deja las otras ediciones en el directorio de trabajo para formar commits separados.
Ejemplo y condiciones
El ejemplo tiene una corrección y una impresión de depuración en el mismo archivo. Ambas deben poder revisarse como cambios de texto distintos.
Inspecciona antes de cambiar
Compara git diff con git diff --cached. El primero muestra cambios sin preparar; el segundo muestra exactamente lo que el siguiente commit incluirá.
git status --short
git diff
git diff --cachedConserva una referencia o checkout separado
Preparar un cambio no borra la edición restante. Mantén el índice y el directorio de trabajo como dos estados que puedes inspeccionar por separado.
Primer flujo
En FluxGit, abre el diff y usa Stage change en la corrección. Revisa el panel de commit: la impresión de depuración debe seguir sin preparar.
Elige deliberadamente la otra opción
En terminal, git add -p permite aceptar o rechazar hunks. Las opciones s y e pueden dividir un hunk o editar su parche cuando corresponde.
git add -p -- app.py
git diff --cachedLímites y excepciones
La unidad mínima de FluxGit es un cambio dentro de un hunk. Un cambio de seis líneas se prepara entero; no equivale a pintar rangos arbitrarios de líneas.
Conflictos y limpieza
Despreparar conserva el archivo; descartar modifica su contenido. FluxGit captura una instantánea de seguridad antes del descarte parcial: son acciones distintas.
Verifica el resultado
Lee git diff --cached antes de confirmar y git show después. Comprueba también git diff para asegurarte de que el trabajo pendiente sigue en el archivo.
git show --stat HEAD
git diff
git status --shortPreguntas habituales
Si el commit era privado y normal, git reset --soft HEAD^ puede devolver su contenido al índice. Revisa el estado y no reescribas una historia compartida sin coordinarlo.
Revisa la operación en FluxGit
Commit Studio mantiene el diff y el mensaje juntos. Revisa el contenido mientras escribes y crea commits con una intención clara.
Documentación oficial de Git
Hacer commit de solo una parte de un fichero en Git
¿Arreglaste un bug y dejaste un print de depuración en el mismo fichero? Haz commit solo del arreglo. Por qué Git guarda el área de preparación y no tu carpeta, cómo preparar un único cambio de forma visual en FluxGit, y lo mismo con git add -p.
Ver en YouTube — abre una pestaña nueva
Grabado en un repositorio de pruebas.
Leer la transcripción de la narración
- Arreglaste un bug y en el mismo fichero dejaste un print de depuración. Quieres un commit limpio: el arreglo, sin el print.
- Este es el fichero en FluxGit: app.py, con dos cambios.
- Por esto funciona. Git no guarda tu carpeta; guarda el área de preparación. Los dos cambios empiezan solo en el disco. Stage change pone solo el arreglo en el área de preparación. El commit se lleva exactamente eso, y el print sigue en tu disco, sin commit.
- Abre el fichero. El diff muestra los dos cambios, y cada uno tiene su propio botón Stage change.
- Stage change en el arreglo. Solo se mueve ese cambio; el print se queda donde está.
- De vuelta en el panel de commit: el arreglo está preparado, el print no.
- Escribe el mensaje y haz commit.
- El nuevo commit contiene el arreglo, y solo el arreglo. El print sigue en tu disco, sin commit.
- ¿Cambias de idea? Deshacer retira el commit. El arreglo vuelve al área de preparación y tus ficheros no cambian.
- En la terminal, lo mismo es git add con guion p: Git pregunta por cada cambio, respondes sí al arreglo y no al print, y luego haces commit.
- Resumen. Prepara cambios, no ficheros enteros. Una idea por commit. Y Deshacer si te equivocas. Siguiente lección: arreglar el último commit.