Flujo de trabajo Git con Claude Code: automatiza commits y PRs (2026)

¿Claude Code puede crear commits y PRs por sí solo?

Sí, y es una capacidad integrada, no hay que instalar nada extra. Claude Code llama a git y a gh mediante su herramienta Bash, así que solo dices "haz commit de los cambios" y ejecuta git status y git diff, lee el contexto y luego redacta un mensaje de commit. Di "crea un pr" y ejecuta gh pr create, generando el título y el cuerpo a partir de tus commits.

Requisitos mínimos: el repositorio debe estar inicializado con git init y tienes que estar dentro de él. Para abrir un PR también necesitas el gh CLI (GitHub CLI) con sesión iniciada. Si no lo tienes, Claude Code igual hace commit sin problema; solo que no puede abrir el PR por ti. Según la documentación de flujos comunes de Anthropic (consultada el 09/08/2026), estos son flujos oficialmente compatibles, no trucos de terceros.

Un apunte de confianza para empezar: Claude Code toca git a través de la capa de permisos de la herramienta Bash, así que cada comando de escritura (commit, push) pide tu aprobación a menos que la hayas concedido de antemano. No hace push a un remoto salvo que se lo pidas, pero, como cubre el final de este artículo, conviene dejarlo por escrito en el CLAUDE.md para estar segura.

Paso 1 - Configuración: git, el gh CLI y la autenticación

Antes de entregarle git al agente, revisa tres cosas. Abre una terminal (o deja que Claude Code la ejecute por ti) y confirma:

git --version
gh --version
gh auth status

Si gh avisa de que no está instalado, instala el GitHub CLI e inicia sesión una vez:

# macOS
brew install gh
# Windows
winget install --id GitHub.cli
# After installing, log in (opens a browser to authenticate)
gh auth login

Elige GitHub.com, luego HTTPS y autentícate en el navegador. Una vez hecho, gh guarda un token para poder abrir PRs en tu nombre. Por último, asegúrate de estar en el repositorio correcto y en una rama de trabajo:

git rev-parse --is-inside-work-tree # true if this really is a git repo
git branch --show-current

Consejo: no trabajes directamente en main. Crea una rama primero; incluso puedes pedírselo a Claude Code: "crea una rama feat/checkout y cámbiate a ella". Una rama limpia deja el paso final del PR mucho más ordenado.

Paso 2 - Redacta conventional commits correctos de forma automática

Aquí es donde Claude Code luce. Cuando termines de programar, en vez de escribir el mensaje tú misma, da la instrucción:

commit the current changes using conventional commits

Claude Code ejecuta git status y git diff --staged (más el diff sin preparar), analiza lo que realmente cambiaste y luego escribe un mensaje con el formato correcto:

type(scope): short description in the present tense

- bullet detail if needed
- the reason for the change, not just a file list

Los valores de type más comunes de Conventional Commits:

Consejo para mensajes de más calidad: si ya preparaste exactamente la parte que quieres commitear (un git add deliberado), Claude Code se ciñe al diff preparado y adivina menos. También puedes ser específica: "haz commit, el scope es 'checkout', céntrate en el porqué del cambio en vez de listar archivos". Cuanto más contexto le des sobre el porqué del cambio, más útil seguirá siendo el mensaje para quien lea el historial más adelante.

Sobre la línea "Co-Authored-By": por defecto, Claude Code suele añadir una atribución como Co-Authored-By: Claude <...> al final del commit. En un repositorio personal o un proyecto paralelo, mantenerla es inofensivo y transparente. Pero en un repositorio de empresa con convenciones de commit estrictas (o CI que valida el formato del mensaje con commitlint), quizá quieras desactivarla. La solución más simple es una regla en el CLAUDE.md: "no añadas una línea Co-Authored-By ni ninguna firma de IA a los mensajes de commit"; Claude Code obedece. Es una decisión de política del repositorio, así que acuérdala con tu equipo antes de activarla o desactivarla para todos. Si quieres una referencia rápida de los comandos de git que más usas con Claude Code, el cheat sheet de Claude Code tiene una tabla de consulta muy práctica.

Paso 3 - Divide los commits por type/scope (división automática)

En la práctica, rara vez cambias una sola cosa. Una única sesión de código puede añadir una función, corregir un bug y actualizar la documentación, todo a la vez. Mete todo eso en un commit gigante y los revisores sufren, y un revert arrastra cambios sin relación. Claude Code puede dividirlo por ti:

these changes span several types. Split them into separate atomic
commits by type/scope, one type of change per commit

Agrupa el diff por tema, prepara cada grupo (git add -p o por archivo) y luego crea los commits uno a uno. Un diff mezclado podría quedar así:

feat(payment): add VietQR payment flow
fix(payment): correct amount rounding
docs(payment): note the SEPAY_KEY environment variable

Por qué vale la pena: cada commit atómico es una unidad de revisión independiente, el historial se lee con claridad y, cuando necesites git revert, quitas solo lo que se rompió sin tocar el resto. Es una técnica que casi ninguna guía menciona, pero es la gran diferencia entre "dejar que la IA haga commit de lo que sea" y "dejar que la IA haga commit como una dev cuidadosa". Una salvedad: échale un vistazo a los commits que propone antes de aprobarlos; a veces los límites de scope que traza no coinciden con la estructura de tus módulos y, en ese caso, basta con decir "fusiona los dos primeros commits".

Paso 4 - Busca secretos antes de hacer commit

Aquí hay un riesgo real de dejar que un agente haga commit que casi ninguna guía menciona: el agente puede colar sin querer un .env, una clave de API, un token o una cadena de conexión a la base de datos en un commit, y, una vez en el historial, limpiarlo bien es un fastidio. Antes de hacer commit, pídele que busque:

before committing, scan the staged files for any secrets:
API keys, tokens, passwords, connection strings, or a stray .env file

La lista de comprobación de seguridad que conviene aplicar:

• Ten un .gitignore que bloquee .env, *.pem, *.key desde el principio del repositorio.
• Pídele a Claude Code que inspeccione el diff preparado en busca de cadenas parecidas a claves o tokens antes de cada commit.
• Instala un hook de pre-commit que bloquee en la capa de git (por ejemplo gitleaks o git-secrets) para no depender por completo del agente.
• Si ya hiciste commit de un secreto: trata ese token como filtrado, rótalo ahora, no basta con borrar el archivo y commitear encima.

Para automatizar del todo esta parte, puedes mover el escaneo a un hook que se ejecute antes del commit; mira cómo usar hooks en Claude Code para encajar una comprobación automática. La regla de oro: nunca confíes por completo a un agente el acceso de escritura a tu historial sin una capa de bloqueo a nivel de git.

Paso 5 - Abre un pull request automáticamente con gh

Con los commits limpios, abrir un PR es una sola frase:

create a pr

Claude Code hace push de la rama (si lo permites), ejecuta gh pr create y redacta el título y el cuerpo a partir de los commits de la rama, incluido un resumen de cambios y una checklist si el repositorio tiene una plantilla de PR. Puedes ser más específica: "abre el PR contra la rama develop y detalla las pruebas que ejecuté".

Un truco simpático de la documentación de Anthropic: un PR creado con gh pr create queda vinculado automáticamente a la sesión de Claude Code que lo generó. Más tarde, cuando vuelvas a revisarlo, reabres ese mismo contexto de sesión con:

claude --from-pr 1234

Muy útil cuando un revisor deja comentarios y quieres que Claude Code siga trabajando en ellos recordando todo el contexto original.

Si en este paso necesitas operaciones más profundas de GitHub —leer issues, comentar, gestionar solicitudes de revisión dentro de la sesión— combina el GitHub MCP con Claude Code en vez de depender solo de gh. El MCP permite que Claude Code "vea" todo el contexto de GitHub, no solo ejecutar comandos de CLI.

Estandariza con el CLAUDE.md y un slash command /commit

Las instrucciones en lenguaje natural son rápidas, pero si tienes que repetir "conventional commits, no hagas push, sin firma de IA" cada vez, conviértelo en una regla fija. Pon el siguiente bloque en un archivo CLAUDE.md en la raíz del repositorio; Claude Code lo lee en cada sesión:

## Git Rules
- Commit using Conventional Commits: type(scope): description (present tense).
- Types to use: feat, fix, docs, refactor, chore, test.
- Split a mixed diff into atomic commits by type/scope.
- Scan for secrets (API keys, tokens, .env) before every commit.
- Do NOT run git push on your own; push only when I explicitly ask.
- Do NOT add a Co-Authored-By line or any AI signature to commit messages.
- Scope names follow the repo's module/folder names.

Para entender cómo escribir bien este archivo, mira la guía de cómo escribir reglas de git en el CLAUDE.md. El siguiente paso es envolver todo el proceso en un slash command personalizado, para que todo el equipo ejecute exactamente el mismo flujo con un solo comando. Crea el archivo .claude/commands/commit.md:

---
description: Conventional commit, atomic split, secret scan
---
Review git status and git diff. Scan the staged files for secrets.
Split the changes into atomic commits by type/scope.
Commit using Conventional Commits. Do NOT push.

A partir de ahí, todo el equipo solo escribe /commit y obtiene el mismo comportamiento: se acabaron los commits fuera del estándar. Así es exactamente como conviertes un "truco personal" en un "estándar del equipo".

Flujo avanzado: worktrees, revisión de PR y CI

Cuando ya te sientas cómoda, algunas técnicas llevan la productividad a otro nivel:

Worktrees en paralelo. Para que Claude Code construya una función en su propia rama sin alterar tu directorio de trabajo principal, usa una worktree:

claude --worktree feature-auth

Puedes tener una sesión corrigiendo un bug y otra construyendo una función en paralelo, en dos worktrees, sin que se pisen entre sí.

Encájalo en el pre-commit/CI. Claude Code se ejecuta de forma no interactiva con -p, así que puedes meterlo en un script. Por ejemplo, resumir los commits recientes para un changelog o un paso de revisión:

git log --oneline -20 | claude -p "summarize these recent commits into a changelog"

PRs apilados. Cuando una función grande se divide en varios PRs dependientes (el PR B se apoya en el PR A aún sin fusionar), puedes hacer que Claude Code construya la cadena de ramas apiladas y abra los PRs en el orden padre-hijo correcto. Así los revisores aprueban piezas pequeñas en lugar de un PR gigante, y es justo donde una skill de git lista ahorra mucho trabajo repetitivo.

Autorrevisa el PR antes de fusionar. Antes de darle a merge, deja que Claude Code lea el diff y cace bugs de lógica, casos límite o vulnerabilidades; mira cómo hacer que Claude revise un PR antes del merge. Combinado con el CI de tu repositorio, obtienes dos capas de comprobación: la máquina ejecuta las pruebas, la IA lee el sentido del cambio. Mantén los roles separados: un agente hace una sólida primera revisión, pero la decisión final de fusión aún debería pasar por ojos humanos, sobre todo en cambios que tocan seguridad o datos.

Acelera git con una skill lista (el ak-git de AgentKit)

Todo este artículo básicamente te enseña a montarlo tú misma: escribir los prompts, fijar las reglas del CLAUDE.md, crear el slash command. Ese enfoque es perfectamente válido y gratuito. Pero, si prefieres no ensamblar cada pieza a mano, existe una skill de git lista llamada ak-git que hace justo las cuatro cosas de este artículo —conventional commits, división automática por type/scope, escaneo de secretos y PRs apilados— en una sola llamada.

Una línea para no confundir: ak-git es parte de AgentKit, el kit para Claude Code en agentkit.best (la CLI ak), que es distinto del "AgentKit" de OpenAI. No mezcles los dos.

ak-git viene del Engineer Kit ($99, el sitio no menciona ninguna tarifa recurrente); si quieres saber qué más incluye, lee la reseña del Engineer Kit antes de decidir. El punto honesto: no estás obligada a comprar nada para ejecutar este flujo de git; todo lo de este artículo funciona con Claude Code puro. El valor del kit está en ahorrarte el esfuerzo de configuración y mantener un comportamiento consistente en un equipo.

Errores comunes y consejos de seguridad

Dejar que un agente lleve git es cómodo, pero hay algunas trampas conocidas. Esto es lo que suele fallar y cómo manejarlo:

Un límite honesto que recordar: Claude Code no "entiende" tu lógica de negocio tan a fondo como tú, así que a veces sus mensajes describen mejor qué cambió que por qué. En commits importantes, añade el "porqué" tú misma. Y revisa siempre el diff antes de aprobar: el agente es rápido, pero la responsabilidad del historial sigue siendo tuya.

Preguntas frecuentes (FAQ)

¿Claude Code hace push al remoto por su cuenta?

No, salvo que se lo pidas. Cada comando de escritura de git pasa por la capa de permisos de la herramienta Bash, y Claude Code no hace push a menos que lo indiques. Para mayor seguridad, añade una regla "no hagas git push por tu cuenta" al CLAUDE.md.

¿Tengo que instalar el gh CLI?

Para hacer commit, no; con git basta. Pero para que Claude Code abra un pull request por sí mismo con gh pr create, necesitas gh instalado y con sesión iniciada mediante gh auth login.

¿El commit incluye una línea "Generated with Claude" y cómo la desactivo?

Por defecto suele haber una línea Co-Authored-By que acredita a Claude. Para desactivarla, añade una regla al CLAUDE.md: "no añadas una línea Co-Authored-By ni ninguna firma de IA a los mensajes de commit". Claude Code la quitará.

¿Cómo consigo que Claude divida un montón de cambios en varios commits?

Da la instrucción "divide estos cambios en commits atómicos por type/scope". Claude Code agrupa el diff por tema, prepara cada grupo y luego crea un commit separado por cada tipo de cambio.

¿Puede abrir un pull request privado (borrador)?

Sí. Di "crea el PR como borrador" y Claude Code añade la flag correspondiente al ejecutar gh pr create. También puedes especificar la rama de destino y los revisores.

¿Funciona con GitLab o Bitbucket?

Los conventional commits, la división de commits y el escaneo de secretos funcionan con cualquier repositorio git. Solo el paso automático de PR depende de gh, que está ligado a GitHub; para GitLab/Bitbucket usa la CLI correspondiente (como glab) o hazlo a mano.

Conclusión y próximos pasos

El flujo de trabajo de git con Claude Code se reduce a cuatro pasos: configurar git más gh, escribir conventional commits correctos, dividir en commits atómicos y buscar secretos, y luego abrir el PR con gh. Pon las reglas en el CLAUDE.md y en un slash command /commit y todo el equipo comparte un único estándar. Después: conecta el GitHub MCP para operaciones más profundas de GitHub y deja que Claude revise el PR antes del merge. Si prefieres saltarte la parte de montarlo tú misma, el bundle de AgentKit, ahora $149 (antes $198) incluye la skill ak-git que ejecuta exactamente este flujo.