Seu primeiro projeto no GitHub, do zero ao link

1. Por que um projeto terminado vale mais

Tutoriais mostram o caminho já aberto. Um projeto seu obriga a tomar decisões, travar, pesquisar e resolver, que é o que o trabalho real pede. E um projeto pequeno, terminado e bem explicado mostra mais do que dez repositórios pela metade.

Para quem está procurando a primeira vaga, um projeto publicado dá assunto na entrevista: você pode contar o que construiu, o que deu errado e o que aprendeu.

2. Escolher o projeto

O melhor primeiro projeto resolve um problema seu ou de alguém perto de você. Problema real dá motivação para terminar e uma história para contar. Algumas ideias por área:

Evite clones de projetos famosos que todo mundo faz igual seguindo o mesmo vídeo. Eles mostram que você sabe seguir um tutorial, não que sabe resolver um problema.

3. Cortar até caber: a primeira versão

Todo projeto começa grande na cabeça. Corte até sobrar o menor pedaço que já é útil e que você termina em uma ou duas semanas. Isso costuma ser chamado de MVP (produto mínimo viável).

Escreva três listas antes de começar:

• Precisa ter: o mínimo para funcionar. Por exemplo: "digito o valor e o número de pessoas e vejo quanto cada uma paga".
• Seria bom ter: fica para a versão 2. "Escolher a porcentagem da gorjeta."
• Fica de fora: não entra agora. "Login, salvar histórico, aplicativo de celular."

Coloque as listas como issues no seu repositório. Fechar cada uma dá a sensação de progresso e mostra como você organiza o trabalho.

4. Organizar o repositório

• Nome claro e em minúsculas, com hífens: divide-conta, não projeto1 nem teste-final-agora-vai.
• Descrição de uma linha no campo About do GitHub.
• .gitignore desde o primeiro commit, para não subir arquivos de sistema, dependências baixadas nem segredos. O GitHub oferece modelos prontos por linguagem ao criar o repositório.
• Licença: sem licença, ninguém tem permissão legal para reutilizar seu código. Para projetos de estudo, a MIT é uma escolha comum e simples. O GitHub oferece a opção ao criar o repositório.
• Pastas simples: código numa pasta, testes em outra, imagens do README numa terceira. Não precisa de mais que isso.

5. Trabalhar em pequenos passos

Faça um commit cada vez que uma parte pequena funcionar. Commits pequenos facilitam voltar atrás quando algo quebra e contam a história do projeto.

feat: calcula o valor por pessoa
feat: adiciona campo de gorjeta
fix: arredonda centavos para cima
docs: explica como rodar no README

Experimente trabalhar com branches (linhas paralelas de trabalho no mesmo repositório) e pull requests mesmo sozinho: crie uma branch para cada funcionalidade e junte na main por um PR. É o fluxo que você vai usar em qualquer time, e a lição Primeiros passos no GitHub mostra como.

6. Escrever um README que se explica

O README é a primeira coisa que alguém vê no seu repositório. Muita gente decide em segundos se vai continuar lendo. Um bom README responde, nesta ordem:

# Divide Conta

Calcula quanto cada pessoa paga numa conta de restaurante, com gorjeta.

![Tela do Divide Conta](imagens/tela.png)

**Acesse:** https://seu-usuario.github.io/divide-conta/

## Como rodar no seu computador
1. Clone o repositório: `git clone https://github.com/seu-usuario/divide-conta.git`
2. Abra o arquivo `index.html` no navegador.

## O que eu usei
HTML, CSS e JavaScript, sem bibliotecas.

## O que eu aprendi
- Como tratar números com centavos sem erro de arredondamento.
- Como publicar um site estático no GitHub Pages.

## Próximos passos
- [ ] Salvar as últimas contas no navegador
- [ ] Dividir por item consumido

A seção O que eu aprendi é a mais valiosa para quem está começando: mostra como você pensa. Uma imagem ou um GIF curto do projeto funcionando também ajuda muito.

7. Publicar para qualquer pessoa ver

Um link que abre e funciona vale mais do que um "clone e rode". Opções gratuitas para começar:

• GitHub Pages: para sites estáticos (HTML, CSS e JavaScript). No repositório, vá em Settings, Pages, escolha a branch main e salve. Na conta gratuita, o repositório precisa ser público. Em alguns minutos o site fica em https://seu-usuario.github.io/nome-do-repositorio/.
• Cloudflare Pages, Netlify ou Vercel: também publicam sites a partir do GitHub, de graça para projetos pequenos, e atualizam sozinhos a cada push.
• Scripts e análises de dados: não precisam de site. Um README com exemplos de uso e da saída, ou um notebook publicado (um documento que junta código, resultados e texto, como os do Jupyter), resolve.

Planos gratuitos mudam com o tempo. Confira as condições atuais do serviço antes de publicar.

8. Pedir para alguém testar

Mande o link para duas ou três pessoas, de preferência uma que não seja de TI. Peça para usarem sem a sua ajuda e observe, ou pergunte depois:

• Você entendeu para que serve só pelo README ou pela tela?
• Onde você travou?
• O que você esperava que acontecesse e não aconteceu?

Transforme cada resposta numa issue. Corrigir o que outra pessoa encontrou é o ciclo de trabalho de um time de produto.

9. Montar seu perfil

• Foto, nome e uma bio curta dizendo o que você está estudando e para qual área quer ir.
• README do perfil: crie um repositório com o mesmo nome do seu usuário. O README dele aparece no topo do seu perfil. Três ou quatro linhas sobre você e seus projetos bastam.
• Fixe de dois a seis projetos (opção Customize your pins). Escolha os mais completos e com melhor README.
• Constância vale mais que volume. Um projeto pequeno que você melhora aos poucos conta uma história melhor do que dezenas de repositórios vazios.

10. E a IA no projeto?

Usar IA no projeto é normal e é uma habilidade que o mercado valoriza. O que conta é você entender e conseguir explicar cada parte do que está no repositório.

• Use a IA para tirar dúvidas, revisar seu código e sugerir testes.
• Não publique como seu um projeto inteiro gerado que você não sabe explicar. Na primeira pergunta da entrevista, isso aparece.
• Se usou IA de forma relevante, conte no README. Explicar como você usou mostra maturidade.

11. Missão final