Aula 03 - Publicando na Web - GitHub e Deploy

Onde o site vive

Antes de publicar, preciso entender onde um site fica guardado. Todo site vive num servidor: um computador que fica ligado o tempo todo e entrega os arquivos para quem pedir. Mas o tipo de servidor muda conforme o tipo de projeto.

É como escolher o ponto da loja: um vendedor de pipoca na rua precisa de um carrinho. Uma loja de roupas precisa de uma sala. Um restaurante precisa de cozinha, mesa e estoque. Cada projeto cabe num lugar diferente.

Hospedagem para cada tipo de projeto

As formas de subir o projeto

“Subir o projeto” significa levar os arquivos que estão no meu computador (ou no Replit) até o servidor que vai publicar. Existem quatro formas principais:

A melhor forma: o Git com repositório conectado

De todas as formas, a mais vantajosa é conectar o projeto a um repositório Git (GitHub, GitLab e outros). O motivo:

É como ter o molho da receita guardado num cofre: mesmo que o restaurante feche, eu tenho a receita e abro em outro lugar. O Git é o cofre, o repositório é onde o cofre fica, e as plataformas de hospedagem são os restaurantes que usam a receita.

Onde o site mora

Antes de publicar, preciso entender onde um site fica guardado. Todo site mora num servidor: um computador que fica ligado o tempo todo e entrega os arquivos para quem pedir. Mas o tipo de servidor muda conforme o tipo de projeto.

É como escolher o ponto da loja: um vendedor de pipoca na rua precisa de um carrinho. Uma loja de roupas precisa de uma sala. Um restaurante precisa de cozinha, mesa e estoque. Cada projeto cabe num lugar diferente.

Hospedagem para cada tipo de projeto

No curso, eu crio sites estáticos - a parte visual. É por isso que a hospedagem pode ser gratuita: não tem servidor processando nada por trás.

As formas de subir o projeto

“Subir o projeto” significa levar os arquivos que estão no meu computador (ou no Replit) até o servidor que vai publicar. Existem quatro formas principais:

A melhor forma: o Git com repositório conectado

De todas as formas, a mais vantajosa é conectar o projeto a um repositório Git (GitHub, GitLab e outros). O motivo:

É como ter o molho da receita guardado num cofre: mesmo que o restaurante feche, eu tenho a receita e abro em outro lugar. O Git é o cofre, o repositório é onde o cofre fica, e as plataformas de hospedagem são os restaurantes que usam a receita.

Git - o cofre de versões

Git é um software de versionamento: guarda o histórico de todas as mudanças de um projeto. Se eu errar algo, volto para a versão anterior - é uma máquina do tempo para o código.

É como o histórico de um documento no Google Docs: toda vez que eu salvo, o Google fica com uma versão. Se eu errar, volto. O Git faz a mesma coisa, mas com código.

A analogia do fichário

Como funciona na prática

1. Eu crio um arquivo e salvo no computador
2. Eu faço um commit - o Git guarda essa versão com nome e data
3. Eu mudo o arquivo e salvo de novo
4. Eu faço outro commit - o Git guarda a versão nova
5. Se eu errar, volto para qualquer versão anterior

Por que isso importa para o meu site

Imagine um cartão de visitas digital funcionando. Eu mudo uma cor e o site inteiro quebra. Sem Git, perdi a versão que funcionava. Com Git, volto para ela num clique.

GitHub - o cofre na nuvem

GitHub é uma plataforma online onde eu guardo meus projetos. É como o Google Drive, mas feito para código. Ele usa o Git por trás, então o histórico inteiro fica salvo.

É a diferença entre salvar um documento no pendrive (pode perder) e salvar no Google Drive (acesso de qualquer lugar). O GitHub é o “Google Drive do código”.

O GitHub é como um cofre: mesmo que o computador queime, o telefone seja roubado ou eu apague tudo por engano, o projeto está salvo. É o backup permanente.

O que é um repositório

Um repositório é uma pasta no GitHub onde todos os arquivos de um projeto ficam organizados. Cada projeto tem o seu. A estrutura de um site estático típico é assim:

cartao-de-visitas-digital/
├── index.html      - Pagina principal
├── style.css       - Visual (cores, fontes, layout)
├── script.js       - Funcionalidades (botoes, animacoes)
├── imagens/        - Fotos e icones
│   ├── foto-perfil.jpg
│   └── logo.png
└── README.md       - Descricao do projeto

O index.html é o arquivo principal - é ele que o navegador abre quando alguém acessa o site. O nome “index” não é aleatório: é o padrão que os servidores esperam.

Criando uma conta

1. Acesse github.com e clique em Sign up
2. Digite seu e-mail (pode ser o mesmo do Google)
3. Crie uma senha forte (mínimo 8 caracteres)
4. Escolha o nome de usuário - vira o endereço do seu perfil (ex: github.com/seu-nome)
5. Confirme o e-mail pelo link da caixa de entrada

Criando um repositório

No fluxo do curso, o repositório é criado sozinho quando eu faço o push pelo Replit (o Replit cria o repositório e envia os arquivos). Mas dá pra criar na mão também, se eu quiser começar do zero:

1. Clique no ícone + e escolha New repository
2. Digite um nome (ex: cartao-de-visitas-digital)
3. Escolha público (qualquer pessoa vê) ou privado (só você)
4. Marque Add a README file - cria um arquivo inicial
5. Clique em Create repository

É como criar uma pasta nova no Google Drive: eu dou um nome, escolho se é público ou privado, e o conteúdo vai para dentro.

Estático ou dinâmico

Site estático não quer dizer parado ou sem graça. Quer dizer que o código-fonte não muda: o servidor entrega o mesmo arquivo para todo mundo. Isso não impede interatividade - formulários que validam na hora, botões que mudam de cor, galerias e animações rodam no navegador do visitante, com JavaScript, sem precisar de servidor.

Site dinâmico tem um servidor processando coisas: senhas, pagamentos, formulários que enviam e-mail, banco de dados. É como um restaurante com cozinha: o pedido chega, alguém prepara, e o resultado volta ao cliente.

GitHub Pages - a hospedagem grátis do GitHub

GitHub Pages é um serviço gratuito do GitHub que hospeda sites estáticos com endereço próprio, no formato seu-usuario.github.io/nome-do-projeto.

É como ter uma vitrine grátis: eu coloco os produtos na prateleira e qualquer pessoa vê, sem pagar nada.

Passo a passo:

1. Pedir pra IA criar a integração - no chat da IA do Replit, peça: “Crie a integração com GitHub Pages no meu projeto”. A IA cria o arquivo de instruções (o workflow) que publica o site
2. Enviar o código pelo Replit - em Tools (menu inferior) → + → Git → Initialize repository
3. Conectar ao GitHub - clique em Connect to GitHub, faça login e autorize a conexão
4. Commit e Push - escreva a mensagem (ex: “Primeira versão do site”) e clique em Commit e depois em Push. O Replit cria o repositório no GitHub e envia os arquivos
5. Ativar o Pages - no GitHub, em Settings → Pages, escolha Source: GitHub Actions
6. Acessar - aguarde alguns minutos (o workflow criado pela IA roda sozinho), volte em Settings → Pages e clique no link que aparece no topo

Como atualizar: faça a mudança no Replit (com IA) e faça commit + push. O GitHub Pages publica a versão nova sozinho, em alguns minutos.

É como editar uma planilha no Google Sheets: quando eu salvo, todo mundo vê a versão nova automaticamente.

Vercel - deploy mais fácil

A Vercel é uma plataforma de deploy usada por empresas grandes e projetos pessoais. O diferencial é a CDN: o site é distribuído em servidores pelo mundo inteiro, então carrega rápido em qualquer lugar.

É como uma rede de lojas: em vez de uma loja só, a Vercel tem “filiais” em todos os países. Quando alguém acessa, o site vem da filial mais perto - e carrega mais rápido.

O jeito mais simples: conectar o repositório

O jeito mais simples de publicar na Vercel é conectar o repositório do GitHub. A Vercel lê o código do repositório e publica. E a partir daí, toda vez que eu faço push, o site atualiza sozinho.

Passo a passo:

1. Tenha o site no GitHub - mesmo fluxo do GitHub Pages: peça pra IA criar a integração, faça commit e push pelo Replit
2. Acesse vercel.com e faça login com Google ou GitHub
3. Clique em Add New… → Project
4. Escolha Import Git Repository
5. Escolha o repositório do site na lista
6. Clique em Deploy - a Vercel detecta sozinha que é um site pronto pra publicar
7. Em alguns segundos o site ganha um endereço assim: seu-projeto.vercel.app

Como atualizar: faça a mudança no Replit (com IA) e faça commit + push. A Vercel detecta o push e publica a versão nova sozinha, sem tocar em nada.

Vantagens:

Cloudflare Pages - alternativa sem restrição

Cloudflare Pages é a hospedagem gratuita de um dos maiores serviços de internet do mundo. Ela é rápida, gratuita e não tem restrição de uso comercial.

É como a Vercel, mas sem as restrições do plano gratuito. Pode usar para vender, divulgar, qualquer coisa.

Passo a passo:

1. Tenha o site no GitHub - mesmo fluxo do GitHub Pages: peça pra IA criar a integração, faça commit e push pelo Replit
2. Acesse dash.cloudflare.com, clique em Sign up e confirme o e-mail
3. No painel, vá em Workers & Pages → Create → Pages
4. Clique em Connect to Git
5. Autorize o Cloudflare a acessar seu GitHub (se pedir)
6. Escolha o repositório do site
7. Clique em Save and Deploy
8. Em poucos minutos o site ganha um endereço assim: cartao-de-visitas-digital.pages.dev

Como atualizar: faça a mudança no Replit (com IA) e faça commit + push. O Cloudflare detecta o push e publica a versão nova sozinho.

Por que ela é diferente da Vercel no plano gratuito:

Se você quer vender algo pelo site (um produto, um serviço, um curso), o Cloudflare Pages é a melhor opção gratuita.

As 4 formas de publicar

Quando usar cada um

Dica: o ideal é usar mais de um. O GitHub guarda o código (backup). O Vercel ou Cloudflare publica o site (deploy). Assim, mesmo que uma plataforma caia, o código está salvo no GitHub.

Mini atividade - publicar um projeto já pronto

Quem já tem um site pronto (feito no Replit, no OpenCode ou em outro lugar) pode publicá-lo agora, no ar, em três passos: exportar para o GitHub, conectar o repositório e ver o site no ar.

É como levar a comida pronta para o restaurante: o prato já está feito. Eu só preciso guardar a receita no cofre (GitHub) e colocar o prato na vitrine (Vercel ou Cloudflare).

Passo 1 - Exportar o projeto do Replit para o GitHub

1. Abra o projeto no Replit
2. Vá em Tools (menu inferior) → clique no + → escolha Git
3. Clique em Initialize repository (cria o Git dentro do projeto)
4. Clique em Connect to GitHub, faça login e autorize a conexão
5. Escreva uma mensagem de commit (ex: “Primeira versão do site”)
6. Clique em Commit e depois em Push - o Replit cria o repositório no GitHub e envia os arquivos
7. Abra o link do GitHub que aparece para confirmar que o projeto está lá

Agora o código tem um backup permanente. Mesmo que o Replit expire, os arquivos continuam no GitHub.

Passo 2 - Publicar na Vercel conectando o repositório

1. Acesse vercel.com e faça login com o GitHub
2. Clique em Add New… → Project
3. Clique em Import Git Repository (ou Continue with GitHub)
4. Escolha o repositório recém-publicado
5. Clique em Deploy
6. Em alguns minutos o site fica no ar: seu-projeto.vercel.app

A Vercel já entende que é um site estático. Não precisa configurar nada - é só clicar em Deploy.

Passo 3 - Publicar no Cloudflare Pages conectando o repositório

1. Acesse dash.cloudflare.com e faça login
2. Vá em Workers & Pages → Create → Pages
3. Escolha Connect to Git
4. Autorize o Cloudflare a acessar seu GitHub (se pedir)
5. Escolha o mesmo repositório
6. Clique em Save and Deploy
7. Em poucos minutos o site fica no ar: seu-projeto.pages.dev

Agora o mesmo código está publicado em dois lugares. Se um cair, o outro continua no ar.

Como atualizar daqui para frente

1. Volte ao Replit e faça as alterações no código
2. No painel Git, escreva a mensagem do commit e clique em Commit
3. Clique em Push
4. A Vercel e o Cloudflare detectam o envio e atualizam os sites sozinhos, em minutos

É aqui que a integração com o Git brilha: publico uma vez e, depois, cada envio atualiza tudo sozinho. Nada de baixar, arrastar e reenviar a cada mudança.

Performance e UX

Um site demorado faz o visitante ir embora - e não é opinião, é dado:

• 53% das pessoas abandonam um site que demora mais de 3 segundos para carregar (pesquisa do Google)
• O Google penaliza sites lentos nos resultados de busca

É como entrar numa loja: se a porta trava, se o corredor é longo demais, se o caixa demora - eu vou embora para a loja do lado.

O que afeta a velocidade

PageSpeed Insights - como testar

O PageSpeed Insights é uma ferramenta gratuita do Google que dá notas de 0 a 100 para o site.

É como um exame médico para o seu site: ele verifica tudo e diz o que está bom e o que precisa melhorar.

1. Acesse pagespeed.web.dev
2. Digite o endereço do site
3. Clique em Analyze e aguarde 10-30 segundos
4. Veja as notas e as sugestões

Métricas principais:

Dicas rápidas para melhorar performance

Fluxo completo do encontro

1. Criar o site no Replit - projeto HTML/CSS/JS e colar o prompt do cartão de visitas
2. Pedir pra IA criar a integração com GitHub Pages - “Crie a integração com GitHub Pages no meu projeto”
3. Criar conta no GitHub (se não tiver) - github.com → Sign up
4. Enviar o código pelo Replit - Tools → Git → Initialize repository → Connect to GitHub → Commit → Push
5. Ativar GitHub Pages - Settings → Pages → Source: GitHub Actions
6. Publicar na Vercel (opcional, mas recomendado) - Add New… → Project → Import Git Repository → Deploy
7. Publicar no Cloudflare Pages (opcional) - Workers & Pages → Create → Pages → Connect to Git → Save and Deploy
8. Testar performance - pagespeed.web.dev → Analyze
9. Melhorar se necessário - se a nota for abaixo de 70, compresse imagens e peça: “Otimize o site pra performance”

Se a nota ficar acima de 90, seu site está mais rápido que 90% dos sites da internet. Isso é excelente.

Prompts pra auxiliar

"Crie um cartão de visitas digital para [SEU NOME], [SEU CARGO].

Hierarquia:
1. Titulo: '[SEU NOME]' - maior elemento, fonte bold, cor [COR]
2. Subtitulo: '[DESCRICAO CURTA]' - menor que o titulo
3. Foto: perfil centralizado, borda arredondada
4. Contato: WhatsApp, E-mail, Instagram - icones e links
5. Botao: 'Fale comigo' - link para WhatsApp
6. Rodape: (c) 2026 [SEU NOME]

Estilo: [ESTILO]
Cores: [CORES]
Responsivo: mobile first
Performance: imagens otimizadas, codigo minimo"

"Otimize este site pra performance:
- Comprima todas as imagens
- Minimize o CSS (remova espacos e comentarios)
- Remova scripts desnecessarios
- O site deve carregar em menos de 2 segundos
- Mantenha o design atual - so otimize o peso"

"Torne este site 100% responsivo:
- No celular: tudo em coluna, botoes grandes (minimo 44px de altura)
- No tablet: layout adaptado
- No desktop: layout centralizado com largura maxima
- Imagens que se adaptam ao tamanho da tela"

"Ajuste o link do WhatsApp para usar o formato correto:
https://wa.me/55NUMERO (sem tracos, sem parenteses, com o codigo do pais 55)"

Problemas comuns

Regra de ouro: se algo não funciona, primeiro veja se todos os arquivos foram enviados. 90% dos problemas são arquivos faltando ou caminhos errados. Depois verifique se todas as configurações estão corretas.

Checklist de publicação

Links de apoio