gener8v/gener8v.claude-skills.engineering

Ramificación de Git

Cada cambio va en su propia rama. Esto incluye una corrección de una línea y un cambio sin issue. No hagas commit en la rama base.

1. Encuentra la rama base

Usa la primera fuente que dé una respuesta:

1. Instrucciones del repositorio. Lee CLAUDE.md, CONTRIBUTING.md y los documentos de .github/. Si nombran una rama base o de integración, úsala.
2. Rama predeterminada remota.

   git symbolic-ref --short refs/remotes/origin/HEAD   # imprime origin/<nombre>
   gh repo view --json defaultBranchRef -q .defaultBranchRef.name
   

3. Ambigüedad. Si el remoto también tiene develop o development y ningún documento indica cuál es la base, pregunta al usuario. No adivines.

Cuando una rama de integración (por ejemplo develop) es la base, una corrección urgente para una versión publicada comienza desde la rama predeterminada en su lugar. Usa esto solo cuando el usuario llame al trabajo una corrección urgente.

2. Verifica dónde estás

git status --porcelain
git rev-parse --abbrev-ref HEAD

• Si el árbol de trabajo tiene cambios que no hiciste tú, detente. Pregunta al usuario qué hacer con ellos.
• Si ya estás en una rama para este mismo trabajo, quédate en ella.
• Si estás en la rama base con tus propias ediciones sin commit, muévelas: git switch -c <nombre> las mantiene en el árbol de trabajo.

3. Inicia la rama desde el último commit remoto

git fetch origin --prune
git switch -c <nombre> origin/<base>
git log -1 --oneline

Comenzar desde origin/<base> significa que una rama base local desactualizada no causa daño. No ejecutes git pull en la rama base para "ponerte al día" primero. No es necesario.

4. Nombra la rama

Usa la convención del repositorio si la tiene. Si no, usa <tipo>/<ref>-<slug>:

Parte	Valores
tipo	feat, fix, docs, chore, refactor, test, release, hotfix
ref	Número de issue (42), ticket del pipeline (ticket-007), o nada
slug	De dos a cinco palabras en minúsculas, unidas con guiones

Ejemplos: fix/42-null-session-crash, feat/ticket-007-search-filters, docs/readme-install-steps.

5. Mientras trabajas

• Haz commits en pasos pequeños que tengan sentido por sí solos. Escribe el asunto en imperativo, 72 caracteres o menos. Usa el cuerpo para explicar el porqué.
• No agregues un trailer Co-Authored-By: Claude a ningún mensaje de commit. Esta es una regla de gener8v.
• Antes del primer push, puedes hacer rebase sobre origin/<base>. Después de que la rama se haya subido, fusiona la base en la rama en su lugar. Un rebase de una rama ya subida reescribe el historial, y engineering:git-safety controla eso.
• Haz push con una cadena que se detenga en el primer fallo:

  set -o pipefail
  git fetch origin && <comando de prueba> 2>&1 | tail -n 40 && git push -u origin HEAD
  

  Sin set -o pipefail, | tail oculta el código de salida del comando anterior. Nunca pases un comando git o un comando de prueba a través de tail sin él.

Trabajo paralelo

Para dos o más agentes que editan código al mismo tiempo, lee resources/parallel-work.md antes de iniciar cualquier agente. En resumen: una rama de lote desde la base, un árbol de trabajo y una rama por agente desde la rama de lote, y ningún agente trabajando en los mismos archivos.

Terminado cuando

• Estás en una rama con un nombre claro, y comienza en el origin/<base> actual.
• git status no muestra cambios que pertenezcan a otra persona.

Habilidades relacionadas

• engineering:github-pr-merge: abre el PR cuando el trabajo esté completo.
• engineering:git-safety: reglas de aprobación para push forzado, eliminación de ramas y comandos similares.
• engineering:github-issue-workflow: el ciclo de vida completo de un issue o un ticket del pipeline. Esta habilidad se llama primero.