Idioma
Categoria
Pesquisar

Como subir um novo projeto no GitHub usando Linux e SSH sem senha

Configure Git no repositório local, sincronize com o GitHub, aprenda sobre versionamento e use tags e releases para organizar versões do seu projeto e disponibilizá-lo para download

Índice

Como subir um novo projeto no GitHub usando Linux e SSH sem senha
Em Terminal Por Rudi Drusian Lange
Publicado em
Última atualização

Introdução

Este artigo é um guia passo a passo para ajudar iniciantes a configurar o Git em um novo projeto e sincronizá-lo com o GitHub. Além disso, você aprenderá como usar chaves SSH para evitar a necessidade de digitar senhas repetidamente. No final, também abordaremos como criar tags e disponibilizar releases para seu projeto.

Pré-requisitos

Criar uma Conta no GitHub e Configurar um Novo Repositório

Antes de começarmos, você precisará ter uma conta no GitHub e criar um repositório para armazenar seu projeto. Este processo é intuitivo e conta com assistência direta do próprio GitHub durante as etapas. Certifique-se de seguir os prompts na plataforma para concluir esta configuração inicial.

Ambiente de Desenvolvimento

Os comandos apresentados neste artigo foram testados no Linux Slackware 15.0, utilizando as ferramentas nativas Git (versão 2.46.3) e OpenSSH (versão 9.9p2) . Os comandos são genéricos e devem funcionar em qualquer distribuição Linux que tenha o Git e o SSH instalados.

Iniciando o Git no Projeto Local

Passo 1: Configurando o Git para Usar main Como Branch Padrão

Muitas plataformas modernas (como o GitHub, GitLab e Bitbucket) adotam o nome main como o branch padrão. Para garantir que novos repositórios usem automaticamente main como branch principal, é necessário ajustar a configuração global do Git. Execute o seguinte comando:

$ bash

git config --global init.defaultBranch main

Com essa configuração, o comando git init criará automaticamente o branch main, eliminando a necessidade de renomeá-lo manualmente.

Passo 2: Inicializando o Repositório

Considerando um projeto denominado telazul, serão apresentados a seguir os passos necessários para configurar o Git neste diretório e preparar o projeto para sincronização com o GitHub.

$ bash

# Entra no diretório do projeto
cd telazul/  

# Inicializa o repositório Git
git init

O git init é usado somente uma vez para criar a estrutura necessária para o repositório. Para verificar o nome do branch atual e renomeá-lo se necessário, são usados os comandos a seguir:

$ bash

# Verifica o nome do branch atual
git branch

# Renomeia o branch master para main
git branch -m master main

Passo 3: Adicionando Arquivos ao Repositório Local

Adicione todos os arquivos e diretórios ao repositório e salve as alterações com uma mensagem informativa:

$ bash

# Adiciona todos os arquivos da pasta atual recursivamente
git add .  

# Salva as alterações permanentemente com uma mensagem descritiva
git commit -m "Commit inicial: adicionando arquivos do projeto"

O comando git add . adiciona todos os arquivos modificados ou novos ao índice, enquanto o git commit cria uma fotografia do estado atual dos arquivos, salvando as alterações permanentemente. Como é possível recuperar o estado exato deste commit no futuro, a mensagem associada deve ser clara e descritiva para facilitar a identificação das mudanças realizadas.

Os passos acima configuram o Git no projeto local. Eles são independentes da integração com o GitHub e podem ser usados em qualquer fluxo de trabalho Git.

Configurando acesso SSH ao GitHub

O projeto será transferido usando SSH, um protocolo seguro e prático para transferir arquivos pela internet. Para isso, é necessário configurar chaves SSH que funcionarão como credenciais, permitindo o login no GitHub sem a necessidade de digitar uma senha.

$ bash

# Cria as chaves usando o algoritmo ed25519
ssh-keygen -t ed25519

Quando perguntado pressione Enter ↲ para manter a localização padrão ~/.ssh/ e para usar uma senha em branco. Se você já possui chaves SSH compatíveis com o GitHub (como id_rsa ou id_ed25519), não é necessário criar novas chaves.

Adicionando a Chave Pública ao GitHub

Para transferir a chave pública entre computadores Linux, você pode usar o comando ssh-copy-id. No entanto, no GitHub, é necessário copiar e colar a chave manualmente na interface gráfica da plataforma.

A chave pública está armazenada no arquivo que termina com .pub. Para exibir seu conteúdo, use o comando abaixo (substitua seu-usuário pelo nome do seu usuário no sistema):

$ bash

cat /home/seu-usuário/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEDbDtQNhBvGd292FgKDRgqhiXGiLHo32ZYXCSS017d5 seu-usuário@nome-do-host

Copie a linha inteira iniciada com ssh-ed25519 (chave pública) e:

  1. Acesse o GitHub e clique  clique no menu com seu avatar no canto superior direito. 
  2. Navegue até Settings > SSH and GPG Keys.
  3. Clique em New SSH Key,
  4. Preencha o campo Title com um nome descritivo para a chave. (ex.: "Chave SSH do meu notebook").
  5. Cole a chave pública no campo Key.
  6. Clique em Add SSH Key para salvar.

Após a configuração, a chave aparecerá listada na página de chaves SSH, conforme ilustrado abaixo:

github-ssh-authentication-keys

Subindo o Projeto no GitHub

Para conectar o repositório local ao repositório remoto no GitHub, use o comando abaixo. Ele adiciona o apelido origin ao repositório remoto, permitindo referenciá-lo facilmente em operações futuras.

$ bash

git remote add origin git@github.com:seu-usuário/seu-repositório.git

Certifique-se de executar o comando acima dentro da pasta do projeto e substituir seu-usuário pelo seu nome de usuário no GitHub e seu-repositório pelo nome do repositório criado na plataforma.

Agora, envie o projeto para o repositório remoto com o seguinte comando:

Atenção! O uso do parâmetro -f apagará todos os arquivos existentes no repositório remoto. Utilize-o apenas quando necessário, como no caso de um repositório recém-criado no GitHub.

$ bash

git push -u -f origin main
  • O parâmetro -u (ou --set-upstream) define origin como a referência padrão para o branch main. Após essa configuração, você poderá usar os comandos git push e git pull sem precisar especificar o repositório remoto ou o branch.
  • O parâmetro -f (ou --force) força a atualização do repositório remoto, sobrescrevendo qualquer conteúdo existente. Esse parâmetro é útil ao iniciar um novo projeto quando o repositório remoto contém arquivos padrão (como LICENSE ou README.md) que impedem o push inicial.

Sincronizando Alterações do Repositório Remoto

Entre no site do GitHub e crie o arquivo README com algum conteúdo. Para sincronizar essas alterações no repositório remoto com o repositório local, execute o seguinte comando a partir da pasta do projeto:

$ bash

git pull

O comando git pull traz todos os commits mais recentes do branch remoto e aplica-os ao branch local.

Como mencionado anteriormente, ao subir o projeto com o comando git push usando o parâmetro -u, o repositório no GitHub é definido como referência padrão. Isso elimina a necessidade de especificar o nome do repositório remoto (origin) nos comandos subsequentes.

Após executar o comando, verifique que o arquivo README criado remotamente agora está presente na pasta local do projeto.

Atualizando Arquivos Localmente

Edite o arquivo README no repositório local, adicionando uma nova linha. Em seguida, registre as alterações e envie-as para o repositório remoto com os seguintes comandos:

$ bash

git commit -a -m "Atualização do arquivo README"

git push

O parâmetro -a prepara automaticamente todos os arquivos modificados ou apagados no repositório local. No entanto, ele não inclui novos arquivos (arquivos que ainda não foram rastreados pelo Git). Para incluir novos arquivos, use o comando git add.

O parâmetro -m permite adicionar uma mensagem descritiva ao commit.

O comando git push atualiza o repositório remoto no GitHub com as alterações recentes feitas na pasta local do projeto.

Versionamento Semântico

Antes de entrar no assunto tags e releases, é importante entender brevemente a numeração utilizada nas versões de software. O Versionamento Semântico (ou SemVer ) é uma convenção amplamente adotada para nomear versões de software, facilitando a comunicação sobre mudanças e garantindo compatibilidade.

Ele segue o formato:

MAJOR.MINOR.PATCH
  • MAJOR : Incrementado quando há mudanças incompatíveis com versões anteriores (ex.: alterações que quebram APIs ou funcionalidades).
  • MINOR : Incrementado quando são adicionadas funcionalidades retrocompatíveis (sem quebrar o funcionamento atual).
  • PATCH : Incrementado para correções de bugs ou pequenas melhorias que não alteram funcionalidades existentes.

Exemplos

  • 1.0.0: Primeira versão estável do software.
  • 1.1.0: Adição de novas funcionalidades sem quebrar a compatibilidade.
  • 1.1.1: Correção de bugs na versão 1.1.0.
  • 2.0.0: Alterações incompatíveis com a versão 1.x.x.

É uma prática recomendada para projetos que precisam comunicar claramente o estado de desenvolvimento e as mudanças introduzidas em cada versão.

Nomeando Versões com Tags

Uma tag é uma referência estática que aponta para um commit específico no histórico do Git. Diferente dos branches, que podem avançar e mudar ao longo do tempo, as tags são fixas e não mudam depois de criadas. Isso as torna ideais para marcar eventos importantes, como lançamento de versões que podem ser disponibilizadas para os usuários baixarem.

$ bash

git tag v1.0.0

Esse comando cria uma tag chamada v1.0.0, gerando uma versão definitiva do projeto contendo todos os arquivos e diretórios no estado em que estavam no momento do último commit executado.

O prefixo v (de "version") é uma convenção adotada para identificar tags de versão, facilitando sua distinção no histórico do Git, especialmente em meio a outras marcações (ex.: beta-test).

Para nomear um commit específico, diferente do atual, com uma tag use:

$ bash

git tag nome-da-tag hash-do-commit

Para descobrir o hash-do-commit consulte este tópico.

Os comandos anteriores criam as chamadas tags simples (ou leves). Outra opção são as tags anotadas, que são mais detalhadas e incluem metadados, como mensagem, autor e data. Elas são recomendadas para marcar versões importantes.

Para criar uma tag anotada, use o parâmetro -a:

$ bash

git tag -a v1.0 -m "Versão 1.0 estável"

Outros comandos úteis para gerenciar tags:

$ bash

# Lista todas as tags
git tag

# Lista todas as tags e seus commits
git log --oneline --decorate

# Visualiza detalhes sobre uma tag específica
git show nome-da-tag

Enviando Tags para o Repositório Remoto

Por padrão, as tags não são enviadas automaticamente para o repositório remoto ao usar o comando git push. Para enviar tags ao repositório remoto, use os seguintes comandos:

$ bash

# Envia uma tag específica
git push origin nome-da-tag

# Envia todas as tags de uma vez
git push origin --tags

Exemplo Prático

Suponha que você tenha acabado de concluir a versão 1.0 do seu projeto. Você pode marcar esse momento com uma tag anotada e enviá-la para o repositório remoto seguindo estes passos:

$ bash

# Cria a tag localmente
git tag -a v1.0 -m "Versão 1.0 estável"

# Envia a tag para o repositório remoto
git push origin v1.0

Removendo Tags

Tags no Git são referências imutáveis por design, o que significa que, uma vez criadas, elas sempre apontam para o commit ao qual foram atribuídas. No entanto, é possível removê-las.

Para remover uma tag local:

$ bash

git tag -d nome-da-tag

Para remover uma tag remota:

$ bash

git push origin --delete nome-da-tag

Esse comando removerá a tag no GiHub.

Atualizando Tags

Tags no Git não podem ser atualizadas diretamente. No entanto, é possível simular uma atualização removendo a tag existente e criando uma nova com o mesmo nome. Para isso, siga os passos abaixo:

$ bash

# Remove a tag local
git tag -d nome-da-tag

# Remove a tag remota
git push origin --delete nome-da-tag

# Cria a nova tag com o mesmo nome
git tag -a nome-da-tag -m "Nova mensagem da tag"

# Envie a nova tag para o repositório remoto
git push origin nome-da-tag

Atenção! Boas Práticas ao "Atualizar" Tags

Embora seja tecnicamente possível remover e recriar tags com o mesmo nome, essa prática pode causar confusão, especialmente se a tag original já estiver sendo usada por outras pessoas. Alterar uma tag após ela ter sido compartilhada pode levar a inconsistências no histórico do projeto.

Evite alterar tags já publicadas: Se a tag já foi compartilhada com outros desenvolvedores ou utilizada em lançamentos oficiais, prefira criar uma nova tag com um nome diferente (por exemplo, v1.0.1 em vez de reutilizar v1.0).

Criando uma Nova Release no GitHub

Comece criando uma tag local para indicar a versão do seu projeto e envie-a para o repositório remoto no GitHub:

$ bash

# Cria a tag localmente
git tag -a v1.0.0 -m "Versão 1.0.0 estável"

# Envia a tag para o repositório remoto
git push origin v1.0.0

No GitHub:

  1. Acesse a página de releases.
    • https://github.com/seu-usuário/seu-repositório/releases
  2. Clique em Create a new release.
  3. Preencha os detalhes da release:
    • Chose a tag: Selecione a tag que você criou (ex: v1.0.0) ou crie uma nova diretamente nesta tela. Neste exemplo a tag está sendo criada localmente e transferida ao repositório remoto, no entanto o processo reverso também é válido.
    • Release Title: Forneça um título descritivo para a release (por exemplo, v1.0.0 - Versão Estável).
    • Describe this release: Adicione uma descrição detalhada da release. Inclua informações como: o que foi adicionado, corrigido ou alterado, links para documentação, recursos relacionados etc.
    • Set as a pre-release : Marque esta opção se a versão for beta ou experimental. Caso contrário, mantenha desmarcada.
  4. Publique clicando em Publish release.

Após publicar a release, o GitHub disponibiliza automaticamente os arquivos associados ao commit marcado pela tag. Você pode baixá-los como um arquivo .zip ou .tar.gz.

Conclusão

Este artigo foi escrito para ser um guia prático, no qual pessoas possam consultar os passos necessários para criar seus primeiros projetos e disponibilizá-los para download no GitHub. Se você conseguiu configurar seu repositório, criar tags, releases e compartilhar seu trabalho com o mundo, ele cumpriu seu propósito.

Continue explorando o Git e o GitHub, e aproveite todas as possibilidades que essas ferramentas oferecem para organizar, compartilhar e colaborar em seus projetos.

Referências

Mural do site

Parte do conteúdo deste site, incluindo textos, imagens, gráficos e outros materiais, pode ser gerado ou aprimorado por ferramentas de inteligência artificial (IA). Para mais detalhes sobre o uso de IA, consulte nosso Termo de Uso.

Anúncio
Índice
Anúncio