Git no Currículo: Branches, Pull Requests e Code Review Com Prova

Git aparece em boa parte das vagas de desenvolvimento, e quase sempre aparece como uma palavra numa lista de ferramentas, sem frase ao redor. O recrutador que lê essa lista não sabe se a pessoa criou um repositório para estudar ou se trabalhou num time que revisava cada mudança antes de publicar. Git no currículo ganha peso quando mostra o fluxo: em que branch você trabalhou, como uma mudança chegou à branch principal, quem a revisou e o que fez quando havia conflito. Este guia mostra como escrever cada parte e o que fazer quando o seu uso foi sozinho.

Escrever Git numa lista de ferramentas não mostra como você o usou

A lista de ferramentas prova que a palavra está no texto, e nada além disso. Coloque o Git na linha da experiência em que ele apareceu, junto da entrega que ele tornou possível. Uma frase que diz o que foi entregue e por qual caminho responde à pergunta que o recrutador faz ao ler a palavra: essa pessoa trabalhou com código de outros, ou só instalou a ferramenta?

Antes: Git, GitHub e controle de versão.

Depois: Desenvolvi o módulo de notificações em branches por funcionalidade e entreguei cada uma por pull request, com revisão de um colega antes da fusão na branch principal.

Se a vaga pede a ferramenta pelo nome, use o nome exatamente como a vaga escreve. A página de palavras-chave para desenvolvedor full stack mostra os termos que essas vagas costumam trazer, e a descrição da própria vaga mostra as palavras do fluxo que o time espera. Se o campo de experiência for o da Gupy, com regras de preenchimento próprias, o guia de campo de experiência da Gupy mostra como ele se encaixa.

Qual fluxo o time seguia, e como descrevê-lo sem jargão

Descreva o fluxo que a equipe usava, porque é a parte que o recrutador técnico reconhece de imediato. Três modelos aparecem com frequência, e você não precisa saber o nome oficial de cada um, só qual era o seu:

• Branch por funcionalidade. Cada tarefa ganha uma branch própria, criada a partir da principal, e volta para ela por pull request depois da revisão. É o modelo mais comum em times pequenos e médios.
• Git Flow. Há branches permanentes de desenvolvimento e de release, e as correções urgentes saem de uma branch de hotfix. É comum em produtos que publicam em ciclos fixos.
• Trunk-based. Todo mundo integra à principal em commits pequenos e frequentes, com branches de vida curta e funcionalidades escondidas por flags. Exige uma bateria de testes forte, e vale dizer isso quando a descrição for essa.

Escreva o modelo só se tiver certeza de qual era. Se o time usava branch por funcionalidade e você diz trunk-based, a pergunta seguinte é sobre flags, e aí a diferença aparece. Para a linha do currículo, basta algo como trabalhei com branches por funcionalidade e entrega por pull request. Se o seu trabalho foi em back-end, o guia de currículo de desenvolvedor back-end mostra como escrever a linguagem e o framework junto desse fluxo.

Pull request com descrição clara prova o que você entregou

O pull request é o registro de uma entrega, e a descrição dele é o que o revisor lê antes do código. Uma boa descrição diz qual problema a mudança resolve, o que mudou e como alguém pode testar. No currículo, o que importa é o resultado dessa entrega, e não o número de pull requests abertos.

Antes: Abri mais de cinquenta pull requests no projeto.

Depois: Entreguei a migração do cadastro de clientes em oito pull requests pequenos, cada um com teste de regressão, sem parar o atendimento.

Se for citar um número, faça-o da entrega: o tamanho do módulo, o prazo ou a quantidade de usuários afetados. Pull request é o veículo, e a linha precisa dizer o que ele carregou. Se o fluxo termina num pipeline que roda a cada pull request, o guia de CI/CD no currículo mostra como descrever essa etapa.

Revisar código de colegas vira linha própria quando você deu o parecer

Revisar código é uma competência separada de escrevê-lo, e vagas de nível pleno e sênior costumam pedir as duas. Se você aprovou ou pediu mudanças no código de outras pessoas, escreva a revisão como função própria. Participar de code review diz que você estava na lista de revisores. Revisar diz o que você fez com ela.

Antes: Participação em code review.

Depois: Revisei pull requests da equipe de pagamentos, com foco em tratamento de erro e testes, e fui um dos dois revisores obrigatórios para mudanças no esquema do banco.

Só escreva a revisão se você fez de fato, com comentários na plataforma e pedidos de mudança que chegaram ao autor. Quem perguntar como você revisou uma mudança espera ouvir um caso concreto, e quem só leu pull requests sem comentar não tem esse caso.

Conflito de merge só vira prova de trabalho em equipe quando você explica o caso

Conflito acontece quando duas pessoas alteraram as mesmas linhas, e resolver um deles é trabalho real. Mas a frase resolvi conflitos de merge não diz nada, porque todo time que usa Git tem conflito. O que diferencia é o caso: o que estava em jogo, quem era a outra pessoa e como vocês decidiram qual mudança ficava.

Antes: Resolução de conflitos de merge.

Depois: Resolvi conflitos entre a reformulação do fluxo de login e a branch de correções de segurança, alinhando com o autor de cada lado qual regra prevalecia antes da fusão.

Cuidado com rebase. Ele reescreve o histórico, e isso é perigoso numa branch que outras pessoas usam. Escreva rebase só se você já o usou em branch compartilhada e sabe explicar por que um histórico publicado não deve ser reescrito. Se você só usou o comando depois de ler um tutorial, deixe a palavra de fora, porque é nela que a primeira pergunta técnica costuma começar.

Versionamento e releases entram como entrega quando têm dono

Em times que publicam versões, o trabalho com tags e correções urgentes mostra que você esteve perto da produção. Escreva o processo, e não a palavra versionamento: quem cortava a versão, como a tag era criada e como uma correção urgente chegava ao ambiente sem esperar a próxima entrega.

Antes: Versionamento de código com Git e tags.

Depois: Cortei as releases semanais com tags de versão e publiquei duas correções urgentes no mesmo dia, ambas revisadas pelo líder técnico antes do deploy.

Se você não tinha esse papel, não o atribua. Acompanhar a montagem de uma release também é experiência. Basta usar o verbo que descreve o que você fez, como acompanhei ou ajudei, sem assumir o papel de quem cortava a versão.

Sem equipe, o repositório pessoal precisa mostrar o mesmo fluxo, com verdade

Se você estudou ou fez projetos sozinho, o fluxo ainda pode aparecer no currículo, desde que seja o que você de fato seguiu. Crie uma branch para cada funcionalidade do projeto, escreva a descrição de cada pull request contra a branch principal e mantenha o histórico de commits com mensagens que explicam a mudança. Esse histórico é o que um recrutador técnico abre quando clica no seu link.

O que não funciona é inventar uma equipe. Descrever um projeto pessoal como trabalho de time é a linha que a entrevista desfaz na primeira pergunta sobre quem revisou cada pull request. O guia sobre currículo de programador com GitHub e projetos cobre o que o recrutador encontra quando abre a conta, e o guia sobre links no currículo mostra onde o endereço deve ficar. Este texto fica com o fluxo.

O que fazer agora com o seu currículo

Releia a seção de experiência e procure a palavra Git. Se ela aparece sem verbo e sem entrega, troque a linha por outra que diga o que você fez com a ferramenta, em qual fluxo e com que resultado. Depois confira se cada projeto ou emprego diz quem revisou e o que aconteceu com a mudança quando ela chegou.

A consequência de deixar a palavra solta é o recrutador ler Git, não encontrar nada que a sustente e passar para o próximo currículo. A vaga de desenvolvimento pede o processo de trabalho junto da ferramenta, e um texto que mostra só a ferramenta fica para trás. Para conferir se os termos da vaga já aparecem no seu texto, cole a descrição dela na análise ATS gratuita. Ela não pede cadastro e mostra quais termos da vaga o seu currículo já tem e quais faltam.

Perguntas frequentes