---
title: "Primeiro pull request como dev junior: como abrir PR sem travar o time"
url: "https://eu.dev.br/carreira/primeiro-pull-request-dev-junior/"
markdown_url: "https://eu.dev.br/carreira/primeiro-pull-request-dev-junior.MD"
description: "Seu primeiro PR no emprego não precisa impressionar. Precisa ser pequeno, legível, testado e fácil de revisar. Veja como abrir pull request como dev junior."
date: "2026-05-21"
author: ""
---

# Primeiro pull request como dev junior: como abrir PR sem travar o time

Seu primeiro PR no emprego não precisa impressionar. Precisa ser pequeno, legível, testado e fácil de revisar. Veja como abrir pull request como dev junior.


O primeiro pull request como dev junior costuma parecer uma apresentação pública da sua competência. Você abre a tela, vê o botão verde, lê a diferença de arquivos, pensa no tech lead olhando seu código e começa a imaginar tudo que pode estar errado.

Respira.

Pull request não é palco. É ferramenta de colaboração. O objetivo do seu primeiro PR não é provar que você nasceu pronto para ser pleno. É deixar uma mudança pequena passar pelo fluxo real do time com o mínimo de ruído possível: contexto claro, escopo controlado, teste feito, dúvida explícita e abertura para review.

Junior bom não é quem abre PR gigante. É quem facilita revisão.

Se você ainda está entendendo o ambiente, leia também o guia de [primeira semana como dev junior](/carreira/primeira-semana-dev-junior/) e o roteiro de [primeiros 30 dias como dev junior](/carreira/primeiros-30-dias-dev-junior/). Este texto entra no detalhe do momento em que sua primeira tarefa vira código revisável.

## antes do código: confirme o tamanho da tarefa

O erro começa antes do commit. Muita gente junior recebe uma tarefa pequena, descobre três problemas ao redor e tenta resolver tudo junto para mostrar capricho.

Não faça isso no primeiro PR.

Seu primeiro objetivo é passar pelo fluxo inteiro: branch, mudança, teste, descrição, review, ajuste, merge e talvez deploy. Para aprender esse caminho, escopo pequeno é melhor que escopo ambicioso.

Antes de codar, confirme:

```text
Minha leitura da tarefa:
- ajustar validação do campo telefone
- mostrar mensagem quando o DDD estiver ausente
- não mexer no fluxo de cadastro fora desse caso

É esse o escopo certo para o primeiro PR?
```

Essa mensagem evita o clássico PR que vira surpresa. Também mostra que você entendeu uma regra importante: código bom fora de escopo ainda pode atrapalhar.

Se encontrar um problema real no caminho, não misture sem perguntar:

> Achei também uma inconsistência na máscara do campo. Posso abrir um segundo ticket/PR para isso depois ou faz parte desta tarefa?

Isso separa iniciativa de bagunça.

## escolha um nome de branch simples

Não precisa inventar. Use o padrão do time se existir. Se não existir, algo direto basta:

```text
fix/telefone-ddd-cadastro
chore/readme-setup-local
test/cadastro-campo-obrigatorio
```

Branch boa ajuda quem revisa a entender intenção sem abrir cinco telas. Evite nomes genéricos como `ajustes`, `fix`, `teste`, `minha-branch` ou `mudancas-finais`.

Se a empresa usa ticket, inclua o ID se esse for o padrão:

```text
abc-123-fix-telefone-ddd
```

O ponto não é estética. É rastreabilidade. Daqui a três meses, alguém precisa entender de onde veio aquela mudança.

## faça o menor código que resolve o caso combinado

O primeiro PR não é o lugar para refatorar o arquivo inteiro. Se você mexe em validação, não reorganize componente. Se muda texto, não formate imports. Se adiciona teste, não troque biblioteca.

Mudanças misturadas tornam review mais difícil porque o revisor precisa separar três coisas:

- o que resolve a tarefa;
- o que é limpeza opcional;
- o que pode ter quebrado algo sem necessidade.

Para dev junior, isso é perigoso porque aumenta o volume de comentários e dá a sensação de que o time está criticando tudo. Na verdade, o PR ficou grande demais.

Uma regra prática:

> Se eu não consigo explicar por que este arquivo mudou em uma frase, talvez ele não pertença a este PR.

Exemplo de frase boa:

> `signup.ts` mudou porque a validação de telefone fica ali.

Exemplo de alerta:

> `layout.css` mudou porque eu aproveitei para arrumar umas coisas.

"Aproveitei" é quase sempre sinal de escopo escapando.

## teste antes de abrir o PR

Abrir PR sem testar o básico passa a mensagem errada. Você não precisa prever todos os casos do sistema, mas precisa mostrar que conferiu o que estava ao seu alcance.

Antes de abrir, rode o que o projeto usa:

```text
npm test
go test ./...
pytest
bundle exec rspec
cargo test
```

Se não sabe qual comando roda, pergunte cedo:

> Qual comando vocês esperam que eu rode antes de abrir PR neste repo?

Além de teste automatizado, faça teste manual do caso principal. Para uma validação de telefone, por exemplo:

- telefone válido passa;
- telefone sem DDD mostra erro;
- campo vazio segue a regra esperada;
- tela ainda carrega sem erro no navegador.

Se algum teste falha por motivo já conhecido, não esconda. Escreva na descrição:

```text
## testes
- rodei `npm test`
- 1 teste legado falha em `UserAddress.test`, mesmo sem minhas mudanças
- testei manualmente cadastro com telefone válido, sem DDD e vazio
```

Isso é melhor do que fingir que está tudo verde.

## escreva descrição para quem revisa

Descrição de PR não é diário. Também não é lugar para pedir desculpa por existir. É um resumo operacional.

Um bom modelo para junior:

```markdown
## o que muda
- corrige validação do campo telefone no cadastro
- mostra mensagem quando o DDD está ausente

## como testei
- rodei `npm test`
- testei cadastro com telefone válido, sem DDD e vazio

## contexto
- ticket ABC-123
- mantive o escopo só na validação combinada
- dúvida: faz sentido cobrir telefone internacional agora ou fica para outro PR?
```

Repare em três coisas.

Primeiro: a descrição fala do comportamento, não só dos arquivos. "Muda `Form.tsx`" ajuda pouco. "Mostra erro quando DDD está ausente" ajuda muito.

Segundo: o teste está explícito. Revisor não precisa adivinhar se você rodou algo.

Terceiro: a dúvida aparece como dúvida. Junior não precisa ter certeza de tudo. Precisa deixar incerteza visível.

Se o PR tiver imagem, vídeo ou antes/depois, inclua. Para mudança visual pequena, um print evita comentário desnecessário. Só não transforme a descrição em mural gigante.

## abra PR menor do que sua ansiedade quer

Ansiedade empurra para dois extremos.

Um extremo é abrir cedo demais, sem revisar, porque você quer se livrar da tarefa. O outro é segurar por tempo demais, polindo em silêncio, porque tem medo do review.

O caminho bom fica no meio: abra quando o escopo combinado está resolvido, os testes básicos passaram e você revisou o diff.

Revise seu próprio diff antes:

- tem arquivo que mudou sem querer?
- sobrou `console.log`, comentário temporário ou código morto?
- a descrição do PR bate com os arquivos alterados?
- tem teste ou justificativa para não ter teste?
- o PR responde ao ticket original?

Esse ritual de cinco minutos evita muito comentário bobo.

Se ainda estiver inseguro, peça review com contexto:

> Abri o PR pequeno para passar pelo fluxo. Minha principal dúvida é se a validação ficou no lugar certo ou se o time prefere concentrar isso no schema.

Isso direciona o revisor. Em vez de "me avalia", você diz onde precisa de orientação.

## responda review sem virar debate

Review pode doer porque parece que a pessoa está apontando defeito em você. Na maior parte das vezes, ela está protegendo o código, o produto e você.

Respostas boas:

```text
Boa, não tinha considerado esse caso. Vou adicionar teste.
```

```text
Entendi. Vou seguir o padrão do arquivo X para manter consistência.
```

```text
Não entendi totalmente o risco aqui. Pode me dar um exemplo de entrada que quebraria?
```

Respostas ruins:

```text
Mas funciona na minha máquina.
```

```text
Fiz assim porque vi num tutorial.
```

```text
Não acho que precisa, mas mudei.
```

Você pode discordar, claro. Mas discorde com evidência, não com ego:

> Pensei em manter assim porque evita mexer no fluxo antigo e o ticket pede só o caso novo. Mas se o risco de duplicar validação for maior, ajusto para o schema. Qual caminho você prefere?

Isso mostra julgamento sem bater de frente.

## faça os ajustes em commits claros

Depois do review, ajuste uma coisa de cada vez quando possível. Não responda todos os comentários com "feito" se ainda não subiu código. Não marque conversa como resolvida se não entendeu.

Um bom ciclo:

1. leia todos os comentários antes de mudar;
2. agrupe os que têm relação;
3. ajuste código e teste;
4. responda com contexto curto;
5. peça nova revisão.

Exemplo:

```text
Atualizei para usar o schema existente e adicionei teste para telefone sem DDD. Rodei `npm test` de novo.
```

Isso economiza tempo do revisor. Ele sabe o que mudou desde a última olhada.

## depois do merge, aprenda com o PR

O PR não acaba quando entra em `main`. Para junior, ele vira material de aprendizado.

Depois do merge, anote:

```text
PR #123 - validação de telefone

O que aprendi:
- validação deve ficar no schema, não no componente
- teste precisa cobrir campo vazio e DDD ausente
- descrição boa economizou pergunta no review

Para o próximo PR:
- olhar testes parecidos antes de implementar
- mencionar ticket na descrição
```

Esse registro conversa com o guia de [primeiros 90 dias como dev junior](/carreira/primeiros-90-dias-dev-junior/): review repetido vira plano de evolução. Se três PRs voltam com comentário de teste, seu plano não é "estudar mais". É mudar o ritual antes de abrir PR.

## quando pedir ajuda antes de abrir

Pedir ajuda não é fracasso. Mas pedir ajuda sem contexto cansa o time.

Mensagem fraca:

> Não consegui. Alguém pode me ajudar?

Mensagem boa:

```text
Estou na task ABC-123, validação de telefone.

O que já fiz:
- encontrei a validação atual em `signupSchema`
- reproduzi o caso sem DDD
- adicionei teste, mas ele falha antes de chegar na validação

Minha hipótese:
- o campo está sendo normalizado antes do schema

Pergunta:
- faz sentido investigar a normalização primeiro ou estou olhando no lugar errado?
```

Isso permite que alguém te ajude em cinco minutos em vez de fazer entrevista para descobrir o problema.

Se a tarefa encostar em dado sensível, pagamento, produção, migração, segurança ou rollback, peça ajuda antes. O guia de [primeiro bug em produção como dev junior](/carreira/primeiro-bug-producao-dev-junior/) aprofunda esse cuidado depois que algo quebra, mas a maturidade começa antes: reconhecer risco cedo.

## checklist antes de clicar em criar PR

Use este checklist nas primeiras semanas:

- [ ] o escopo está claro e pequeno;
- [ ] o nome da branch faz sentido;
- [ ] revisei meu próprio diff;
- [ ] removi logs, código morto e mudanças acidentais;
- [ ] rodei o teste esperado ou expliquei por que não rodei;
- [ ] testei manualmente o caso principal;
- [ ] escrevi o que muda, como testei e contexto;
- [ ] deixei dúvidas explícitas;
- [ ] não misturei refactor fora de escopo;
- [ ] estou pronto para receber comentário sem me defender.

Esse checklist parece simples. É exatamente por isso que funciona.

## a régua certa para o primeiro PR

Seu primeiro pull request como dev junior não precisa ser brilhante. Precisa ser revisável.

Revisável significa que a pessoa do outro lado consegue entender o problema, olhar o código, conferir o teste, comentar o que falta e confiar que você vai ajustar sem drama.

Se o revisor pensa "esse PR é pequeno, claro e a pessoa responde bem", você já ganhou muito. Não porque escreveu o código perfeito, mas porque mostrou o comportamento que sustenta carreira: reduzir ruído, aceitar feedback, testar o que mexeu e voltar melhor no próximo ciclo.

É assim que confiança começa. Um PR pequeno de cada vez.