Trilha de aprendizado · Nível 3 · Tutorial 2

Publicar um repositório local no GitHub

Conectar um projeto que já possui commits a um repositório vazio no GitHub, publicar uma branch e conferir o resultado.

Nível: Iniciante
Duração: 15 min
6 passos

Começar tutorial Voltar para a trilha

O que você vai percorrer

Entender o que será publicado Identifique quais versões serão enviadas ao GitHub e o que continuará apenas no seu computador. 2 min
Criar um destino vazio no GitHub Crie o repositório de destino com a visibilidade escolhida e sem arquivos ou commits iniciais. 2 min
Associar e conferir o remoto origin Associe a URL HTTPS do repositório ao nome origin e confira o destino antes de publicar. 3 min
Publicar a branch com acompanhamento Faça o primeiro push de uma branch local, configure seu acompanhamento e reconheça a confirmação no terminal. 4 min
Conferir a publicação no GitHub Confira o destino, a branch, os arquivos e os commits para validar a publicação. 2 min
Aplicar o fluxo e concluir a publicação Organize o fluxo de primeira publicação e reúna evidências de que a branch foi publicada corretamente. 3 min

O que você vai aprender

Criar um repositório vazio no GitHub com a visibilidade escolhida, sem gerar arquivos iniciais.
Associar a URL HTTPS do repositório ao remoto origin e conferir a configuração.
Publicar uma branch local existente e configurar sua relação de acompanhamento com a branch remota.
Conferir no GitHub a branch publicada, seus arquivos e seus commits.

Antes de começar

Configurar o acesso seguro ao GitHub
Registrar alterações em commits locais
Inspecionar alterações e histórico com diff e log
Evitar arquivos desnecessários nos commits com .gitignore
Criar e alternar branches com segurança

Passo 1 de 6

Entender o que será publicado

Identifique quais versões serão enviadas ao GitHub e o que continuará apenas no seu computador.

Um histórico em dois lugares

Ponto de partida

Use um projeto de prática que já tenha commits, sem dados sensíveis nos arquivos nem no histórico e com o acesso ao GitHub por HTTPS preparado.

Publicar não é mover

Seu repositório local guarda o histórico no computador. Publicar uma branch leva os commits do histórico dela ao repositório remoto no GitHub, incluindo versões anteriores.

O histórico continua disponível localmente: a publicação não o apaga do computador.

O que acontece com o histórico local?

Verdadeiro ou falso?

Depois de publicar uma branch no GitHub, seus commits deixam de existir no repositório local.

VerdadeiroFalso

O limite é o commit

Nem toda alteração será enviada

Push é o envio de commits ao remoto. Alterações ainda não commitadas ficam de fora, mesmo que estejam na área de preparação.

Exemplo

Uma página em construção

A branch site tem dois commits:

O primeiro criou uma página.
O segundo mudou o título da página.

Depois, você mudou a cor da página e colocou essa alteração na área de preparação, mas não fez outro commit.

O que aparecerá no GitHub?

Escolha o resultado da publicação

Ao publicar a branch site do exemplo, com dois commits e a mudança de cor apenas preparada, o que estará no GitHub?

Os dois commits e a página com o título atualizado, sem a nova cor.Só o segundo commit e a página com o título atualizado, sem a nova cor.Os dois commits e a página com o título atualizado e a nova cor.

Passo 2 de 6

Criar um destino vazio no GitHub

Crie o repositório de destino com a visibilidade escolhida e sem arquivos ou commits iniciais.

Defina o destino

Abra a criação de um repositório

No GitHub, abra o menu + e escolha a opção de criar um novo repositório.

Preencha:

Proprietário: confira a conta em que o repositório será criado.
Nome do repositório: escolha um nome disponível nessa conta.
Visibilidade: selecione a opção pública ou privada que você já decidiu usar.

Antes de criar, ajuste as opções de inicialização.

Deixe o destino sem commits

Não gere arquivos pelo GitHub

Nas opções de inicialização:

README: deixe a opção de adicionar desativada.
.gitignore: mantenha a opção de não adicionar; não selecione um modelo.
Licença: mantenha a opção de não adicionar; não selecione uma licença.

Gerar qualquer um desses arquivos cria um commit no GitHub. Neste fluxo, o destino precisa começar sem commits, pois receberá o histórico que já existe no seu computador.

Dica

Não precisa recriar o que já existe

Se README, .gitignore ou licença já fazem parte do histórico local da branch, eles serão enviados com ela. Deixar essas opções desativadas no site não exclui seus arquivos locais.

Confira a configuração

Qual configuração atende ao fluxo?

Você decidiu usar um repositório privado. Seu projeto local já tem commits, incluindo README e .gitignore. Qual configuração e justificativa estão corretas?

Privado, sem README, .gitignore ou licença gerados, para receber o histórico local em um destino sem commits.Privado, com README gerado, porque é necessário ter um arquivo no destino antes de receber o histórico local.Público, sem arquivos gerados, porque um destino vazio dispensa manter a visibilidade escolhida.Privado, com .gitignore gerado, porque esse arquivo precisa ser recriado no GitHub para acompanhar o projeto.

Crie e confira o destino

Agora, crie o repositório

Revise proprietário, nome, visibilidade e as três opções de inicialização. Depois, clique no botão de criar o repositório.

Na página aberta, confira:

O proprietário e o nome correspondem ao destino planejado.
A visibilidade é a escolhida.
Aparecem instruções de configuração inicial, sem uma lista de arquivos ou commits.

Mantenha essa página aberta para o próximo passo.

Dica

Se aparecer um arquivo inicial

Esse destino não está vazio. Para seguir este tutorial, prepare outro repositório de prática sem inicialização automática. Apenas apagar o arquivo não remove o commit já criado.

Passo 3 de 6

Associar e conferir o remoto origin

Associe a URL HTTPS do repositório ao nome origin e confira o destino antes de publicar.

Associe um nome ao destino

O que é um remoto?

Um remoto é uma associação, na configuração local, entre um nome e uma URL. Usaremos origin: é um nome convencional, não obrigatório, e não é o próprio repositório.

Copie a URL HTTPS

Na página do repositório vazio criado no GitHub, localize a seção de configuração inicial. Selecione HTTPS e copie a URL do repositório. Não inclua senha, token ou outras credenciais nesse endereço.

Atenção

Confira antes de adicionar

Na pasta do projeto local, execute git remote -v. Se aparecer origin, compare a URL com o destino desejado. Se já estiver correta, não adicione novamente. Se estiver diferente, pare e investigue: não substitua a associação às cegas.

Adicione origin se ele ainda não existir

Substitua <URL-HTTPS> pela URL copiada, sem os sinais < >, e execute. Esse comando apenas configura o destino; não envia commits.

bash

git remote add origin <URL-HTTPS>

Complete a associação

Qual nome usar?

Neste exemplo fictício, o projeto local ainda não tem remotos. Complete o comando com o nome convencional usado neste tutorial:

git remote add ____ https://github.com/ana-exemplo/caderno-git.git

Confira a configuração

Liste o nome e as URLs

Depois de adicionar origin, execute este comando para conferir o que ficou registrado:

bash

git remote -v

Saída para o exemplo anterior

text

origin  https://github.com/ana-exemplo/caderno-git.git (fetch)
origin  https://github.com/ana-exemplo/caderno-git.git (push)

O que precisa coincidir?

Compare as duas entradas com o seu destino:

Nome do remoto: origin.
Protocolo: https://, no endereço do GitHub.
Proprietário: sua conta ou a organização escolhida.
Repositório: o nome exato do repositório criado.

Essa saída mostra a configuração local. Ela não comprova que commits foram publicados.

É seguro prosseguir?

Confira este cenário

O destino esperado é https://github.com/ana-exemplo/caderno-git.git. Você apenas adicionou o remoto e executou git remote -v, que exibiu:

text

origin  https://github.com/equipe-exemplo/caderno-git.git (fetch)
origin  https://github.com/equipe-exemplo/caderno-git.git (push)

Qual é a conclusão correta?

Considere o destino configurado e o efeito dos comandos executados.

O nome do repositório coincide; posso continuar, mesmo com outro proprietário.O proprietário difere; preciso revisar o destino. Esses comandos não enviaram commits.O proprietário difere; a conferência já enviou os commits para o endereço exibido.

Passo 4 de 6

Publicar a branch com acompanhamento

Faça o primeiro push de uma branch local, configure seu acompanhamento e reconheça a confirmação no terminal.

Publique a branch escolhida

Com origin já conferido, use este comando no terminal, dentro do projeto. Substitua <nome-da-branch> pelo nome real de uma branch local existente, sem os sinais < >. Ela não precisa se chamar main nem ser renomeada.

Modelo do comando

bash

git push -u origin <nome-da-branch>

O que esse push faz

O comando envia os commits necessários e cria ou atualiza a branch de mesmo nome no remoto. Neste primeiro envio ao destino vazio, ela será criada. O comando não publica automaticamente todas as branches locais.

Dica

Para que serve -u?

Após o envio bem-sucedido, -u registra o upstream: a relação de acompanhamento entre a branch local e a branch correspondente no remoto. Essa relação não é uma sincronização automática; novos commits não serão enviados sozinhos.

Monte o primeiro push

Use o nome da branch apresentada

Um projeto tem a branch local pagina-inicial e o remoto origin já conferido. Organize os blocos conforme o modelo para publicar essa branch e configurar seu acompanhamento.

Sua frase

Palavras disponíveis

Execute e confira a saída

Agora, no seu projeto

Execute o comando com o nome real da branch que você escolheu publicar. Aguarde o término e procure duas confirmações: a criação da branch no remoto e a configuração do acompanhamento.

Exemplo

Dois sinais de sucesso

Para a branch do exercício, estes seriam os sinais esperados, com a mensagem de acompanhamento traduzida e simplificada:

[new branch] pagina-inicial -> pagina-inicial: indica que a branch foi criada no remoto.
“A branch local pagina-inicial foi configurada para acompanhar a branch pagina-inicial do remoto origin”: confirma o efeito de -u.

A redação pode variar conforme a versão e o idioma do Git. Mensagens de progresso da transferência, sozinhas, não confirmam os dois resultados.

Atenção

Se aparecer um erro, pare

Não considere a publicação concluída nem tente contornar o problema com envio forçado. Leia o erro e revise o nome da branch, o destino de origin, o acesso HTTPS e se o repositório no GitHub foi criado vazio. Resolva a condição indicada antes de continuar.

Interprete o resultado

Publicação e acompanhamento

Você executou git push -u origin entrega. Qual relato confirma o envio e descreve corretamente o efeito de -u?

A saída confirma a criação de entrega no remoto e o acompanhamento configurado. Novos commits não serão enviados automaticamente.A saída confirma a criação de entrega no remoto e o acompanhamento configurado. Novos commits serão enviados automaticamente.A saída mostra apenas o progresso da transferência. Isso basta para confirmar a publicação e o acompanhamento.

Passo 5 de 6

Conferir a publicação no GitHub

Confira o destino, a branch, os arquivos e os commits para validar a publicação.

Confira o destino e a branch

Abra a versão que você publicou

Após o push, abra ou atualize a página do repositório no GitHub.

Confira o proprietário e o nome do repositório no topo da página.
No seletor de branches, acima da lista de arquivos, selecione explicitamente a branch que você enviou. Não presuma que ela já está selecionada.
Confira os arquivos esperados e abra um deles para verificar seu conteúdo commitado.

Dica

Compare com a versão commitada

A lista mostra o conteúdo versionado da branch selecionada, não uma cópia de toda a sua pasta local.

Uma diferença esperada

Isso indica falha?

Você selecionou a branch enviada no GitHub. Uma frase acrescentada ao README local, mas ainda não commitada, não aparece no site. Isso, por si só, prova que o push falhou.

VerdadeiroFalso

Compare os históricos

Confira identificadores e mensagens

Com a branch enviada selecionada, clique no link do histórico de commits, acima da lista de arquivos, próximo ao resumo do último commit.

No terminal, na mesma branch local que você publicou, consulte git log --oneline.

Compare o commit mais recente e os anteriores: identificadores e mensagens devem corresponder. Se os identificadores aparecerem abreviados com tamanhos diferentes, compare seus primeiros caracteres.

Dica

Quatro evidências juntas

Valide destino, branch, arquivos e commits. A mensagem de sucesso no terminal não substitui essa conferência no GitHub.

As evidências são suficientes?

Exemplo

Uma conferência com divergência

O destino está correto, a branch site está selecionada e os nomes dos arquivos são os esperados.

Histórico local da branch enviada, do mais recente ao mais antigo:

c82e4a1 Atualiza instruções
9bd70f2 Cria página inicial

Histórico na página carregada do GitHub:

9bd70f2 Cria página inicial

Qual é sua conclusão?

Já é possível confirmar que todo o histórico da branch foi publicado? Aponte a evidência que sustenta sua resposta.

Passo 6 de 6

Aplicar o fluxo e concluir a publicação

Organize o fluxo de primeira publicação e reúna evidências de que a branch foi publicada corretamente.

Reconstrua o fluxo

Da preparação à conferência

Ordene as etapas da primeira publicação de um projeto local que já possui commits.

Abrir o destino no GitHub, selecionar a branch enviada e conferir seus arquivos e commits.
Associar o destino com git remote add origin <URL-HTTPS> e conferir com git remote -v.
Criar o repositório no GitHub com proprietário, nome e visibilidade escolhidos, sem gerar README, licença ou .gitignore.
Publicar com git push -u origin <nome-da-branch>, usando o nome real da branch local.

Aplique no projeto de prática

Execute apenas o que falta

Use seu projeto de prática já versionado e sem dados sensíveis. Complete o fluxo organizado na tela anterior, substituindo os marcadores pela URL HTTPS e pelo nome real da branch, sem os sinais < e >. Não é necessário renomear a branch.

Se você já publicou durante o tutorial, não recrie o destino nem adicione origin novamente: reúna as evidências da publicação.

Atenção

Não avance com uma pendência

Se origin já existir, confira seu destino antes de prosseguir; não substitua uma associação diferente às cegas. Se houver erro no envio, revise as condições do fluxo. Não use envio forçado nem considere a publicação concluída.

Registre as evidências

O que confirma sua publicação?

Após a prática, registre:

O protocolo, proprietário e repositório de origin conferidos nas duas entradas de git remote -v.
A branch enviada e as confirmações de envio e acompanhamento vistas no terminal.
A branch selecionada no GitHub e um arquivo cujo conteúdo corresponde à versão commitada.
O identificador e a mensagem de um commit que você comparou no histórico local e no GitHub.

Conclua dizendo se alterações sem commit entraram na publicação. Não inclua senhas, tokens ou outras credenciais. Se algo falhou, registre a pendência.

Escreva pelo menos 80 caracteres (0/80).

Feche o ciclo

Resumo

A competência que você praticou

Preparar um destino vazio, associar origin e publicar a branch escolhida com acompanhamento.
Validar a publicação conferindo destino, branch, arquivos e commits no GitHub.
Distinguir o histórico publicado das alterações sem commit, que permanecem locais. O histórico local não é removido, e o acompanhamento não sincroniza mudanças automaticamente.