AI Skill Report Card

Creating Contextual Branch and PR

B74·Aug 18, 2026·Source: Web
14 / 15
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
Recommendation
Mixed language usage (Portuguese in Workflow/Best Practices/Pitfalls, English elsewhere) hurts consistency and clarity — standardize on one language throughout the skill.
13 / 15

Progress:

  • Step 1: Rodar git status e git diff para 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 status para ver arquivos modificados/novos/deletados.
  • git diff (ou git 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 funcionalidade
  • fix/<descricao> — correção de bug
  • chore/<descricao> — manutenção, configs, deps
  • hotfix/<descricao> — correção urgente em produção
  • release/<versao> — preparação de release

Nome curto, minúsculo, sem espaços, refletindo o objetivo (ex: feature/add-user-login).

3. Criar a branch

Bash
git 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.
Bash
git 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

Bash
git 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.

Recommendation
Add a third example showing a mixed/ambiguous case (e.g., changes spanning multiple unrelated contexts) to demonstrate how to split into separate branches/PRs.
13 / 20

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 users
    • test(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.21
    • docs(readme): fix typo in installation section
  • PR título: chore: update dependency and fix docs typo
Recommendation
Include guidance on edge cases like handling merge conflicts, empty diffs, or when the base branch has diverged significantly before branch creation.
  • 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 --fill do gh/glab quando 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 fix ou update.
  • 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.
0
Grade BAI Skill Framework
Scorecard
Criteria Breakdown
Quick Start
14/15
Workflow
13/15
Examples
13/20
Completeness
15/20
Format
14/15
Conciseness
12/15