A sua foto no perfil de portfólio: o avatar do GitHub vem do e-mail do commit

Foto de perfil do GitHub, do Behance e do Dribbble: o que cada um publica

Quem vai subir uma foto de perfil no GitHub, no Behance ou no Dribbble quer uma resposta de arquivo: qual formato entra, quanto pode pesar, quantos pixels. As três plataformas, GitHub para código, Behance e Dribbble para projeto visual, respondem essa pergunta de formas bem desiguais, e uma delas simplesmente não responde.

A tabela abaixo separa duas coisas que a busca em português mistura o tempo todo. Regra publicada é o que a própria plataforma escreveu numa página oficial, e a última linha diz onde. Medição é o que eu obtive puxando os arquivos que essas plataformas servem, em 26/08/2026: vale para aquele dia, não é especificação, não é promessa, e muda quando a plataforma trocar a infraestrutura.

A distinção não é preciosismo. Os números que circulam por aí (220 x 220, 400 x 400, 1.000 x 1.000, 150 x 150) aparecem em páginas que não citam fonte nenhuma, e nenhum deles bate com o que as plataformas de fato entregam. Nas seis páginas editoriais que medi em 26/08/2026, somando 5.259 palavras, a expressão "e-mail do commit" não aparece nenhuma vez, e o número 460 também não.

O resumo, uma linha por plataforma, antes da tabela: o GitHub publica formato, peso e dimensão, mas numa página de referência que a busca em português quase nunca serve; o Dribbble publica formato, peso e uma restrição de recorte que decide o seu fluxo de trabalho; e o Behance não publica nada sobre o avatar, embora a mesma central de ajuda publique número exato para a capa do projeto e para o banner do perfil.

Seis conferências antes de subir a foto no perfil de portfólio

A ordem abaixo é a que evita retrabalho: as três primeiras são sobre o arquivo, e as três últimas são sobre o endereço que decide qual rosto vai aparecer grudado no seu trabalho. Se você só for fazer uma, faça a quarta.

1. Recorte quadrado antes de subir. As três plataformas exibem o avatar em quadrado ou em círculo, e o Dribbble escreve na ajuda que não existe ferramenta de recorte depois do envio. Um arquivo 3:2 enviado ali continua 3:2 no arquivo público, e é cortado só na hora de desenhar.
2. Cabeça grande no quadro. A decisão de enquadramento é tomada para 16 px, não para os 260 px da sua página de perfil. O alvo prático é a cabeça ocupando cerca de 60% da altura do quadro.
3. Contraste entre a cabeça e o fundo. Reduzida a 16 px, a foto vira silhueta: o que separa você do fundo é diferença de luminância, não detalhe. Cabelo escuro em parede escura some.
4. Confira o e-mail configurado para os seus commits. Nas seis páginas editoriais que medi para esta pauta em 26/08/2026, só uma cita a configuração do Git, e sem explicar o motivo. É o passo que decide o rosto que assina o seu histórico, e os comandos estão logo abaixo.
5. Adicione esse endereço à sua conta ou, se você não quiser o e-mail pessoal gravado em texto puro no histórico público, use o endereço noreply da conta, no formato [email protected] para contas criadas depois de 18/07/2017. O vínculo passa a valer para os commits seguintes.
6. Repita a conferência em cada máquina onde você commita: computador de casa, notebook do trabalho, servidor, contêiner de desenvolvimento. A doc do GitHub pede isso com todas as letras, e é por isso que o sintoma reaparece sozinho meses depois.

Os três comandos da quarta conferência, na ordem em que vale a pena rodar:

git config user.email             # o e-mail definido neste repositório
git config --global user.email    # o e-mail padrão desta máquina
git log -1 --format='%ae'         # o e-mail gravado no último commit

As duas primeiras linhas mostram a configuração; a terceira mostra o que de fato foi gravado, e é essa que vale. Se o endereço devolvido pela terceira linha não estiver na lista de e-mails da sua conta, o avatar ao lado daquele commit não vai ser o seu, por mais correta que esteja a foto do seu perfil. A seção seguinte explica por quê.

O avatar dos seus commits não vem do upload: ele vem do e-mail

Aqui a foto de perfil de um portfólio de código deixa de ser assunto de arquivo. A página Troubleshooting commits, da documentação do GitHub, consultada em 26/08/2026, escreve o mecanismo em uma frase: "GitHub links a commit to a user by matching the email address in the commit header to an email address on a GitHub account". Em português: o GitHub liga um commit a um usuário comparando o endereço de e-mail do cabeçalho do commit com um endereço de e-mail cadastrado numa conta do GitHub.

Repare no que a frase não diz. Ela não fala de quem fez o push, não fala de quem está logado no navegador e não fala de upload. O que decide é um texto gravado dentro do próprio commit, no instante em que ele foi criado. O avatar é consequência: se existe conta ligada, aparece a imagem daquela conta; se não existe, não há de onde tirar rosto nenhum.

Quem grava esse texto é a configuração local do Git. A página sobre o endereço de e-mail dos commits publica: "GitHub uses the email address set in your local Git configuration to associate commits pushed from the command line with your account on GitHub", e o comando que ela mostra é git config --global user.email "YOUR_EMAIL". O limite está na própria frase: isso vale para commit feito pela linha de comando. Operação feita pela interface web usa o endereço escolhido nas configurações da conta.

Com esse mecanismo na mão, os três estados possíveis do seu histórico ficam óbvios:

• Vinculado à conta certa. O e-mail do commit está na sua conta, o nome do autor aparece como link e o avatar é a foto que você subiu. É o caso que ninguém precisa diagnosticar.
• Vinculado a outra conta sua. O commit foi gravado com um endereço antigo (o da empresa anterior, o da faculdade) que está cadastrado numa segunda conta. O trabalho é seu, aparece com o rosto ou com o desenho da outra conta, e nada está tecnicamente quebrado.
• Não vinculado a conta nenhuma. O endereço não está em conta alguma. O nome do autor aparece como texto puro, sem link para perfil, e ao lado dele fica o estado-base da plataforma.

O GitHub publica um diagnóstico visual para o terceiro caso, dentro da própria interface: na página do commit, "hover over the blue ? to the right of the username". A mensagem que aparece separa as causas: "Unrecognized author (with email address)" quer dizer que o commit tem endereço, mas ele não está em conta nenhuma; "Unrecognized author (no email address)" quer dizer que o commit foi gravado sem endereço; e "Invalid email" quer dizer que o endereço não é válido. Isso é interface, e interface muda: o que descrevo é o que a documentação trazia em 26/08/2026.

A correção publicada tem duas pontas, e é aí que quase todo tutorial para pela metade. A primeira: "change the email address in your local Git configuration", com o aviso literal "if you work on multiple machines, change this setting on each one". A segunda: adicionar aquele endereço à sua conta, ou, se você não quiser o e-mail pessoal exposto no histórico público, adicionar e passar a usar o endereço noreply da conta, que a referência de endereços de e-mail do GitHub descreve assim: "If you created your account after July 18, 2017, your noreply email address is an ID number and your username in the form of [email protected]". Para contas criadas antes de 18 de julho de 2017, a mesma página publica uma condição: a forma sem o número de identificação vale para quem já tinha ativado a privacidade do e-mail antes daquela data. Feito isso, a doc promete exatamente o que promete: "future commits that use the email address will be linked to your account".

A palavra "future" carrega o resto da história. A página de conceitos sobre endereços de e-mail escreve o que não acontece: "any commits you made prior to changing your commit email address are still associated with your previous email address". Não existe botão de reprocessar o histórico. Se você tem dois anos de commits gravados com um endereço solto, eles continuam lá com o rosto de antes, e o conserto vale só para o que vier depois. É o mesmo tipo de decisão de exposição que aparece no currículo, e o critério para escolher está em o que expor e o que omitir nos dados pessoais.

Existe ainda uma trava publicada para quem esquece de trocar a configuração numa máquina. Com a opção de bloquear pushes que exponham o seu e-mail pessoal ativada, a plataforma escreve que confere o commit mais recente do push: "if the author email on that commit is a private email on your GitHub account, we will block the push". Ou seja, em vez de descobrir o vazamento depois, você descobre no momento do envio.

O desenho colorido no seu lugar tem nome, origem e um dono

Quando não há foto, o GitHub não mostra um boneco cinza genérico: mostra um quadrado colorido com um padrão simétrico. Aquilo tem nome, identicon, e tem mecanismo publicado. A página de referência do perfil, na seção sobre a imagem de perfil, escreve: "when you sign up for an account, GitHub provides you with a randomly generated 'identicon'. Your identicon generates from a hash of your user ID, so there's no way to control its color or pattern".

A palavra que importa nessa frase é hash. O anúncio do recurso no blog do GitHub, escrito por Jason Long em 14 de agosto de 2013, descreve o algoritmo: "our Identicons are simple 5x5 'pixel' sprites that are generated using a hash of the user's ID. The algorithm walks through the hash and turns pixels on or off depending on even or odd values. These generated patterns, combined with hash-determined color values, ensures a huge number of unique Identicons". É um post de 2013, e o desenho que a plataforma serve hoje continua batendo com essa descrição.

A consequência prática vem do determinismo. O identicon não é sorteado a cada carregamento: ele é derivado do identificador da sua conta, e por isso é sempre o mesmo. Nos 70 avatares que puxei em 26/08/2026, 11 eram identicons, todos PNG de 420 x 420 px, iguais byte a byte em requisições repetidas e diferentes entre contas. Ele ignora até o parâmetro de tamanho: nas requisições que fiz naquele dia, o CDN de avatares aceitou o pedido de redução na URL e devolveu 16 px, 64 px e 400 px para uma foto, mas para um identicon devolveu 420 x 420 px em qualquer valor pedido.

Isso corta nos dois sentidos. Do lado bom, o identicon é reconhecível: quem revisa código do seu repositório acaba aprendendo o seu quadradinho, o que é mais do que um boneco cinza entrega. Do lado ruim, ele é reconhecível como conta sem foto, e é ele que assina o seu trabalho enquanto durar.

Há ainda um terceiro rosto possível, e é o que costuma explicar a pergunta "de onde saiu essa foto que eu não subi". A mesma página de referência publica: "if you use Gravatar, and your Gravatar image is associated with the email you use for GitHub, the image will be shown as your GitHub profile picture by default (rather than an identicon)". E o tutorial de personalização do perfil fecha o par: "if your email address is associated with a Gravatar, you cannot revert to your identicon. Click Revert to Gravatar instead". Se o e-mail da sua conta já foi usado num Gravatar anos atrás, é aquela imagem que aparece, e o caminho de volta não passa pelo identicon. O teste para descobrir se algum e-mail seu já carrega imagem por esse caminho está em o rosto que o seu e-mail resolve sozinho.

Em que tamanho o seu rosto é realmente visto: 16 px, 24 px, 50 px

Todo mundo aprova a foto de perfil olhando a página de perfil, onde ela é grande e bem desenhada. Não é lá que ela trabalha. Ela trabalha em listas, e em listas ela é minúscula.

O método, para você repetir: em 26/08/2026 abri o HTML servido a um visitante deslogado em três listas de commits públicas (facebook/react, torvalds/linux e rails/rails) e contei as ocorrências de avatar. Foram 128 imagens, e 100% delas desenhadas com 16 px de lado, todas pedidas ao CDN em 32 px, que é a versão de densidade dobrada. Não é amostra: é a totalidade do que aquelas três páginas serviram naquele dia.

No mesmo dia e com o mesmo método, o resto das superfícies. No GitHub: autor de issue ou de pull request em 20 px, avatar de comentário em 24 px, cabeçalho da própria página em 32 px e a página de perfil em 260 px. No Behance: a grade de projetos pede o avatar do autor em 50 px, e a página de perfil usa 138 px, com 230 px na versão de densidade dobrada. No Dribbble: a grade de shots desenha 24 px a partir da variante de 80 px, e a página de perfil usa 48 px.

Traduzido para decisão de imagem, o que sobrevive e o que morre em cada faixa:

• Sobrevive a 16 px: massa da cabeça, silhueta dos ombros, contraste entre cabelo e fundo, cor dominante da roupa. É basicamente uma mancha com formato reconhecível.
• Morre entre 24 px e 50 px: armação fina de óculos, textura de pele, padrão de estampa, sutileza de expressão, cor de olho. Some por reamostragem, não por recorte.
• Morre antes de 24 px: qualquer texto, logotipo, crachá, degradê de fundo e cenário. Se o seu diferencial está num desses, ele nunca chega ao leitor.

A conta ajuda a dimensionar o problema. Um quadrado de 16 px tem 256 pixels de área, contra 1.048.576 de um arquivo de 1.024 x 1.024 px. É 1/4.096 da área que você gerou, ou 0,024%. Essa aritmética de contêiner já tem dono no acervo, em a conta de quanto sobra de uma foto em cada destino; o que este artigo faz é aplicar o resultado a três superfícies novas.

A consequência de projeto é simples e desconfortável: você aprova a foto a 260 px e ela é julgada a 16. O teste é barato. Reduza o arquivo para 16 px de lado em qualquer visualizador, amplie de volta e olhe. Se o que restou for uma mancha ambígua, o problema não é resolução do arquivo: é enquadramento e contraste.

O que cada plataforma faz com o arquivo depois que você sobe

"Suba a maior imagem possível" é conselho comum e, em dois destes três destinos, inútil. As três fazem coisas diferentes com o mesmo upload, e dá para medir qual é qual sem acesso privilegiado a nada.

O GitHub reprocessa e para cedo. A página de referência do perfil publica os requisitos assim: "your profile picture should be a PNG, JPG, or GIF file, and it must be less than 1 MB in size and smaller than 3000 by 3000 pixels. For the best quality rendering, we recommend keeping the image at about 500 by 500 pixels". Já a medição conta outra história: nos 70 perfis que medi em 26/08/2026 (os 70 primeiros usuários devolvidos por duas consultas à API pública de usuários), havia 11 identicons e 59 fotos; entre as 59, o maior lado observado foi 460 px, 45 delas estavam exatamente em 460 x 460 px e nenhuma passou disso. Nos 70 arquivos somados, os formatos servidos eram 40 JPEG e 30 PNG.

Vale escrever com todas as letras o que isso é e o que isso não é. Não estou dizendo que o GitHub limita a 460 px: estou dizendo que nos 70 perfis que medi em 26/08/2026 nenhum arquivo servido passou de 460 px de lado. A leitura prática, essa sim, é estável: a recomendação publicada, cerca de 500 px, já é maior do que tudo que eu encontrei guardado, e subir um arquivo de 3.000 px não coloca 3.000 px em lugar nenhum.

O Behance reprocessa numa lista fechada. O avatar é servido pelo serviço de perfil da Adobe, e nas sondagens que fiz em 26/08/2026 ele só respondeu a um conjunto fixo de tamanhos. Numa página com 150 objetos de usuário, todos vinham com exatamente seis: 50, 100, 115, 138, 230 e 276 px. Pedi outros onze valores (16, 32, 51, 60, 128, 200, 275, 277, 300, 500 e 512) e todos devolveram HTTP 400 com a mensagem "Invalid size.". O maior tamanho que consegui obter foi 276 px. Nessa mesma página, 11 dos 150 usuários vinham marcados com imagem padrão, ou seja, sem foto própria.

O Dribbble faz o oposto: guarda o original. Ainda em 26/08/2026, as variantes nomeadas do CDN devolveram 32 px, 80 px e 160 px, e existe uma variante pública que entrega o arquivo exatamente como foi enviado. Nos 14 originais de autores da página inicial que medi naquele dia, os arquivos iam de 80 x 80 px até 1.924 x 1.924 px, incluindo um GIF animado de 320 px e dois arquivos que nem quadrados eram (500 x 563 px e 492 x 493 px). O que você subir ali fica público como está, e a ajuda avisa por que isso importa: "please choose an image where your face or logo is central as you cannot custom crop the image", como publica o artigo sobre criação e gestão do perfil no Dribbble.

A regra prática que sai das três medições cabe em uma linha: recorte e enquadre antes de subir, sempre; envie um quadrado de tamanho moderado; e não conte com nenhuma das três para consertar composição. É o inverso do que acontece no seu próprio site, onde você controla largura, formato e recorte: aqui o contêiner é de terceiro e não tem alavanca.

Rosto, marca ou ilustração: o critério aqui não é o de uma rede de vagas

A pergunta aparece toda vez, e a resposta genérica ("use o seu rosto, gera confiança") ignora que essas plataformas não fazem o mesmo trabalho que uma rede de vagas.

A diferença é de papel. Num portfólio, a sua foto assina autoria de trabalho: ela aparece grudada em cada commit, em cada comentário de revisão, em cada projeto da grade, e não passa por moderação nem por regra de aceite. Numa plataforma que vende serviço, a mesma foto anuncia um serviço à venda, e ali existe diretriz publicada que aceita ou recusa o arquivo, como mostra a regra de cada plataforma que vende serviço. São dois problemas diferentes com a mesma imagem no meio.

O Dribbble escreve as duas opções na própria ajuda, ao pedir uma imagem em que "your face or logo is central". Não é recomendação nossa: é a plataforma dizendo por escrito que logotipo é escolha válida ali. O Behance, que publica 78 palavras sobre o avatar e nenhum número, não diz nem uma coisa nem outra, embora especifique a capa do projeto com precisão de pixel ("your Cover Image will display at 202x158 px, but you must upload an image that is at least 808x632px"). A plataforma detalha a miniatura do trabalho e deixa o seu rosto sem regra.

Os três casos que cobrem quase todo mundo:

• Você está procurando vaga. Rosto. O portfólio vai ser lido junto com o currículo e com o perfil da rede profissional, e três imagens diferentes obrigam quem lê a refazer o vínculo três vezes. O critério de foto desse conjunto está em o guia de foto para currículo.
• Você opera como estúdio ou marca pessoal. Logotipo é defensável, com um custo declarado: some o reconhecimento do rosto em evento, em call e em comunidade. Se metade do seu trabalho é relação, o custo é alto.
• Você contribui em projeto aberto com pseudônimo. Ilustração é uma decisão declarada, não um descuido. Vale saber que o identicon já faz esse trabalho de graça e é único, ainda que anuncie que você não subiu nada.

O que não muda em nenhum dos três: a peça é quadrada, o elemento central e o contraste com o fundo mandam. A régua de 16 px vale igual para rosto, para logotipo e para ilustração, e um logotipo com texto pequeno morre exatamente na mesma faixa em que morre um crachá.

As três linhas que você acrescenta ao prompt para este destino

Se a foto vem de um gerador, o pedido muda pouco em relação à base de sempre, que está reunida na biblioteca de prompts do blog. O que muda para portfólio são três exigências, e as três saem de números medidos, não de gosto. Este é o bloco pronto:

Square 1:1 professional portrait, head and shoulders only,
head occupying about 60% of the frame height,
face centered horizontally and vertically so nothing is lost to a circular crop,
plain high-contrast background clearly separated from hair and shoulders,
even frontal lighting, no strong shadow across the face,
no text, no logo, no props, no busy scenery,
sharp eyes, neutral confident expression, natural skin texture,
readable as a silhouette when reduced to 16 pixels.

Em português, resumido: retrato quadrado, do peito para cima, com a cabeça ocupando cerca de 60% da altura e centralizada nos dois eixos para sobreviver ao recorte circular; fundo liso e bem separado do cabelo e dos ombros; luz frontal uniforme, sem sombra dura atravessando o rosto; nada de texto, logotipo, objeto ou cenário; olhos nítidos, expressão neutra e confiante, textura de pele preservada; e o critério final, continuar legível como silhueta quando reduzido a 16 pixels.

Por que cada linha está ali, cada uma amarrada a um número medido:

• Square 1:1 porque as três plataformas trabalham em quadrado: o Behance só serve tamanhos quadrados, o GitHub reprocessa para quadrado e o Dribbble guarda o que vier, o que faz um retângulo enviado ali virar um retângulo público cortado na exibição.
• head occupying about 60% of the frame height porque a régua é a superfície pequena. Um retrato de meio corpo, que é a média que o modelo entrega quando ninguém pede nada, deixa a cabeça com poucos pixels a 16 px de lado.
• face centered horizontally and vertically porque o recorte circular come os cantos, e no Dribbble não existe ajuste depois do envio. Centralizar é o seguro contra os três recortes ao mesmo tempo.
• plain high-contrast background porque, a 16 px, contraste é praticamente a única informação que sobra. É a linha que evita a cabeça fundida no fundo.
• no text, no logo, no props porque esses elementos morrem antes dos 24 px e, no caminho, viram ruído. Texto inventado por modelo de imagem é o pior dos dois mundos: ilegível e errado.
• readable as a silhouette when reduced to 16 pixels porque isso é o critério de aprovação escrito dentro do próprio pedido, não um efeito. Serve de lembrete para você na hora de escolher entre as saídas.

E uma linha que não está ali de propósito: qualquer descrição da sua aparência. Quando existe foto de referência anexada, descrever a pessoa compete com a imagem e é uma das causas conhecidas de troca de rosto. O que funciona é declarar a foto como única fonte de identidade e proibir embelezamento. Limite honesto: isso reduz a deriva de identidade, não elimina.

Limites honestos: o que é regra publicada e o que eu medi

Este artigo mistura dois tipos de informação de propósito, porque só um deles existe. A separação, para você saber o peso de cada número:

• Regra publicada. As linhas de formato, peso e dimensão do GitHub e do Dribbble, o mecanismo do e-mail do commit, o mecanismo do identicon, a precedência do Gravatar e o formato do endereço noreply. Tudo isso está em página oficial linkada aqui, consultada em 26/08/2026.
• Medição própria. Todas as linhas de tamanho: o teto de 460 px, a lista de seis tamanhos da Adobe, o identicon de 420 px, os 16, 20, 24, 32, 48, 50, 138 e 260 px de exibição. Valem para 26/08/2026 e para as páginas que abri naquele dia.
• O que o parâmetro de tamanho na URL significa. Ele é o tamanho pedido ao CDN, não o tamanho do arquivo guardado do outro lado. Por isso as duas coisas aparecem separadas no texto.

Três ressalvas que mudam como você deve ler o restante. A primeira: a página de ajuda do Behance sobre o avatar responde 403 a leitura automatizada do HTML; o corpo dela foi lido pela API pública da própria central de ajuda, que devolve o mesmo texto, e o link que publiquei aqui é o da página humana. A segunda: dizer que o Behance não publica spec do avatar é uma ausência conferida naquele artigo, naquele dia, e não uma declaração da plataforma de que aceita qualquer coisa. A terceira: interface muda. O "?" azul do diagnóstico de commit, os nomes dos botões e a árvore de menus podem estar diferentes quando você ler isto, e a data de consulta está aqui exatamente para esse caso.

Também vale dizer o que eu não testei. Não subi arquivos em contas de terceiros para ver o que cada plataforma faz com um upload de 3.000 px: o que medi foi o que as contas servem publicamente hoje. E não meço nem estimo efeito de foto de perfil sobre contratação, convite ou visibilidade em nenhum desses destinos, porque não existe dado público que sustente esse tipo de afirmação.

Resumo e próximos passos

Se você fechar esta página agora, leve cinco coisas:

• O perfil e o histórico têm chaves diferentes. O upload manda no perfil; o e-mail do cabeçalho do commit manda no rosto que aparece ao lado do seu código.
• A correção tem duas pontas e é multi-máquina. Trocar a configuração local do Git e adicionar o endereço à conta, em cada máquina onde você commita. E ela só alcança os commits futuros.
• O identicon não é placeholder neutro. É um desenho derivado do identificador da sua conta, estável e reconhecível, e um Gravatar antigo no e-mail da conta passa na frente dele.
• A régua de enquadramento é 16 px. Foi o que medi na lista de commits, contra 24 px na grade de shots, 50 px na grade de projetos e 260 px na página de perfil.
• Recorte antes de subir. O GitHub reprocessa, o Behance serve seis tamanhos fixos e o Dribbble guarda o seu arquivo como ele veio, sem oferecer recorte.

O próximo passo depende de onde essa foto vai aparecer depois. Se o portfólio faz parte de uma candidatura, o conjunto (currículo, perfil, portfólio) precisa mostrar a mesma pessoa, e o critério de escolha da imagem está em o pilar sobre foto para currículo. Se você ainda vai gerar a imagem, comece pelo bloco de prompt desta página e teste reduzindo o resultado a 16 px antes de aprovar qualquer coisa.