Creating Contextual Branch and PR
Bash# 1. Inspect changes git status git diff # 2. Create branch (pattern-based naming) git checkout -b feature/short-description # or: fix/, chore/, hotfix/, release/ # 3. Stage and commit by context git add <related-files> git commit -m "feat(scope): add short description of change" # 4. Push and open PR git push -u origin feature/short-description gh pr create --fill # or `glab mr create --fill` for GitLab
Progress:
- Step 1: Rodar
git statusegit diffpara entender o que mudou - Step 2: Agrupar arquivos alterados por contexto/funcionalidade
- Step 3: Definir o tipo de branch e nome (padrão de feature branch)
- Step 4: Criar a branch a partir da branch base atualizada
- Step 5: Gerar commits separados por contexto, com mensagens Conventional Commits
- Step 6: Push da branch
- Step 7: Abrir PR/MR com título e descrição baseados nos commits
Detalhes
1. Contextualizar mudanças
git statuspara ver arquivos modificados/novos/deletados.git diff(ougit diff --staged) para entender a natureza da mudança.- Agrupar arquivos que pertencem à mesma alteração lógica (ex: componente + teste + estilo).
2. Nomear a branch Seguir padrão tipo/descrição-curta-com-hifens:
feature/<descricao>— nova funcionalidadefix/<descricao>— correção de bugchore/<descricao>— manutenção, configs, depshotfix/<descricao>— correção urgente em produçãorelease/<versao>— preparação de release
Nome curto, minúsculo, sem espaços, refletindo o objetivo (ex: feature/add-user-login).
3. Criar a branch
Bashgit checkout main git pull origin main git checkout -b feature/add-user-login
4. Commits por contexto (Conventional Commits)
Formato: <tipo>(<escopo opcional>): <descrição curta no imperativo>
Tipos comuns: feat, fix, docs, style, refactor, test, chore, perf, build, ci.
- Um commit por mudança lógica coesa (não misturar contextos diferentes no mesmo commit).
- Mensagem curta (até ~72 caracteres na primeira linha), descrição no corpo se necessário.
Bashgit add src/auth/ git commit -m "feat(auth): add login form validation" git add tests/auth/ git commit -m "test(auth): add unit tests for login validation"
5. Push e abertura do PR/MR
Bashgit push -u origin feature/add-user-login gh pr create --title "feat(auth): add login form validation" --body "Resumo das mudanças, contexto e como testar."
Título do PR/MR deve seguir o mesmo padrão do commit principal; a descrição deve resumir os commits e o contexto da mudança.
Example 1:
Input: Arquivos alterados: src/api/users.ts (novo endpoint), src/api/users.test.ts (testes)
Output:
- Branch:
feature/add-users-endpoint - Commits:
feat(api): add endpoint to list userstest(api): add tests for users endpoint
- PR título:
feat(api): add endpoint to list users
Example 2:
Input: Arquivos alterados: package.json (bump de dependência), README.md (typo)
Output:
- Branch:
chore/update-deps-and-docs - Commits:
chore(deps): bump lodash to 4.17.21docs(readme): fix typo in installation section
- PR título:
chore: update dependency and fix docs typo
- Sempre atualizar a branch base (
pull) antes de criar a nova branch. - Um commit = uma mudança lógica; evitar commits genéricos como "update files".
- Usar escopo no commit quando ajudar a localizar a área afetada (
feat(auth): ...). - Descrição do PR deve incluir: o que mudou, por quê, e como testar.
- Preferir
--filldogh/glabquando os commits já estão bem escritos, pois preenche título/descrição automaticamente.
- Não misturar múltiplos contextos em um único commit ou branch.
- Não usar nomes de branch vagos como
fixouupdate. - Não usar mensagens de commit fora do padrão (
"mudanças","wip","ajustes"). - Não esquecer de rodar testes/lint antes de commitar.
- Não abrir PR sem descrição de contexto, mesmo que o diff seja pequeno.