Subir projeto para o GitHub: remote, push, clone e pull

Para publicar um repositório local, conecte um remote, envie a branch e defina o upstream. clone faz o caminho inverso quando o projeto já existe no remoto. fetch baixa objetos e atualiza referências remotas sem tocar na sua working tree; pull busca e também integra.

Os comandos foram executados contra um repositório bare local. Ele reproduz o protocolo de arquivos do Git sem autenticação e sem criar ou alterar um projeto externo no GitHub.

git init --bare /tmp/grupo-git-remoto.GmCWt4/central.git

No GitHub, comece vazio quando o histórico nasceu local

Na interface do GitHub, crie um repositório sem README, .gitignore ou licença se a pasta local já tem o primeiro commit. Essa etapa de interface não foi executada por este material: depende da sua conta, nome e permissões. A recomendação vem da documentação oficial e evita criar duas raízes diferentes.

Se você inicializar os dois lados, o Git não encontra ancestral comum. O artigo do erro unrelated histories mostra as duas saídas honestas.

Remote é um apelido para endereço e referências

Dentro do repositório local, o teste associou origin ao bare:

git remote add origin /tmp/grupo-git-remoto.GmCWt4/central.git
git remote -v

Num GitHub real, o endereço seria HTTPS ou SSH. O nome origin não significa GitHub e não é palavra reservada. Ele só economiza repetir o endereço.

Push envia commits e cria o upstream

O primeiro push real do sandbox produziu:

git push -u origin main

-u registra que a main local acompanha origin/main. Nos próximos envios, git push sabe o destino. Isso não manda arquivos soltos: transfere objetos e tenta avançar a referência remota. Um commit que ficou apenas na working tree ou no stage não viaja.

git branch -vv

Os dois nomes apontam para o mesmo hash logo após o push. Eles podem divergir quando outra cópia trabalha.

Clone parte do remoto e configura origin

Outra pasta recebeu histórico, arquivos e configuração:

git clone /tmp/grupo-git-remoto.GmCWt4/central.git copia-a

O clone não é download de ZIP. Ele contém .git, commits e referências. A cópia fez uma alteração e enviou; a origem inicial ainda não conhecia esse commit até buscar.

Fetch atualiza a observação sem integrar

Antes do fetch, main e origin/main locais estavam em 16eb2a6. Depois que a outra cópia enviou 8eb0591, o comando mostrou o avanço:

git fetch origin

O arquivo da working tree não mudou. main continuou local; origin/main passou a representar a última observação do remote:

git --no-pager log --oneline --decorate --all -3

A ordem textual pode variar quando datas empatam; o grafo e os nomes dizem a relação. Compare o diff antes de integrar.

Pull busca e atualiza a branch atual

Como a local era ancestral direta da remota, --ff-only aceitou:

git pull --ff-only

Se houver divergência, --ff-only recusa e obriga você a escolher merge ou rebase. Essa recusa é útil: evita criar uma integração sem perceber. Configure uma política com o time, em vez de escolher uma opção apenas para silenciar o terminal.

HTTPS e SSH autenticam; user email não

No GitHub, HTTPS usa token por meio de um gerenciador de credenciais; SSH usa um par de chaves. Não coloque token no remote, no código ou no .env versionado. user.name e user.email identificam commits, mas não concedem acesso. Uma falha de autenticação não se resolve trocando o autor.

git remote get-url origin

O caminho confirma o limite do teste: não houve token nem SSH. Ao usar GitHub, siga a documentação atual para adicionar a credencial e valide o remote com git remote -v antes do primeiro push.

Um projeto pode ter mais de um remote

Em contribuição open source, origin costuma apontar para o seu fork e upstream para o repositório original. Fetch pode consultar ambos, mas push só deve ir para o destino em que você possui permissão e intenção. Os nomes são locais: outra pessoa pode escolher convenção diferente, embora manter origin e upstream reduza confusão.

Antes de copiar um comando de publicação, confira URL e branch. Um remote com nome certo e endereço errado ainda envia ao lugar errado. git remote get-url --all origin mostra URLs configuradas, e git branch --show-current confirma a linha que você está prestes a publicar. Em empresas, políticas do servidor podem rejeitar push direto na main e exigir uma branch com pull request. Essa recusa não se corrige trocando credencial: ela protege o fluxo acordado.

Remover um remote com git remote remove apaga apenas a configuração local e as referências de acompanhamento associadas; não apaga o repositório hospedado. Da mesma forma, renomear origin não move commits na internet. Separe sempre a configuração que vive em .git/config do serviço remoto que possui suas próprias permissões e retenção.

O tropeço comum é criar README remoto e commit local separadamente. Outro é confundir fetch com pull e perder a oportunidade de inspecionar. Se o push for recusado, leia remote contains work antes de considerar force.

Sua missão é criar um bare local, fazer push de uma pasta, clonar em outra, enviar um commit da segunda e observar origin/main mover com fetch na primeira. Termine quando souber explicar o upstream e estiver pronto para abrir um pull request numa conta sua, com revisão humana.