Publique o projeto e feche o ciclo com pull request

O projeto final reúne o curso: histórico local legível, branch de tarefa, sincronização com remoto, pull request, README executável e tag anotada. A publicação acontece numa conta e num repositório sob sua responsabilidade. O curso não cria GitHub externo, não aprova revisão em nome de outra pessoa e não finge que um bare local possui interface.

Antes de usar rede, pratique com bare local:

LAB=$(mktemp -d /tmp/curso-git-remoto.XXXXXX)
git init --bare "$LAB/central.git"
git remote add origin "$LAB/central.git"
git push -u origin main

Remote é um apelido para endereço e referências. origin é convenção, não palavra reservada. -u associa a branch local a origin/main, permitindo push e pull sem repetir nomes. Um push envia commits; conteúdo apenas no stage ou na working tree não viaja.

Clone em outra pasta, faça um commit e envie. Na primeira cópia, execute apenas fetch:

git fetch origin
git --no-pager log --oneline --graph --decorate --all

origin/main avança, mas main e os arquivos atuais não mudam. Essa pausa permite revisar. git pull --ff-only integra apenas quando a branch local é ancestral direta. Se houver divergência, escolha merge ou rebase segundo a política. Nunca resolva push rejeitado com force antes de descobrir qual commit remoto falta.

Quando o laboratório estiver claro, crie no GitHub um repositório vazio se seu histórico já nasceu localmente. Copie a URL HTTPS ou SSH, substitua o remote de teste e autentique pelo mecanismo oficial. Nome e e-mail de commit não são senha. Não coloque token no endereço ou no código.

Abra uma branch curta e prepare dois commits coerentes. Antes do push, revise:

git status --short
git diff main...HEAD
git --no-pager log --oneline main..HEAD

No GitHub, abra o PR com main como base. O título descreve resultado. A descrição informa problema, solução, como testar, riscos e itens fora do escopo. Comentários e aprovação exigem pessoas reais. Um novo commit na mesma branch atualiza o PR; não abra outro para cada ajuste.

Escolha a estratégia de merge pelo histórico desejado. Merge commit preserva topologia e commits; squash cria um commit consolidado; rebase merge reaplica commits em linha. O código final pode coincidir, mas os hashes e pais mudam. Registre a convenção escolhida no projeto.

O README precisa sobreviver ao teste de uma pasta limpa. Inclua promessa, requisitos, instalação, variáveis de exemplo, comando de execução, teste, decisões e licença quando aplicável. Clone novamente e siga somente o texto. Toda informação que você completou de memória estava faltando.

Depois do merge e da atualização da main, marque uma versão anotada:

git tag -a v1.0.0 -m "Primeira versão de portfólio"
git push origin v1.0.0
git --no-pager show --no-patch v1.0.0

Uma release na interface é opcional e precisa apontar para essa tag, com notas baseadas no intervalo real de commits. Não invente deploy nem revisão. Se o projeto não está hospedado publicamente, diga isso com honestidade e entregue a prova local que existe.

O checklist final é objetivo: working tree limpa; commits que explicam decisões; branch do PR integrada; README executado em clone; nenhum segredo no histórico; tag no commit certo; remote e upstream conferidos. Apague branches somente depois de confirmar a integração.

Conclua o desafio em um repositório autorizado e cole no seu registro de estudo os links do repositório e do PR, além do hash da tag. Se não houver pessoa para revisar, abra o PR e faça uma auto-revisão declarada, sem afirmar aprovação externa. O resultado do curso é um projeto reproduzível e uma narrativa honesta de como ele chegou à versão publicada.