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: a estudante termina um tutorial com uma página funcionando, mas não consegue reconstruir o caminho quando precisa trabalhar em uma equipe real.

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.

Embora este artigo tenha sido inicialmente imaginado em três partes, o trabalho contém 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, substitua equipe-exemplo, administrador e projetoexemplo.com.br pelos nomes reais. Não copie 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.

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, git add o coloca na área de preparação, chamada staging area. Finalmente, git commit grava uma fotografia lógica das mudanças preparadas no histórico local.

Essa separação permite editar três arquivos e incluir apenas dois em um commit. O commit não significa enviar ao GitHub. Ele existe primeiro no repositório local; git push é a operação que o envia a um repositório remoto.

Depois de instalar o Git, cada participante configura a identidade que aparecerá no histórico:

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

O endereço deve pertencer à conta do GitHub ou ser o endereço privado fornecido pela plataforma. A autenticação do push será feita por uma credencial aceita pelo GitHub, como uma chave SSH ou o gerenciador de credenciais. A senha comum da conta não substitui esse mecanismo.

1.2 O primeiro repositório

O administrador cria no GitHub um repositório público chamado exatamente administrador.github.io. Esse nome não é decoração: um repositório de usuário 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 entra na pasta:

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

Clonar cria a cópia local e configura, com o nome convencional origin, o endereço do repositório no GitHub. git status é o nosso painel de instrumentos: antes de adicionar, confirmar, trocar de ramificação ou enviar mudanças, vale lê-lo.

Vamos criar um arquivo .gitignore desde o início, 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 no imperativo descreve o efeito da mudança. Configura o repositório inicial ajuda mais do que alterações quando alguém investiga o histórico dois meses depois.

1.3 Branches não são pastas copiadas

Uma 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 grupo.

O administrador pode experimentar uma alteração assim:

git switch -c configura-pagina-inicial

Depois de modificar arquivos, ele confere a diferença, prepara e registra 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 mostra mudanças ainda não preparadas. O segundo mostra exatamente o que entrará no próximo commit. A opção -u relaciona a ramificação local à remota, permitindo que os próximos envios usem apenas git push.

1.4 O contrato de colaboração do grupo

A frase apenas o administrador fará os commits; os demais abrirão pull requests contém uma impossibilidade técnica que precisamos corrigir antes de ela virar regra de avaliação. Todo pull request compara commits. Logo, as colaboradoras 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 será este:

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* da colaboradora atravessem um *pull request* e a revisão do administrador.

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 é verificável: uma tentativa de enviar diretamente para main deve ser recusada.

1.5 O fluxo de uma colaboradora

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

git clone https://github.com/colaboradora/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 da colaboradora, no qual ela pode escrever, e upstream aponta para o projeto oficial, que ela acompanhará. Antes de começar uma tarefa, a colaboradora 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, a colaboradora abre uma ramificação com um nome descritivo:

git switch -c adiciona-pagina-contato

Depois da edição, ela inspeciona e registra 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

Na página do fork, o botão Compare & pull request abre a proposta. A base deve ser administrador/administrador.github.io:main; a origem deve ser colaboradora/administrador.github.io:adiciona-pagina-contato. O título resume o resultado, enquanto a descrição informa o que mudou, como a alteração foi testada e, quando houver mudança visual, inclui uma captura de tela.

1.6 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, a colaboradora 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 uma 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 agora produz uma main confiável. Falta fazer com que o conteúdo dessa ramificação se torne uma página 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. A colaboradora 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/

Se a página retornar 404, conferimos quatro fatos antes de esperar ao acaso: 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.
• Uma colaboradora 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, a colaboradora 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.