gener8v/gener8v.claude-skills.engineering

Git branching

Cada alteração vai no seu próprio branch. Isso inclui uma correção de uma linha e uma alteração sem issue. Não faça commit no branch base.

1. Encontre o branch base

Use a primeira fonte que der uma resposta:

1. Instruções do repositório. Leia CLAUDE.md, CONTRIBUTING.md e documentos em .github/. Se eles nomearem um branch base ou de integração, use-o.
2. Branch padrão remoto.

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

3. Ambiguidade. Se o remoto também tiver develop ou development e nenhum documento disser qual é o base, pergunte ao usuário. Não adivinhe.

Quando um branch de integração (por exemplo develop) é o base, uma hotfix para uma versão lançada começa a partir do branch padrão. Use isso apenas quando o usuário chamar o trabalho de hotfix.

2. Verifique onde você está

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

• Se a árvore de trabalho tiver alterações que você não fez, pare. Pergunte ao usuário o que fazer com elas.
• Se você já estiver em um branch para este mesmo trabalho, permaneça nele.
• Se você estiver no branch base com suas próprias edições não commitadas, mova-as: git switch -c <nome> as mantém na árvore de trabalho.

3. Inicie o branch a partir da ponta remota

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

Começar de origin/<base> significa que um branch local desatualizado não causa problemas. Não execute git pull no branch base para "atualizar" primeiro. Não é necessário.

4. Nomeie o branch

Use a convenção do repositório se houver. Se não, use <tipo>/<ref>-<slug>:

Parte	Valores
tipo	feat, fix, docs, chore, refactor, test, release, hotfix
ref	Número da issue (42), ticket do pipeline (ticket-007) ou nada
slug	Duas a cinco palavras em minúsculo, unidas por hífens

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

5. Enquanto você trabalha

• Faça commits em passos pequenos que façam sentido isoladamente. Escreva o assunto no imperativo, com 72 caracteres ou menos. Use o corpo para dizer o porquê.
• Não adicione um trailer Co-Authored-By: Claude a nenhuma mensagem de commit. Esta é uma regra da gener8v.
• Antes do primeiro push, você pode fazer rebase em origin/<base>. Depois que o branch for enviado, faça merge do base no branch. Um rebase de um branch já enviado reescreve o histórico, e engineering:git-safety controla isso.
• Faça push com uma cadeia que pare ao primeiro erro:

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

  Sem set -o pipefail, | tail esconde o código de saída do comando anterior. Nunca pipe um comando git ou um comando de teste através de tail sem ele.

Trabalho paralelo

Para dois ou mais agentes que editam código ao mesmo tempo, leia resources/parallel-work.md antes de iniciar qualquer agente. Resumindo: um branch de lote a partir do base, uma worktree e um branch por agente a partir do branch de lote, e nenhum dois agentes nos mesmos arquivos.

Pronto quando

• Você está em um branch com um nome claro, e ele começa no origin/<base> atual.
• git status não mostra alterações que pertencem a outra pessoa.

Skills relacionadas

• engineering:github-pr-merge: abra o PR quando o trabalho estiver completo.
• engineering:git-safety: regras de aprovação para force-push, exclusão de branch e comandos similares.
• engineering:github-issue-workflow: o ciclo de vida completo de uma issue ou ticket de pipeline. Esta skill é chamada primeiro.