Do Git ao domínio próprio, publicando um site estático com GitHub Pages e Cloudflare

Publicar uma página HTML é fácil. Manter essa página com um grupo, saber quem alterou cada linha, revisar uma contribuição antes de colocá-la no ar, ligar um domínio próprio ao projeto e proteger a entrega exigem peças que normalmente são ensinadas separadas. O resultado é conhecido: o estudante termina um tutorial com uma página funcionando, mas não consegue reconstruir o caminho quando precisar trabalhar em uma equipe real.

Neste artigo vamos fazer o percurso inteiro. Partiremos de uma pasta vazia, construiremos um histórico com Git, organizaremos a colaboração no GitHub, publicaremos a primeira página no GitHub Pages, registraremos um domínio .br e, por fim, colocaremos o Cloudflare entre a visitante e o GitHub Pages. O site continuará sendo estático, isto é, seus arquivos prontos serão enviados sem um servidor de aplicação nem um banco de dados.

Este artigo analisa quatro fronteiras técnicas diferentes. Separá-las evita uma confusão especialmente perigosa entre registro de domínio, DNS, hospedagem e proxy:

1. O Git registrará a história do projeto, enquanto o GitHub organizará a colaboração.
2. O GitHub Pages transformará os arquivos do repositório em um site público.
3. O Registro.br manterá a titularidade do domínio, e o DNS relacionará nomes aos serviços.
4. O Cloudflare passará a responder pelo DNS e a intermediar o tráfego, enquanto o GitHub Pages continuará sendo a origem dos arquivos.

No exemplo que vamos construir, a atenta leitora deve ter o cuidado de substituir equipe-exemplo, administrador e projetoexemplo.com.br pelos nomes reais dos seus próprios, repositórios, usuários e domínios. Não copie os valores ilustrativos para uma configuração de produção sem fazer essa substituição. Na verdade, não copie nada. Crie seus próprios testes e arquivos. Use a única coisa que a inteligência artificial ainda não tem: imaginação. Ainda é a palavra mágica, ela determina um limite de tempo.

1. Parte I: Git e GitHub como controle de versão em grupo

Antes de publicarmos qualquer coisa, precisamos decidir qual mudança merece virar a versão oficial. Essa pergunta distingue o Git do GitHub. O Git é o sistema de controle de versão executado localmente: ele registra estados do projeto, compara alterações e permite criar linhas paralelas de trabalho. O GitHub hospeda repositórios Git e acrescenta identidades, permissões, discussões, revisões e pull requests.

1.1 Repositório, commit e três áreas de trabalho

Um repositório é uma pasta cujo histórico o Git acompanha. Dentro dele, um arquivo passa por três estados relevantes. Primeiro, ele é modificado na área de trabalho. Depois, o comando git add coloca este arquivo na área de preparação, chamada staging area. Finalmente, git commit grava uma fotografia lógica das mudanças preparadas no histórico local.

Esses quatro passos são importantes. Eles permitem editar três arquivos e incluir apenas dois em um commit. Ou um, ou os três. Você decide de acordo com o seu ritmo de trabalho. O commit não significa enviar ao GitHub. Um commit fará com que o arquivo seja incluído no repositório local. O git push é a operação que enviará os arquivos já committed para um repositório remoto.

Para trabalhar em grupo, depois de instalar o Git, cada participante deve configurar a identidade que será registrada nos commits criados em sua máquina:

git config --global user.name "Nome Sobrenome"
git config --global user.email "[email protected]"
git config --global init.defaultBranch main

O user.name e o user.email identificam o autor de cada commit, mas não são credenciais de autenticação. O GitHub poderá associar os commits à conta do participante quando o endereço configurado for um e-mail verificado nessa conta ou o endereço privado noreply fornecido pela plataforma. A opção init.defaultBranch apenas determina que novos repositórios sejam iniciados com um branch chamado main.

O histórico do Git registra os commits realizados, e não todas as operações executadas sobre os arquivos. Alterações feitas no diretório de trabalho ou adicionadas à área de preparação somente passam a integrar o histórico depois da execução de git commit.

Como o repositório remoto utiliza HTTPS, já que vamos usar o Github, não será necessário criar uma chave SSH. A autenticação ocorrerá quando o participante executar uma operação que exija acesso à conta ou permissão de escrita no repositório, como:

git push origin main

Em uma instalação que utilize o Git Credential Manager, a primeira operação autenticada normalmente abrirá o navegador para que o participante entre em sua conta do GitHub e autorize o acesso. No Windows 11, ao instalar o Git for Windows pelo instalador oficial e manter as opções padrão, o Git Credential Manager (GCM) será instalado e selecionado como gerenciador de credenciais. Neste caso, o gerenciador receberá e armazenará uma credencial de acesso de maneira segura no sistema operacional. Nas operações seguintes, essa credencial será reutilizada automaticamente enquanto permanecer válida.

Preste atenção: a senha comum da conta do GitHub não é aceita para operações Git realizadas por HTTPS.

Se o Git Credential Manager não estiver disponível, pode-se utilizar um Personal Access Token, fornecendo-o no campo solicitado como senha. Esse token deve ser tratado como uma credencial secreta e nunca deve ser incluído diretamente na URL do repositório ou salvo em arquivos do projeto.

Um Personal Access Token (PAT, token de acesso pessoal) é uma credencial gerada no GitHub para autorizar operações realizadas por HTTPS. Quando o terminal solicitar uma senha durante um git push, o token será fornecido no lugar da senha comum da conta.

O GitHub recomenda a criação de um token do tipo fine-grained, pois ele pode ser limitado a repositórios e permissões específicos. Para criá-lo:

1. Entre em sua conta no GitHub e clique na imagem do perfil.
2. Acesse Settings e, no menu lateral, selecione Developer settings.
3. Abra Personal access tokens, escolha Fine-grained tokens e clique em Generate new token.
4. Informe um nome que identifique a finalidade do token e defina uma data de expiração.
5. Em Resource owner, selecione a conta proprietária do repositório.
6. Em Repository access, escolha Only select repositories e selecione apenas os repositórios necessários.
7. Em Repository permissions, localize Contents e escolha Read and write para permitir operações como clone, pull e push.
8. Clique em Generate token, copie o valor apresentado e guarde-o em um gerenciador seguro de credenciais.

Quando o Git solicitar as credenciais para uma operação HTTPS, informe o nome de usuário da conta e cole o PAT no campo reservado à senha:

Username for 'https://github.com': nome-do-usuario
Password for 'https://[email protected]': ffbdColeOSeuPATAqui45d5@dc

Os caracteres do token podem não aparecer enquanto ele é colado no terminal. Isso é um comportamento normal de campos destinados a credenciais.

O token deve possuir somente as permissões necessárias e não pode ser incluído em comandos, URLs, commits ou arquivos do projeto. Se ele for exposto, perder a validade ou deixar de ser necessário, deverá ser revogado em Settings → Developer settings → Personal access tokens.

Se você estiver trabalhando em organização no Github, as políticas de segurança da organização podem exigir a aprovação de um administrador antes de permitir que o token acesse seus repositórios. Enquanto essa aprovação estiver pendente, o token não terá a permissão solicitada.

1.2 O primeiro repositório

Para o nosso exemplo o proprietário da conta cria no GitHub um repositório público chamado exatamente administrador.github.io. Só para esclarecer, estou usando administrador como sinônimo de nome de usuário do proprietário da conta. Esse nome não é decoração: um repositório de usuário, com nome de usuário usuario e com o formato <usuario>.github.io será publicado no endereço https://<usuario>.github.io/. Durante a criação, podemos incluir um arquivo README.md, mas deixaremos o restante vazio.

Em seguida, o administrador clona o repositório e acessa a pasta:

git clone https://github.com/administrador/administrador.github.io.git
cd administrador.github.io
git status

Quando executamos git clone URL_DO_REPOSITORIO, o Git faz mais do que copiar os arquivos visíveis no GitHub. Ele cria um diretório local, inicializa dentro dele um repositório Git, transfere o histórico de commits e as referências disponíveis no repositório remoto e prepara os arquivos da ramificação principal para o trabalho. A partir desse momento, temos um repositório local completo, no qual podemos consultar o histórico, criar ramificações e registrar commits mesmo sem uma conexão permanente com a internet.

Durante a clonagem, o Git também registra o endereço do repositório original como um repositório remoto chamado, por convenção, origin. Esse nome é apenas um apelido armazenado na configuração local. Ele não representa uma ramificação (branch) nem uma cópia adicional do projeto. Por isso, comandos como git fetch origin e git push origin main significam, respectivamente, buscar informações no endereço associado a origin e enviar a ramificação local main para esse mesmo endereço. Podemos conferir essa associação a qualquer momento com git remote -v. A atenta leitora também deve observar que se a cópia adicional estiver no GitHub, pertencer a outra conta e mantiver vínculo com o repositório original, ela será um fork.

Depois da clonagem, git status passa a funcionar como o nosso painel de instrumentos.

O comando git status informa em qual ramificação estamos, quais arquivos foram modificados, quais alterações já estão na área de preparação e quais arquivos ainda não são supervisionados pelo Git. Quando existe uma ramificação remota associada, ele também informa se a ramificação local está adiantada ou atrasada em relação à última referência remota conhecida.

Essa comparação não consulta o GitHub em tempo real. Ela utiliza as informações obtidas na clonagem ou no último git fetch. Portanto, antes de executar git add, criar um commit, trocar de ramificação ou enviar alterações com git push, vale a pena executar git status e interpretar sua resposta. Essa verificação simples evita registrar arquivos indesejados, trabalhar na ramificação errada ou enviar uma alteração diferente daquela que pretendíamos publicar.

Usar o git status antes de qualquer git push é uma boa prática de desenvolvimento.

1.3 Nem tudo precisa ser acompanhado pelo Git

O arquivo .gitignore informa ao Git quais arquivos e diretórios não devem ser incluídos no controle de versão. Ele é usado para ignorar arquivos temporários, resultados de compilação, configurações do editor e credenciais locais que não pertencem ao código-fonte do projeto.

Cada linha contém um padrão:

*.log
build/
.vscode/
.env

Nesse exemplo de texto para o .gitignore, o Git ignorará arquivos terminados em .log, os diretórios build e .vscode e o arquivo .env. Não esqueça que, depois de criado, o .gitignore deve ser adicionado ao repositório para que as mesmas regras sejam compartilhadas pela equipe.

O .gitignore afeta apenas arquivos que ainda não são supervisionados. Se um arquivo já foi registrado em um commit, acrescentá-lo ao .gitignore não interromperá seu acompanhamento. Nesse caso, precisamos removê-lo do índice sem apagá-lo do computador. Para isso podemos usar o comando:

git rm --cached nome-do-arquivo

Vamos criar um arquivo .gitignore desde o início para o nosso exemplo, ainda que o primeiro site seja mínimo:

.DS_Store
Thumbs.db
.vscode/

O arquivo impede que metadados do sistema operacional e preferências pessoais do editor entrem no histórico. O administrador registra esse ponto inicial:

git add .gitignore README.md
git commit -m "Configura o repositório inicial"
git push origin main

Uma mensagem de comando no imperativo descreve o efeito da mudança. Ou seja, a mensagem Configura o repositório inicial ajuda mais do que a mensagem alterações quando alguém investiga o histórico dois meses depois.

1.4 Branches não são pastas copiadas

Um branch, ou ramificação, é um nome móvel que aponta para um commit. Quando criamos uma ramificação, não duplicamos manualmente a pasta; abrimos uma linha de desenvolvimento que pode avançar sem mover a main. A main representará a versão aceita e publicável do projeto, pelo grupo.

O administrador pode experimentar a criação de um branch, da seguinte forma:

Antes de modificar os arquivos, criamos uma ramificação exclusiva para a tarefa:

git switch -c configura-pagina-inicial

A opção -c, forma abreviada de --create, cria a ramificação local configura-pagina-inicial a partir do commit atual e muda imediatamente o diretório de trabalho para ela. A partir desse momento, os novos commits serão registrados nessa linha de desenvolvimento, sem alterar diretamente a ramificação da qual ela nasceu.

Depois de modificar os arquivos, vamos inspecionar, preparar, registrar e publicar a mudança:

git diff
git add index.html
git diff --staged
git commit -m "Cria a página inicial"
git push -u origin configura-pagina-inicial

O primeiro git diff compara o diretório de trabalho com a área de preparação. Ele mostra as alterações realizadas em arquivos já supervisionados que ainda não passaram por git add. Se index.html for um arquivo novo, seu conteúdo ainda não aparecerá nessa comparação; nesse caso, git status indicará que o arquivo ainda não é supervisionado.

O comando git add index.html coloca o estado atual do arquivo na área de preparação. Em seguida, git diff --staged compara essa área com o último commit e mostra exatamente quais alterações serão registradas. Essa segunda inspeção permite conferir o conteúdo antes de executar git commit -m "Cria a página inicial", que cria um novo commit apenas com as alterações preparadas.

Por fim, git push -u origin configura-pagina-inicial envia a ramificação para o repositório remoto identificado por origin. A opção -u, forma abreviada de --set-upstream, estabelece uma relação de acompanhamento entre a ramificação local e a ramificação remota origin/configura-pagina-inicial. Depois dessa primeira publicação, enquanto permanecermos nessa ramificação, o Git poderá identificar o destino automaticamente e os próximos envios poderão usar apenas git push.

1.5 O contrato de colaboração do grupo

Todo pull request compara commits. Logo, os colaboradores também precisam criar commits, mas somente em suas próprias ramificações ou em seus próprios forks. O administrador será a única pessoa autorizada a integrar mudanças na main do repositório oficial.

O contrato correto operacional será:

1. A main do repositório oficial ficará protegida contra envios diretos.
2. Cada integrante criará um fork, isto é, uma cópia do repositório vinculada à própria conta.
3. Cada tarefa nascerá em uma ramificação curta do fork.
4. A integrante produzirá commits pequenos nessa ramificação e abrirá um pull request para a main oficial.
5. O administrador revisará, pedirá correções quando necessário e será a única pessoa a concluir a integração.

A Figura 1 separa os dois territórios do histórico. Os commits da tarefa pertencem à ramificação do fork; a main oficial só avança depois que a proposta atravessa a revisão do administrador. A tentativa de saltar essa passagem encontra a proteção da ramificação.

Figura 1: A proteção da main não proíbe commits; ela obriga que os commits do colaborador atravessem um *pull request* e a revisão do administrador.

Muito Importante: no GitHub, o administrador abre Settings, Branches, adiciona uma regra para main, exige um pull request antes da integração e impede atualizações diretas. Dependendo do plano e do tipo do repositório, os nomes e a disponibilidade das regras podem variar. O resultado que importa é de verificação simples: uma tentativa de enviar diretamente para main deve ser recusada.

1.6 O fluxo de um colaborador

Na página do repositório oficial, o colaborador seleciona Fork. Depois, clona a cópia pertencente à sua conta:

git clone https://github.com/colaborador/administrador.github.io.git
cd administrador.github.io
git remote add upstream https://github.com/administrador/administrador.github.io.git
git remote -v

Agora origin aponta para o fork do colaborador, no qual ela pode escrever, e upstream aponta para o projeto oficial, que ela acompanhará. Antes de começar uma tarefa, o colaborador sincroniza a base:

git switch main
git fetch upstream
git merge --ff-only upstream/main
git push origin main

fetch traz referências sem alterar os arquivos locais. merge --ff-only atualiza a main apenas se a operação puder avançar em linha reta, evitando um commit de mesclagem acidental na cópia de trabalho.

Para criar uma página de contato, por exemplo, o colaborador abre um branch local com um nome descritivo:

git switch -c adiciona-pagina-contato

Depois da edição, o colaborador pode inspecionar e registrar apenas os arquivos da tarefa:

git status
git diff
git add contato.html
git diff --staged
git commit -m "Adiciona a página de contato"
git push -u origin adiciona-pagina-contato

Depois de publicar a ramificação adiciona-pagina-contato no fork, acessamos o repositório original no GitHub. A plataforma normalmente apresenta um aviso com o botão Compare & pull request para a ramificação recém-publicada. Se esse aviso não aparecer, podemos abrir a guia Pull requests, selecionar New pull request e usar a opção compare forks para escolher manualmente os repositórios envolvidos.

Na tela de comparação, precisamos conferir com atenção a direção da proposta. O repositório base será administrador/administrador.github.io e a base branch será main, pois esse é o destino no qual desejamos integrar a mudança. O fork será colaborador/administrador.github.io e o branch será adiciona-pagina-contato, pois essa ramificação contém os commits produzidos pelo colaborador. Em outras palavras, o pull request propõe levar as alterações da ramificação do colaborador para a main do repositório administrado pelo professor.

Antes de criar a proposta, convém examinar as guias de commits e arquivos alterados para confirmar que apenas as mudanças relacionadas à página de contato serão incluídas. O título deve resumir o resultado, como Adiciona a página de contato. A descrição deve explicar o que foi alterado, por que a mudança é necessária e como ela foi testada. Quando a modificação afetar a aparência do site, uma captura de tela permitirá que a pessoa responsável pela revisão avalie o resultado sem precisar executar o projeto localmente.

A criação do pull request não altera imediatamente a main do repositório original. Ela abre uma proposta de integração na qual os commits podem ser examinados, comentados e testados. A main somente avançará quando a proposta for aprovada e integrada.

1.7 Revisar não é apertar um botão verde

O administrador lê o conjunto de alterações em Files changed, abre a página localmente, verifica os links e decide entre aprovar ou solicitar mudanças. Se houver uma correção, o colaborador não abre outro pull request. Ela corrige a mesma ramificação, cria outro commit e executa git push; o pull request é atualizado automaticamente.

Quando a proposta estiver pronta, o administrador poderá escolher Squash and merge. Essa estratégia condensa os commits de tentativa da ramificação em um único commit coerente na main. O histórico oficial permanece legível, a autoria da contribuição é preservada na plataforma e o administrador continua controlando a integração.

Depois da integração, a ramificação pode ser removida. A próxima tarefa, contudo, deve nascer de um main novamente sincronizada, nunca da ramificação antiga.

O pull request não substitui o commit; ele transforma commits em uma proposta revisável.

2. Parte II: o primeiro site no GitHub Pages

O fluxo de colaboração que definimos produz uma main confiável. Falta fazer com que o conteúdo desse branch se torne uma página web pública. O GitHub Pages executa precisamente essa função para arquivos estáticos.

2.1 Site de usuário e site de projeto

O GitHub Pages distingue dois endereços. O repositório especial administrador.github.io publica um site de usuário diretamente em https://administrador.github.io/. Um repositório comum, como portfolio, publica um site de projeto em https://administrador.github.io/portfolio/.

Usaremos o site de usuário porque ele simplifica os caminhos e servirá como origem do domínio próprio. Uma conta possui apenas um repositório de usuário com esse nome especial, embora possa publicar vários sites de projeto.

2.2 A primeira página HTML

Na ramificação cria-primeira-pagina, vamos criar index.html na raiz do repositório:

<!doctype html>
<html lang="pt-BR">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Projeto da equipe</title>
</head>
<body>
  <main>
    <h1>Hello, world!</h1>
    <p>Nosso primeiro site estático está no ar.</p>
  </main>
</body>
</html>

O navegador procura index.html como documento inicial do diretório. O doctype seleciona o modo moderno de HTML, charset permite texto em UTF-8 e viewport evita que a página seja tratada como uma tela larga reduzida em celulares. Ainda não precisamos de uma ferramenta de construção: o arquivo que vemos será o arquivo entregue.

Antes de enviar, abrimos index.html no navegador e verificamos o título, o texto e o console. O colaborador então segue o fluxo da Parte I, abre um pull request e o administrador integra a mudança.

2.3 Ativar a publicação

No repositório oficial, o administrador abre Settings, Pages. Em Build and deployment, seleciona Deploy from a branch, escolhe a ramificação main, a pasta / (root) e salva. O GitHub iniciará uma implantação e mostrará seu estado na própria página e na área de ações do repositório.

Quando a implantação terminar, acessamos:

https://administrador.github.io/

em um navegador web qualquer.

Se a página retornar 404, conferimos quatro fatos: o nome do repositório deve coincidir exatamente com o usuário; index.html deve estar na raiz e na main; a fonte de publicação deve ser main e / (root); a implantação mais recente deve ter concluído sem erro.

Cada integração posterior na fonte de publicação dispara uma nova implantação. Isso conecta as duas primeiras partes do artigo: revisar a main também significa controlar o que vai ao ar.

2.4 Um teste que não depende do cache do navegador

Além de abrir a página, podemos consultar os cabeçalhos HTTP:

curl.exe -I https://administrador.github.io/

Esperamos um código 200. O comando não prova que a página está visualmente correta, mas separa uma falha de publicação de uma impressão causada pelo cache do navegador. Para o conteúdo, podemos fazer uma busca simples:

curl.exe -s https://administrador.github.io/ | findstr /C:"Hello, world!"

Agora temos uma origem pública e reproduzível. O endereço ainda pertence ao GitHub; a próxima parte dará ao grupo um nome que ele controla.

3. Parte III: domínio no Registro.br, DNS e subdomínios

Registrar um domínio não hospeda um site, e editar o DNS não transfere os arquivos HTML. O registro estabelece quem administra um nome, enquanto o DNS publica informações sobre onde encontrar serviços associados a esse nome. Essa distinção será decisiva quando movermos o DNS do Registro.br para o Cloudflare sem mover o site do GitHub Pages.

3.1 Registrar o domínio .br

No Registro.br, pesquisamos projetoexemplo.com.br. Se o resultado indicar disponibilidade, autenticamos a conta, informamos o titular responsável, confirmamos os contatos e concluímos a solicitação. Domínios .br são associados a uma pessoa física ou jurídica legalmente estabelecida no Brasil, conforme a categoria escolhida e as regras vigentes.

Em um trabalho acadêmico, a equipe deve decidir por escrito quem será o titular. O domínio não pertence informalmente ao grupo; ele fica sob um CPF ou CNPJ, possui contatos administrativos e exige renovação. A conta deve usar autenticação em dois fatores, e a equipe deve registrar quem responderá pela renovação depois do encerramento da disciplina.

Podemos começar com o DNS oferecido pelo Registro.br. Mais adiante, ao ativar o Cloudflare, substituiremos os servidores autoritativos. O domínio continuará registrado no Registro.br; apenas a operação do DNS mudará de provedor.

3.2 Os quatro nomes que não devemos confundir

Considere www.projetoexemplo.com.br. A parte br é o domínio de topo; com.br é a categoria sob a qual registramos; projetoexemplo.com.br é o domínio registrado; www é um subdomínio, também chamado de nome de host nesse uso.

O domínio sem um rótulo à esquerda, projetoexemplo.com.br, é o ápice da zona. Em interfaces de DNS, ele costuma aparecer como @. Essa notação é um atalho da interface, não uma parte do endereço que a visitante digita.

3.3 Registros DNS necessários para o GitHub Pages

Antes de alterar o DNS, o administrador informa ao GitHub qual será o domínio. Em Settings, Pages, Custom domain, ele adiciona primeiro www.projetoexemplo.com.br e salva. Essa ordem reduz o risco de apontar um subdomínio ao GitHub antes que o repositório esteja associado a ele.

Para o subdomínio www, criamos um registro CNAME:

O CNAME declara que www.projetoexemplo.com.br é um nome alternativo do site de usuário. O destino não contém https://, uma barra final nem o nome de outro repositório.

Para o ápice, um CNAME convencional não é adequado porque o mesmo nome precisa coexistir com registros obrigatórios da zona. O GitHub publica quatro endereços IPv4 para registros A:

Esses endereços devem sempre ser conferidos na documentação oficial do GitHub antes da configuração, pois pertencem ao serviço, não ao nosso projeto. Também é possível acrescentar os registros AAAA oficiais para IPv6. Neste primeiro percurso, manter os quatro registros A e o CNAME de www torna a topologia visível.

O GitHub recomenda configurar tanto o ápice quanto www. Quando ambos estão corretos, a plataforma redireciona uma forma para a outra de acordo com o nome definido em Custom domain. Usaremos www.projetoexemplo.com.br como forma canônica.

3.4 Criar outros subdomínios

Um subdomínio não precisa ser comprado separadamente. Quem controla a zona de projetoexemplo.com.br pode criar nomes como docs.projetoexemplo.com.br e equipe.projetoexemplo.com.br. O registro necessário depende do destino:

O endereço 192.0.2.10 pertence a uma faixa reservada para documentação e não servirá uma aplicação real. Para ligar docs a outro repositório GitHub Pages, precisamos configurar docs.projetoexemplo.com.br também como domínio personalizado naquele site; criar apenas o registro DNS não autoriza o repositório a responder pelo nome.

Não criaremos um curinga como *.projetoexemplo.com.br. Além de esconder erros de digitação, um curinga apontado ao GitHub Pages amplia o risco de apropriação indevida de subdomínios que não foram associados a um repositório.

3.5 Verificar o DNS no Windows

DNS possui cache, por isso a interface do provedor não é prova suficiente. No PowerShell, consultamos os dados publicados:

Resolve-DnsName projetoexemplo.com.br -Type A
Resolve-DnsName www.projetoexemplo.com.br -Type CNAME
Resolve-DnsName projetoexemplo.com.br -Type NS

O primeiro resultado deve conter os endereços esperados; o segundo deve conduzir ao site do GitHub; o terceiro revela quais servidores possuem autoridade sobre a zona. Depois, testamos HTTPS e o redirecionamento:

curl.exe -I https://www.projetoexemplo.com.br/
curl.exe -I https://projetoexemplo.com.br/

Mudanças de DNS podem levar tempo para aparecer em caches. Esperar, contudo, só faz sentido depois de confirmarmos que os servidores autoritativos já publicam o valor correto. Um erro de digitação não amadurece com o tempo.

Depois que o GitHub emitir o certificado, marcamos Enforce HTTPS em Settings, Pages. O arquivo CNAME criado na raiz da fonte de publicação deve continuar no repositório quando a publicação parte de uma ramificação.

4. Parte IV: Cloudflare diante do GitHub Pages

Até aqui, a visitante resolve o domínio e chega diretamente à infraestrutura do GitHub Pages. Agora faremos uma mudança de autoridade. O Registro.br continuará sendo o registrador, mas delegará o DNS ao Cloudflare. Quando o ícone de proxy estiver ativado, a visitante se conectará primeiro à rede do Cloudflare, que poderá encerrar HTTPS, aplicar regras e entregar respostas armazenadas em cache; quando necessário, o Cloudflare buscará o arquivo na origem GitHub Pages.

Cloudflare Pages e GitHub Pages são produtos de hospedagem diferentes. Neste projeto não criaremos um projeto Cloudflare Pages.

4.1 Criar a conta e adicionar a zona

Criamos uma conta no Cloudflare, ativamos a autenticação em dois fatores e selecionamos Onboard a domain. Informamos apenas o domínio de ápice, projetoexemplo.com.br, nunca www.projetoexemplo.com.br, e escolhemos o plano adequado ao exercício.

O Cloudflare tentará importar registros existentes. Essa varredura é uma conveniência, não uma garantia. Antes de trocar os servidores DNS, comparamos registro por registro e confirmamos a presença dos quatro A do ápice e do CNAME de www. Se o domínio já recebe correio eletrônico, também precisamos preservar MX, TXT, DKIM, SPF e DMARC. Perder um registro de e-mail enquanto se publica uma página é uma forma particularmente eficiente de transformar um exercício simples em incidente.

Inicialmente, deixamos os registros web em DNS only, representado pela nuvem cinza. Esse estado permite que o GitHub valide o domínio e emita seu certificado sem acrescentarmos outra camada à investigação.

4.2 Trocar os servidores autoritativos no Registro.br

O Cloudflare atribuirá dois servidores DNS específicos à zona, com nomes semelhantes a nome.ns.cloudflare.com. Copiamos exatamente os dois. Se o domínio já usa DNSSEC, precisamos primeiro desativar a assinatura no provedor anterior e aguardar a expiração do registro DS publicado na zona .br. Trocar os servidores enquanto o DS antigo ainda aponta para outras chaves fará os resolvedores que validam DNSSEC recusarem o domínio com SERVFAIL.

Somente depois dessa verificação, no painel do Registro.br, abrimos o domínio, escolhemos a alteração dos servidores DNS, substituímos os servidores atuais pelos atribuídos pelo Cloudflare e salvamos.

Não copie os servidores de outra conta nem os nomes ilustrativos de um tutorial. A atribuição aparece na tela Overview da zona e não pode ser deduzida a partir do domínio.

Verificamos a delegação:

Resolve-DnsName projetoexemplo.com.br -Type NS

Quando a consulta retornar os dois servidores designados pelo Cloudflare e o painel mostrar a zona como ativa, a mudança de autoridade terminou. O conteúdo permanece no GitHub Pages; apenas as respostas DNS passaram ao Cloudflare.

Com a zona ativa e estável, reativamos DNSSEC. Em DNS, Settings, DNSSEC, selecionamos Enable DNSSEC. O Cloudflare assinará a zona e mostrará os campos do novo registro DS. No Registro.br, habilitamos DNSSEC para o domínio com os valores fornecidos, sem transcrevê-los de nenhum exemplo. Depois da publicação, uma consulta deve encontrar a cadeia nova:

Resolve-DnsName projetoexemplo.com.br -Type DS
Resolve-DnsName projetoexemplo.com.br -Type DNSKEY

DNSSEC autentica as respostas DNS; ele não substitui HTTPS e não criptografa a consulta. A ordem da migração é o que protege a disponibilidade: remover a confiança antiga, trocar a autoridade e somente então publicar a confiança nova.

4.3 Validar a origem antes de ativar o proxy

Com as nuvens ainda cinzas, repetimos as consultas de DNS e HTTP da Parte III. Também voltamos a Settings, Pages, confirmamos www.projetoexemplo.com.br como domínio personalizado e verificamos se Enforce HTTPS está disponível e ativo.

Essa etapa produz uma linha de base. Se o site não funciona em DNS only, ativar o proxy apenas acrescenta outra conexão TLS e outra camada de cache ao defeito.

4.4 Ativar o proxy e escolher o modo de criptografia

No painel DNS, ativamos o proxy, a nuvem laranja, para www e para os registros do ápice usados pelo site. A partir desse momento, uma consulta pública aos registros A normalmente retornará endereços do Cloudflare, não os endereços 185.199.* da origem. Isso é esperado: o DNS está direcionando a visitante ao proxy.

Em SSL/TLS, usamos o modo Full (strict). Nesse modo, há uma conexão HTTPS entre a visitante e o Cloudflare e outra entre o Cloudflare e a origem; o certificado apresentado pelo GitHub Pages precisa ser válido para o domínio solicitado. Não usamos Flexible, pois ele deixaria a conexão entre o Cloudflare e a origem em HTTP e poderia produzir redirecionamentos inesperados.

A Figura 2 torna concreta a diferença entre publicar DNS e intermediar tráfego. Nos dois painéis, o Registro.br delega a zona ao Cloudflare e o GitHub Pages hospeda os mesmos arquivos. A nuvem laranja altera apenas a rota seguida pelas requisições HTTP e HTTPS.

Figura 2: Ativar o proxy acrescenta o Cloudflare ao caminho HTTPS, mas não transfere a origem para o produto Cloudflare Pages.

Depois, ativamos Always Use HTTPS se a zona ainda aceitar HTTP. Mantemos Automatic HTTPS Rewrites apenas quando houver conteúdo antigo com referências inseguras e depois de entender o que ele reescreverá. HSTS fica para uma etapa posterior: uma política HSTS persistida pelo navegador dificulta a recuperação de uma configuração HTTPS defeituosa.

4.5 Cache: começar pelo comportamento padrão

O simples fato de usar a nuvem laranja não significa que todo HTML ficará guardado indefinidamente. O Cloudflare decide a elegibilidade e a duração do cache a partir do tipo de recurso, dos cabeçalhos e das regras da zona. Para o primeiro site, mantemos o cache padrão e verificamos a entrega antes de criar regras.

curl.exe -I https://www.projetoexemplo.com.br/

Cabeçalhos como server: cloudflare e cf-ray indicam que a resposta passou pela rede do Cloudflare. cf-cache-status descreve a decisão de cache para aquela resposta; um DYNAMIC ou MISS não prova uma falha, pois HTML e recursos estáticos podem receber tratamentos diferentes.

Se quisermos aumentar o cache de imagens, folhas de estilo e scripts, criamos uma Cache Rule restrita às extensões desses arquivos. Não começamos com Cache Everything sobre /*, porque isso também pode guardar HTML e atrasar a visualização de uma correção. Um site estático tolera cache agressivo melhor que uma aplicação dinâmica, mas ainda possui uma página inicial que a equipe espera atualizar.

4.6 Redirecionamento canônico e subdomínios

Já configuramos www.projetoexemplo.com.br como domínio canônico no GitHub Pages, que pode redirecionar o ápice quando os dois nomes estão configurados. Portanto, não acrescentamos outra regra de redirecionamento no Cloudflare sem necessidade. Dois redirecionadores tentando impor decisões diferentes criam laços.

Para um novo subdomínio, como docs, o procedimento mantém três responsabilidades separadas:

1. Criamos o registro DNS docs no Cloudflare.
2. Associamos docs.projetoexemplo.com.br ao serviço de origem que responderá por ele.
3. Validamos o certificado com DNS only antes de ativar o proxy.

O proxy não corrige uma origem que desconhece o nome solicitado. Ele apenas fica no caminho.

4.7 Checklist de aceitação

O projeto estará completo quando outra pessoa, fora da rede e sem usar a sessão do administrador, conseguir confirmar todos estes resultados:

• https://administrador.github.io/ publica a versão integrada da main.
• https://www.projetoexemplo.com.br/ apresenta a mesma versão por HTTPS válido.
• O domínio de ápice redireciona uma única vez para o nome canônico escolhido.
• Uma consulta NS retorna os dois servidores atribuídos pelo Cloudflare.
• Os registros web estão com proxy ativo e a resposta contém cf-ray.
• Um colaborador não consegue enviar diretamente para a main, mas consegue atualizar seu pull request com novos commits.
• O administrador consegue revisar e integrar a proposta, e a nova implantação termina sem erro.

Devemos guardar ainda uma captura da regra de proteção, o endereço de um pull request integrado, o resultado das consultas NS, A e CNAME, e os cabeçalhos HTTP finais. Essas evidências demonstram o processo, não apenas a aparência da página.

5. O mapa do sistema que construímos

Ao final, uma alteração percorre duas cadeias diferentes. Na cadeia de desenvolvimento, o colaborador modifica uma ramificação do fork, cria commits, abre um pull request e recebe a revisão do administrador. A integração na main aciona o GitHub Pages, que atualiza a origem.

Na cadeia de entrega, a visitante consulta o domínio. Os servidores autoritativos do Cloudflare respondem, o navegador se conecta ao proxy e o proxy entrega uma resposta em cache ou consulta a origem no GitHub Pages. O Registro.br não participa de cada acesso; ele conserva a titularidade e publica qual conjunto de servidores possui autoridade pelo domínio.

É por isso que quatro painéis não significam quatro hospedagens. O Git conserva a história, o GitHub governa a colaboração, o GitHub Pages hospeda a origem, o Registro.br mantém o domínio e o Cloudflare opera o DNS e a camada de entrega.

Começamos com um arquivo index.html. Terminamos com um sistema pequeno, mas completo: possui autoria, revisão, implantação, identidade própria na Internet, criptografia e uma fronteira clara entre origem e entrega.

Referências

CLOUDFLARE. Change your nameservers: Full setup. Cloudflare Docs, 2026. Disponível em: https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/. Acesso em: 16 ago. 2026.

CLOUDFLARE. Encryption modes. Cloudflare Docs. Disponível em: https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/. Acesso em: 16 ago. 2026.

CLOUDFLARE. DNSSEC. Cloudflare Docs, 2026. Disponível em: https://developers.cloudflare.com/dns/dnssec/. Acesso em: 16 ago. 2026.

CLOUDFLARE. Get started with Cloudflare DNS. Cloudflare Docs. Disponível em: https://developers.cloudflare.com/dns/get-started/. Acesso em: 16 ago. 2026.

CLOUDFLARE. Proxy status. Cloudflare Docs. Disponível em: https://developers.cloudflare.com/dns/proxy-status/. Acesso em: 16 ago. 2026.

GITHUB. About branches. GitHub Docs. Disponível em: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches. Acesso em: 16 ago. 2026.

GITHUB. About pull requests. GitHub Docs. Disponível em: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests. Acesso em: 16 ago. 2026.

GITHUB. Creating a GitHub Pages site. GitHub Docs. Disponível em: https://docs.github.com/en/pages/getting-started-with-github-pages/creating-a-github-pages-site. Acesso em: 16 ago. 2026.

GITHUB. Managing a custom domain for your GitHub Pages site. GitHub Docs. Disponível em: https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site. Acesso em: 16 ago. 2026.

GITHUB. Managing a branch protection rule. GitHub Docs. Disponível em: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule. Acesso em: 16 ago. 2026.

GIT. Git reference. Disponível em: https://git-scm.com/docs. Acesso em: 16 ago. 2026.

REGISTRO.BR. Gerenciamento de conta: DNS. Disponível em: https://registro.br/ajuda/gerenciamento-de-conta/. Acesso em: 16 ago. 2026.

REGISTRO.BR. Registro de novos domínios. Disponível em: https://registro.br/ajuda/registro-de-novos-dominios/. Acesso em: 16 ago. 2026.

REGISTRO.BR. Regras do domínio. Disponível em: https://registro.br/dominio/regras/. Acesso em: 16 ago. 2026.