Definir fluxo de branches e releases
Use este guia como lente principal para esta situação.
Git e versionamento Guia para IA
Controlando Versões com Git e GitHub
Histórico, branches, repositórios remotos, tags, conflitos e modelos de colaboração.
- Autor
- Alexandre Aquiles e Rodrigo Ferreira
- 209 páginas
- Formato do guia
- Markdown no padrão dos modelos originais + instruções operacionais para IA
Orientação
Como utilizar este .md
Não apenas “anexe e peça para programar”. Dê papel, contexto e critérios.
Anexe o .md junto com o requisitoO guia passa a ser a referência de engenharia para aquela tarefa.
Descreva contexto e restriçõesStack, estrutura atual, legado, prazo, compatibilidade, usuários e comportamento que não pode mudar.
Peça diagnóstico antes de soluçãoA IA deve identificar o problema e escolher somente os princípios relevantes.
Implemente em passos verificáveisEvite reescrita ampla. Peça testes, critérios de aceite e plano de rollback quando necessário.
Faça revisão contra o guiaNo final, peça divergências, riscos, trade-offs e pontos ainda não cobertos.
Casos de uso
Quando este guia é especialmente útil
Criar estratégia de commits/tags
Use este guia como lente principal para esta situação.
Orientar merge, rebase e conflitos
Use este guia como lente principal para esta situação.
Planejar colaboração e recuperação segura
Use este guia como lente principal para esta situação.
warning Limite de uso
Não reescreva histórico compartilhado sem entender o impacto; preserve recuperação e rastreabilidade.
Não reescreva histórico compartilhado sem entender o impacto; preserve recuperação e rastreabilidade.
Prompt pronto
Modelo para começar
Use o guia “Controlando Versões com Git e GitHub” anexado como referência para analisar este projeto. Antes de alterar código: 1. Faça um diagnóstico do problema no contexto do projeto. 2. Identifique quais princípios do guia realmente se aplicam. 3. Compare a solução atual com uma alternativa mais simples. 4. Proponha uma mudança incremental e reversível. 5. Defina testes e critérios de aceite. 6. Ao final, revise a implementação contra o guia e liste trade-offs. Contexto: [DESCREVA o sistema, stack, estado atual e cenário da mudança] Objetivo: [DESCREVA o resultado observável que deve existir ao final] Restrições: [DESCREVA o que não pode mudar, compatibilidade e limites técnicos]
Exemplo preenchido — o que o usuário pode descrever
Use o modelo acima com dados concretos do projeto. O exemplo abaixo mostra o nível de detalhe esperado.
Contexto: Repositório com branch main e várias funcionalidades simultâneas; equipe tem conflitos frequentes e tags não são usadas. Objetivo: Definir fluxo simples de branches, integração, commits e tags para releases com histórico compreensível. Restrições: Não reescrever commits já compartilhados; preservar main estável; documentar estratégia de merge/rebase e recuperação.
ContextoStack, versões, arquitetura, página/módulo afetado, estado atual e comportamento existente.
ObjetivoResultado observável para o usuário ou para o sistema; diga o que deve funcionar ao final.
RestriçõesO que não pode mudar, compatibilidade, segurança, acessibilidade, performance, prazo e limites de escopo.
1. Diagnosticar
Peça análise do código e do problema antes de aplicar qualquer padrão ou princípio.
2. Decidir
Exija justificativa: por que esta técnica é adequada e quais alternativas foram descartadas.
3. Verificar
Finalize com testes, checklist, riscos e critérios de aceite.