---

name: commit-changes description: > Preparar, confirmar y enmendar cambios con mensajes de commit convencionales. Incluye la revisión de cambios, la preparación selectiva, la escritura de mensajes descriptivos usando formato HEREDOC y la verificación del historial de commits. Utilizar al guardar una unidad lógica de trabajo en el control de versiones, al crear un commit con mensaje convencional, al enmendar el commit más reciente, o al revisar cambios preparados antes de confirmar. license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: git complexity: basic language: multi tags: git, commit, staging, conventional-commits, version-control locale: es source_locale: en source_commit: 6a868d56 translator: Claude Opus 4.6 translation_date: 2026-03-13

Confirmar Cambios

Preparar archivos de forma selectiva, escribir mensajes de commit claros y verificar el historial de commits.

Cuándo Usar

• Al guardar una unidad lógica de trabajo en el control de versiones
• Al crear un commit con un mensaje descriptivo y convencional
• Al enmendar el commit más reciente (mensaje o contenido)
• Al revisar qué se va a confirmar antes de hacerlo

Entradas

• Requerido: Uno o más archivos modificados para confirmar
• Opcional: Mensaje de commit (se redactará uno si no se proporciona)
• Opcional: Si se debe enmendar el commit anterior
• Opcional: Atribución de coautor

Procedimiento

Paso 1: Revisar los Cambios Actuales

Verificar el estado del árbol de trabajo e inspeccionar las diferencias:

# Ver qué archivos están modificados, preparados o sin seguimiento
git status

# Ver cambios no preparados
git diff

# Ver cambios preparados
git diff --staged

Esperado: Visión clara de todos los archivos modificados, preparados y sin seguimiento.

En caso de fallo: Si git status falla, verificar que se está dentro de un repositorio git (git rev-parse --is-inside-work-tree).

Paso 2: Preparar Archivos de Forma Selectiva

Preparar archivos específicos en lugar de usar git add . o git add -A para evitar incluir accidentalmente archivos sensibles o cambios no relacionados:

# Preparar archivos específicos por nombre
git add src/feature.R tests/test-feature.R

# Preparar todos los cambios en un directorio específico
git add src/

# Preparar partes de un archivo de forma interactiva (no soportado en contextos no interactivos)
# git add -p filename

Revisar lo preparado antes de confirmar:

git diff --staged

Esperado: Solo los archivos y cambios previstos están preparados. Sin .env, credenciales ni binarios grandes.

En caso de fallo: Quitar archivos añadidos por accidente con git reset HEAD <file>. Si se prepararon datos sensibles, quitarlos inmediatamente antes de confirmar.

Paso 3: Escribir un Mensaje de Commit

Usar el formato de commits convencionales. Siempre pasar el mensaje mediante HEREDOC para un formato correcto:

git commit -m "$(cat <<'EOF'
feat: add weighted mean calculation

Implements weighted_mean() with support for NA handling and
zero-weight filtering. Includes input validation for mismatched
vector lengths.

Co-Authored-By: Claude Opus 4.6 <[email protected]>
EOF
)"

Tipos de commit convencionales:

Tipo	Cuándo usar
feat	Nueva funcionalidad
fix	Corrección de error
docs	Solo documentación
test	Agregar o actualizar pruebas
refactor	Cambio de código que no corrige ni agrega
chore	Build, CI, actualización de dependencias
style	Formato, espacios en blanco (sin cambio de lógica)

Esperado: Commit creado con un mensaje descriptivo que explica el por qué, no solo el qué.

En caso de fallo: Si un hook de pre-commit falla, corregir el problema, volver a preparar con git add y crear un commit nuevo (no usar --amend ya que el commit fallido nunca se creó).

Paso 4: Enmendar el Último Commit (Opcional)

Solo enmendar si el commit no ha sido enviado a un remoto compartido:

# Enmendar solo el mensaje
git commit --amend -m "$(cat <<'EOF'
fix: correct weighted mean edge case for empty vectors

EOF
)"

# Enmendar con cambios preparados adicionales
git add forgotten-file.R
git commit --amend --no-edit

Esperado: El commit anterior se actualiza en el lugar. git log -1 muestra el contenido enmendado.

En caso de fallo: Si el commit ya fue enviado, no enmendar. Crear un nuevo commit en su lugar. Forzar el envío de commits enmendados a ramas compartidas causa divergencia en el historial.

Paso 5: Verificar el Commit

# Ver el último commit
git log -1 --stat

# Ver el historial reciente de commits
git log --oneline -5

# Verificar el contenido del commit
git show HEAD

Esperado: El commit aparece en el historial con el mensaje, autor y cambios de archivos correctos.

En caso de fallo: Si el commit contiene archivos incorrectos, usar git reset --soft HEAD~1 para deshacer el commit manteniendo los cambios preparados, y luego confirmar correctamente.

Validación

• Solo los archivos previstos están incluidos en el commit
• No se confirmaron datos sensibles (tokens, contraseñas, archivos .env)
• El mensaje de commit sigue el formato de commits convencionales
• El cuerpo del mensaje explica por qué se hizo el cambio
• git log muestra el commit con los metadatos correctos
• Los hooks de pre-commit (si existen) pasaron correctamente

Errores Comunes

• Confirmar demasiado a la vez: Cada commit debe representar un cambio lógico. Separar cambios no relacionados en commits distintos.
• Usar git add . a ciegas: Siempre revisar git status primero. Preferir preparar archivos específicos por nombre.
• Enmendar commits enviados: Nunca enmendar commits que ya se enviaron a una rama compartida. Esto reescribe el historial y causa problemas a los colaboradores.
• Mensajes de commit vagos: "fix bug" o "update" no dice nada. Describir qué cambió y por qué.
• Olvidar --no-edit al enmendar contenido: Al agregar archivos olvidados al último commit, usar --no-edit para mantener el mensaje existente.
• Fallo de hook que lleva a --amend: Cuando un hook de pre-commit falla, el commit nunca se creó. Usar --amend modificaría el commit anterior. Siempre crear un nuevo commit después de corregir problemas con hooks.

Habilidades Relacionadas

• manage-git-branches - flujo de trabajo con ramas antes de confirmar
• create-pull-request - siguiente paso después de confirmar
• resolve-git-conflicts - manejo de conflictos durante merge/rebase
• configure-git-repository - configuración y convenciones del repositorio