Git add -p: prepara líneas específicas y realiza confirmaciones enfocadas

Para confirmar solo una parte de un archivo, prepare los cambios que desee con `git add -p -- path/to/file`, revíselos con `git diff --cached` y luego confirme. Las ediciones restantes permanecen en sus archivos de trabajo. En GitTree, abra el archivo diff, seleccione las líneas modificadas y elija Stage Lines para preparar el mismo tipo de confirmación enfocada.

Supongamos que solucionó un error de validación de pago y luego comenzó a reorganizar el mismo componente. Un revisor debería poder comprender la corrección del error sin leer una refactorización inacabada. Esta guía separa esos cambios antes de que se conviertan en historia. El ejemplo animado usa GitTree, el cliente que creamos para macOS, Windows y Linux. La puesta en escena parcial pertenece al plan Gratuito; Las compilaciones oficiales actuales requieren iniciar sesión.

Árbol de trabajo, área de preparación y compromiso: ¿qué se guarda?

La puesta en escena es un paso de selección, no un compromiso ni un empujón. Un archivo se puede preparar parcialmente: el índice contiene una versión mientras que el editor muestra todas las ediciones. Si vuelve a editar después de la preparación, la versión preparada no se actualiza silenciosamente. Revíselo nuevamente antes de comprometerse. El gráfico de confirmación visual ayuda a inspeccionar el historial una vez que existe la confirmación.

Cómo usar git add -p en un archivo

Comience con git status e inspeccione todo lo que ya se haya preparado. El modo parche agrega cambios seleccionados al índice existente; no elimina selecciones anteriores. En este ejemplo, reemplace src/checkout.ts con su archivo de texto rastreado, luego acepte solo la corrección de validación cuando Git pregunte sobre cada bloque.

git status
git diff --cached
git diff -- src/checkout.ts
git add -p -- src/checkout.ts
git diff --cached
git diff -- src/checkout.ts
git commit -m "fix: validate checkout input"

Ejecute la confirmación final solo después de revisar la diferencia preparada y probar el cambio previsto. git diff --cached muestra lo que registrará la confirmación; Plain git diff muestra lo que quedará sin confirmar. No utilice git commit -a ni proporcione rutas de archivos a git commit para este flujo de trabajo: esos formularios pueden omitir la selección parcial que acaba de preparar.

Divida un trozo cuando la solución y la refactorización estén muy juntas

Un trozo es un bloque de líneas cambiadas cercanas con contexto. El modo parche puede agrupar la corrección y la refactorización. Usa s para pedirle a Git que divida el bloque. Si las ediciones no se pueden separar automáticamente, e abre un editor de parches o un selector de línea visual puede ayudarle a elegir las adiciones y eliminaciones previstas.

Para un reemplazo, considere tanto la línea eliminada como su reemplazo como un cambio lógico. Seleccionar solo la mitad puede producir código que nunca viste en tu editor. La edición avanzada de parches es opcional; Si no puede explicar el resultado preparado, desactívelo y elija un límite más claro. Los compromisos enfocados deben funcionar por sí solos, no simplemente ser pequeños.

Descargue GitTree para revisar una diferencia mixta y crear confirmaciones enfocadas visualmente. Puedes usarlo en un repositorio existente junto a la terminal; ambos leen la misma área de preparación de Git.

Deshazte de los cambios sin descartar tus ediciones

git restore --staged -- src/checkout.ts
# Or choose which staged blocks to remove:
git restore --staged -p -- src/checkout.ts

Estos son comandos alternativos. Con --staged, restaurar cambia el índice en lugar de su archivo de trabajo. Para un repositorio con confirmaciones, normalmente restablece el contenido preparado hacia HEAD. Sin --staged, la restauración puede sobrescribir las ediciones en funcionamiento, así que mantenga clara la distinción. En GitTree elija Unstage, no Descartar, cuando solo desee cambiar lo que incluye la siguiente confirmación.

Por qué un archivo aparece dos veces o no se puede preparar una línea

Un archivo tanto en Archivos preparados como en Archivos no preparados normalmente significa una preparación parcial o una edición posterior, no un archivo duplicado. Es posible que un archivo de texto nuevo y sin seguimiento necesite git add -N -- path/to/new-file antes de que el modo de parche pueda ofrecer su contenido. Los archivos binarios no tienen fragmentos de texto ordinarios; GitTree también organiza cambios de nombre, punteros LFS y cambios de submódulo como operaciones de archivo completo. Si los espacios en blanco están ocultos, muéstrelos antes de seleccionar cambios que solo incluyan espacios en blanco.

Si un editor o formateador cambia el archivo después de abrir su diferencia, GitTree puede rechazar una selección de línea obsoleta. Actualiza la diferencia y elige nuevamente. Evite dividir cambios estrechamente acoplados solo para alcanzar un número de líneas menor. Para una interrupción de una tarea, guarda el trabajo sin terminar; para conocer el historial mixto ya comprometido, revise la guía interactiva de rebase.

Pruebe la confirmación que está preparando, no solo los archivos del editor

Su comando de prueba normal se ejecuta en archivos de trabajo, que aún incluyen ediciones no preparadas. Pasar las pruebas allí no prueba que la confirmación parcial esté completa. Para una división importante, realice la primera confirmación local, luego inspeccione y pruebe esa instantánea confirmada en un proceso de pago o árbol de trabajo limpio por separado. Agregue la dependencia que falta si falla antes de compartir la rama. La guía del árbol de trabajo explica cómo las carpetas separadas ayudan a mantener esas versiones separadas.