Hogar

Skill

Git y control de versiones

conventional-git

samber/cc-skills

Normas convencionales de v1.0.0 para la denominación de ramas, la denominación de árboles de trabajo y los mensajes de confirmación en proyectos de GitHub y GitLab. Úsalas al crear ramas, nombrar árboles de trabajo, escribir confirmaciones, generar mensajes de confirmación, revisar las convenciones de las ramas o configurar la automatización del registro de cambios. Aplícalas cuando tu proyecto necesite un historial de Git coherente, lanzamientos basados en SemVer, la generación de un registro de cambios analizable o el cierre automático de incidencias. Actívalas cuando el usuario pregunte cómo nombrar un árbol de trabajo, crear un árbol de trabajo de Git u organizar

...Expandir todo

Tiempo actualizado 26 de agosto de 2026

# git # version-control # workflow # changelog # Git & Version ControlProductivity & Workflow # conventional-commits

Acerca de conventional-git

Define las normas de «Conventional Commits v1.0.0» para los nombres de ramas, los nombres de los árboles de trabajo de Git y los mensajes de confirmación en proyectos de GitHub y GitLab, de modo que las herramientas puedan generar automáticamente registros de cambios, aplicar los incrementos de SemVer y filtrar el historial por tema. Aplícalo al crear ramas, nombrar árboles de trabajo, redactar o generar mensajes de confirmación, revisar las convenciones de las ramas o configurar la automatización de los registros de cambios, así como siempre que un proyecto necesite un historial de Git coherente, lanzamientos basados en SemVer, registros de cambios analizables o el cierre automático de incidencias. Está diseñado para Claude Code o agentes de programación con IA similares y requiere Git.

Los nombres de las ramas siguen el formato «/[issue-] » en minúsculas y solo con guiones, precedidos por un número de incidencia cuando exista para que GitHub y GitLab lo enlacen automáticamente, y con una longitud inferior a 50 caracteres. Los «worktrees» se tratan como directorios de checkout locales que nunca llegan al servidor remoto: se encuentran en .claude/worktrees/ y reflejan el nombre de la rama sustituyendo la barra por un guión; además, la guía especifica que «worktree» nunca debe aparecer en el nombre de una rama. Se recomienda ejecutar «git worktree list» antes de crear uno nuevo, limitar los árboles de trabajo a una sola rama y eliminarlos una vez fusionada la rama, utilizando los comandos «git worktree remove» y «git worktree prune» proporcionados.

Los mensajes de confirmación utilizan el encabezado estándar «[ámbito opcional]: », con cuerpo y pie de página opcionales. Una tabla de tipos asigna cada tipo (feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert) a su impacto según SemVer y al uso previsto. Las normas exigen que el asunto tenga 72 caracteres o menos, esté redactado en modo imperativo, no contenga mayúsculas ni un punto al final, incluya una línea en blanco antes del cuerpo del mensaje y señale explícitamente los cambios que rompen la compatibilidad mediante «!» o un pie de página «BREAKING CHANGE:». Cabe destacar que se indica que nunca se debe añadir una firma de Claude, una atribución de agente de IA ni un pie de página «Co-authored-by» para ningún agente de IA. También documenta el cierre de incidencias mediante palabras clave en el pie de página (variantes de «close», «fix» o «resolve») en la rama predeterminada, incluyendo formas entre repositorios y con múltiples incidencias, y advierte de que las fusiones «squash» toman el título de la solicitud de incorporación de cambios (PR) como mensaje de confirmación, por lo que el título debe seguir la convención.

Preguntas frecuentes

¿Qué formato deben seguir los nombres de las ramas?

«/[issue-] », en minúsculas y solo con guiones, por ejemplo, «feat/42-user-authentication». Añade el número de incidencia como prefijo cuando exista y mantén la descripción por debajo de los 50 caracteres.

¿Dónde deben colocarse los «worktrees» de Git y cómo se nombran?

En .claude/worktrees/, y deben nombrarse reflejando el nombre de la rama, sustituyendo la barra por un guión. La palabra «worktree» nunca debe aparecer en el nombre de una rama, ya que los worktrees son un mecanismo de checkout local.

¿Esta habilidad añade un trailer «Co-authored-by» para los agentes de IA?

No. Indica explícitamente que nunca se debe añadir una firma de Claude, una atribución de agente de IA ni el trailer «Co-authored-by» para Claude o cualquier otro agente de IA a las confirmaciones.

¿Cómo se marca un cambio compatible con versiones anteriores en una confirmación?

Utiliza un «!» después del tipo o el ámbito, o añade un pie de página «BREAKING CHANGE:», lo que activa un salto de versión MAJOR. Un cambio compatible que solo se describa en el cuerpo del commit no será visible para las herramientas de registro de cambios.

¿Cómo puede una confirmación cerrar una incidencia automáticamente?

Incluye una palabra clave como «Closes», «Fixes» o «Resolves» junto con la referencia del issue en el pie de página; se activará al fusionarse con la rama predeterminada. Se admiten formas que abarcan varios repositorios y múltiples issues, como «Closes owner/repo#42».

Todos los archivos

2archivos evals/evals.json 12,1KB Ver SKILL.md 7,2 KB Ver

Ver en GitHub

Follow Conventional Commits v1.0.0 for both branch names and commit messages — consistent naming lets tools auto-generate changelogs, enforce SemVer bumps, and filter history by concern.

Branch Naming

Format: <type>/[issue-]<description> — lowercase, hyphens only, no special chars except /.

feat/user-authenticationfeat/42-user-authenticationfix/login-race-conditionfix/87-login-race-conditiondocs/api-reference-updaterefactor/payment-module

Prefix with the issue number when one exists — GitHub and GitLab auto-link it and it makes git log immediately traceable to the tracker. Keep the description under 50 characters — most git UIs truncate branch names in lists around that length. Match the type to the work you're doing — this is the contract readers use to understand the branch purpose at a glance.

NEVER include worktree in a branch name — git worktrees are a local checkout mechanism, not a branch concept; the name would leak implementation details into the remote and confuse other contributors.

Worktree Naming

Worktrees are local checkout directories — they never appear in the remote. Place them under .claude/worktrees/ and name them by replacing the branch / separator with -.

git worktree add .claude/worktrees/feat-user-authentication feat/user-authenticationgit worktree add .claude/worktrees/fix-87-login-race-condition fix/87-login-race-condition

The directory name mirrors the branch name so git worktree list stays readable and each worktree is immediately traceable to its branch without inspecting the checkout. Run git worktree list before creating a new one — reuse an existing worktree if it already covers the same branch.

Keep worktrees scoped to a single branch. Doing unrelated work inside someone else's worktree obscures which changes belong where and makes cleanup error-prone.

Remove the worktree once its branch is merged — either after a local merge or after the pull/merge request is closed on the remote. Stale worktrees accumulate and make git worktree list unreadable.

git worktree remove .claude/worktrees/feat-user-authentication   # branch merged locallygit worktree prune                                                # remove refs to already-deleted directories

Commit Message Format

<type>[optional scope]: <description>[optional body][optional footer(s)]

Types:

Type	SemVer	When
`feat`	MINOR	New feature
`fix`	PATCH	Bug fix
`docs`	—	Docs only
`style`	—	Formatting, no logic change
`refactor`	—	Restructure, no feature/fix
`perf`	—	Performance improvement
`test`	—	Add/fix tests
`build`	—	Build system, deps
`ci`	—	CI config
`chore`	—	Anything else (not src/test)
`revert`	—	Reverts a previous commit

Rules:

Subject line ≤ 72 characters — git log and GitHub/GitLab UIs silently truncate longer subjects
Imperative mood: "add" not "added" — reads as an instruction, not a history log
No capital letter, no trailing period — enforces uniform parsing by changelog tools
Body separated by blank line — parsers split header/body at the first blank line
Breaking changes: use ! after type/scope, or add BREAKING CHANGE: footer (triggers MAJOR bump) — body-only descriptions are invisible to changelog tools
revert commits SHOULD include This reverts commit <hash>. in the body — git revert generates this automatically; don't strip it
NEVER add a Claude signature, AI agent attribution, or Co-authored-by trailer for Claude or any other AI agent to commits

Examples:

feat(auth): add JWT token refresh

fix: prevent race condition on concurrent requestsIntroduce request ID and reference to latest request.Dismiss responses from stale requests.

refactor!: drop support for Go 1.18BREAKING CHANGE: Go 1.18 no longer supported; uses stdlib APIs from 1.21+

Closing Issues via Commit Messages

Both GitHub and GitLab detect keywords in commit messages and automatically close the referenced issue when the commit lands on the default branch. Place the reference in the footer (preferred — keeps the subject line clean).

Keywords: close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved — case-insensitive.

GitHub:

fix(auth): prevent token expiry race conditionCloses #42Closes owner/repo#99

Triggers when merged into the default branch (usually main)
Cross-repo: Closes owner/repo#42
Close multiple: Closes #42, closes #43
Works in PR descriptions too

GitLab:

feat: add dark mode supportResolves #101Closes group/project#42

Triggers when merged into the default branch (configurable per project)
Cross-project: Closes group/project#42
Close multiple: Closes #101, closes #102
Works in MR descriptions too

Tip: Pair with the commit type — fix: closing a bug issue, feat: closing a feature request — keeps the changelog semantically coherent.

Common Mistakes

Mistake	Fix
`feat: Added login page`	`feat: add login page` — imperative, no capital
`fix: fix bug.`	`fix: fix bug` — no trailing period
Subject over 72 chars	Shorten; move detail to body
Breaking change only in body	Add `!` or `BREAKING CHANGE:` footer — tools won't detect body-only
`feat(adding-auth): ...`	`feat(auth): ...` — scope is a noun, not a verb
Closes #42 in subject line	Move to footer — keeps subject clean and parseable

Best Practices

Align branch type and commit type — feat/auth-* branch → feat(auth): commits
One concern per branch — mixing fixes into feature branches obscures the changelog
Use scope consistently within a branch — feat(auth): throughout, not feat(user): mid-way
Squash merge: when squash-merging a PR/MR, the branch commits are collapsed into one — the PR/MR title becomes the commit message. If the title doesn't follow conventional commits format, changelog generation breaks silently. Always set the PR title before squashing.