Daniel-DB-hub/developer-portfolio

Seguindo o Fluxo de Trabalho Git

Regra Principal

production é a única branch de longa duração. Nunca trabalhe diretamente nela.

Antes de qualquer ação de escrita no Git:

1. Execute git status --short --branch.
2. Confirme que não há arquivos ou alterações inesperadas.
3. Busque o remoto.
4. Crie ou mude para uma branch de tarefa de curta duração.
5. Mantenha a branch limitada a um único objetivo.

Nomes de Branches

Use:

• feat/<escopo>
• fix/<escopo>
• hotfix/<escopo>
• test/<escopo>
• docs/<escopo>
• refactor/<escopo>
• chore/<escopo>

Use kebab-case em minúsculas. Nunca use main, dev-production, changes, update ou nomes igualmente vagos.

Antes do Commit

1. Revise git diff e git diff --staged.
2. Remova arquivos não relacionados.
3. Pare se aparecerem segredos, evidências privadas, URLs internos, sessões brutas de IA, dados de clientes ou dados de estudantes.
4. Execute as verificações relevantes para o escopo alterado.
5. Use uma mensagem de Commit Convencional.
6. Nunca adicione um trailer de coautor de IA a menos que explicitamente solicitado.

Push e Pull Request

• Nunca faça push diretamente para production.
• Nunca force-push production.
• Nunca ignore hooks ou verificações obrigatórias.
• Nunca use --force simples.
• Use --force-with-lease em uma branch de tarefa apenas após aprovação explícita.
• Toda alteração na produção passa por um pull request.
• Siga o .github/pull_request_template.md.

Limite de Merge

Claude deve parar antes do merge, a menos que Randi aprove explicitamente a mesclagem do pull request específico na conversa atual.

Use apenas squash merge. Exclua a branch de tarefa após o merge.

Relatório de Conclusão

Relate:

• Branch
• Commits
• Verificações executadas e resultados
• Estado do pull request
• Revisão de confidencialidade
• Riscos restantes
• Se a aprovação do merge ainda é necessária

Política Completa

Leia e siga:

• docs/governance/git-workflow.md
• docs/governance/github-configuration.md