Skip to content

Tudo para WordPress, desenvolvimento web — e não só

🚀 Git para principiantes: primeiro guia para trabalhar com o GitHub

🚀 Git para principiantes: primeiro guia para trabalhar com o GitHub

Escreveu código, mas tem medo de estragar a versão que funciona. Ou trabalha em equipa e perde o rasto de quem fez alterações e quando. Ou talvez só queira reverter uma experiência falhada com um único comando.

Tudo isto é resolvido pelo Git, um sistema de controlo de versões do qual nenhum projeto moderno pode prescindir. Mas a barreira de entrada assusta muita gente: terminal, chaves SSH, branches, pull requests.

Na realidade, o fluxo de trabalho básico aprende-se numa hora. Este guia é exatamente sobre isso: da instalação ao primeiro push, sem palha nem teoria desnecessária.

💡 Visão geral rápida:

  • Instale o Git para o seu SO e defina o seu nome de utilizador com um comando
  • Gere uma chave SSH Ed25519 e associe-a à sua conta do GitHub
  • Crie um repositório, ligue-o a uma pasta local e faça o seu primeiro push
  • Clone um repositório existente via HTTPS ou SSH para trabalhar localmente
  • Domine os comandos modernos git switch e git restore em vez do git checkout

1. Instalar o Git

O Git funciona em Windows, macOS e Linux. A forma mais fiável é descarregar o instalador do site oficial git-scm.com.

Para Windows, descarregue a versão de 64 bits. Durante a instalação, o assistente oferecerá a escolha de um editor padrão, a estratégia de tratamento de fins de linha e o terminal. Para um principiante, os valores predefinidos funcionam bem, exceto o editor: em vez do Vim, é mais conveniente escolher o Nano ou o VS Code.

Um guia detalhado para instalar o Git no Windows (com capturas de ecrã de cada passo do assistente) já está disponível no nosso blogue: como instalar o Git no Windows.

Verifique se o Git foi instalado corretamente:

1git --version

Se o terminal mostrar uma versão (por exemplo, git version 2.48.0), a instalação foi bem-sucedida.

2. Configuração inicial do Git

Antes do seu primeiro commit, o Git precisa de uma apresentação. O nome e o email aparecerão no histórico de cada alteração, permitindo que os colegas percebam quem fez a edição.

1git config --global user.name "Your Name"
2git config --global user.email "[email protected]"

O sinalizador --global grava as definições globalmente, sendo aplicadas a todos os repositórios na máquina. Se um projeto específico precisar de dados diferentes, repita o comando sem --global dentro da pasta do projeto.

Mais dois sinalizadores úteis:

1git config --global core.editor "code --wait" # editor for commit messages
2git config --global init.defaultBranch main # default branch is main, not master

Desde 2020, o GitHub cria repositórios com um branch main em vez de master. A linha init.defaultBranch main sincroniza a sua instalação local com esta norma, evitando confusões futuras.

Verifique tudo de uma vez:

1git config --list

3. Chave SSH e ligação ao GitHub

O GitHub desativou o suporte por palavra-passe para operações Git em 2021. O padrão atual são as chaves SSH, e o algoritmo é o Ed25519 (mais compacto e seguro do que o RSA obsoleto).

Gere uma chave:

1ssh-keygen -t ed25519 -C "[email protected]"

Prima Enter três vezes: uma frase-passe vazia é aceitável para desenvolvimento local. O terminal mostrará a impressão digital e o caminho para a chave:

Resultado do comando ssh-keygen com chave Ed25519 no terminal

Agora copie a chave pública para a área de transferência. O comando depende do sistema operativo:

macOS:

1pbcopy < ~/.ssh/id_ed25519.pub

Linux (Ubuntu):

1cat ~/.ssh/id_ed25519.pub

Windows (Git Bash):

1clip < ~/.ssh/id_ed25519.pub

Só falta adicionar a chave ao GitHub. Entre na sua conta, clique no seu avatar no canto superior direito e selecione Settings:

Menu de definições da conta do GitHub com item Settings

Na barra lateral, vá ao separador SSH and GPG keys:

Página de gestão de chaves SSH e GPG nas definições do GitHub

Clique no botão verde New SSH Key. No campo Title, dê um nome significativo à chave (por exemplo, «Asus Laptop»), no campo Key cole o conteúdo da área de transferência e clique em Add SSH Key.

Verifique a ligação:

Uma resposta Hi username! You've successfully authenticated... significa que está tudo configurado.

4. Criar um repositório e primeira sincronização

Em github.com/new crie um novo repositório: defina um nome, deixe Público ou escolha Privado, NÃO marque "Add a README file" (caso contrário, haverá um conflito no primeiro push).

Agora no terminal, navegue até à pasta do projeto e execute a sequência:

1git init # Git initialization in folder
2git add . # index all files
3git commit -m "First commit" # fix state

Associe a pasta local ao repositório remoto e envie as alterações:

1git remote add origin [email protected]:yourname/yourproject.git
2git push -u origin main

A flag -u memoriza a ligação "branch local → remoto". Da próxima vez, um simples git push será suficiente.

Não se esqueça do .gitignore, que lista os ficheiros que não devem ir parar ao repositório (logs, ficheiros temporários do IDE, pastas de dependências como node_modules/). Pode encontrar modelos prontos para qualquer stack em gitignore.io.

5. Clonar um repositório

Clonar é descarregar o repositório de outra pessoa (ou o seu próprio, mas a partir do GitHub) para uma máquina local com todo o histórico de alterações.

Na página do repositório, clique no botão verde Code:

Botão Code para clonar repositório no GitHub

Abrirá uma janela com três opções. Escolha SSH (se configurou uma chave no passo 3) ou HTTPS:

Janela de clonagem com separadores HTTPS e SSH no GitHub

Copie o URL e execute no terminal:

1git clone [email protected]:username/repository.git

O Git criará uma pasta com o nome do repositório e descarregará todos os ficheiros mais o histórico. Após a clonagem, pode começar a trabalhar de imediato.

Para a navegação diária entre branches, utilize os comandos modernos:

1git switch feature-branch # switch to existing branch
2git switch -c new-feature # create new branch and switch
3git restore file.txt # roll back changes in file

Estes substituíram o sobrecarregado git checkout no Git 2.23 e tornaram-se desde então o padrão. O git checkout não desapareceu, mas o switch e o restore são mais seguros e intuitivos.

Se preferir uma interface gráfica, o GitHub Desktop oferece uma gestão visual de clonagens, commits e branches sem o terminal.

Vídeo: curso completo de Git e GitHub em 2 horas

Para consolidar a matéria, veja um tutorial em vídeo abrangente em inglês, desde a instalação até cenários avançados de colaboração em equipa:

⁉️🤔 Perguntas frequentes

Qual é a diferença entre o Git e o GitHub?

O Git é um programa de controlo de versões que corre no seu computador. O GitHub é um serviço web que armazena repositórios Git na nuvem e adiciona ferramentas de colaboração: pull requests, revisão de código, issues. As alternativas são o GitLab e o Bitbucket. O Git pode funcionar perfeitamente sem o GitHub, mas o GitHub não pode existir sem o Git.

Preciso de aprender a linha de comandos se existir o GitHub Desktop?

O GitHub Desktop cobre a maioria das tarefas do dia a dia, mas o terminal dá-lhe controlo total. Comandos como git rebase, git stash e git cherry-pick nem sempre são óbvios na interface gráfica. Os cenários de CI/CD, servidores e DevOps só funcionam através da CLI. O nosso conselho: comece com o Desktop e aprenda a linha de comandos em paralelo, 2 a 3 comandos de cada vez.

Posso renomear o ramo master para main num projeto existente?

Sim, e esta é uma prática padrão. Execute: git branch -m master main, depois git push -u origin main e git push origin --delete master. Depois disso, nas definições do repositório no GitHub, altere o ramo predefinido para main.

O que fazer se o Git rejeitar um push com o erro "failed to push some refs"?

Quase sempre, o motivo é que o repositório remoto tem commits que não tem localmente. Primeiro faça git pull --rebase origin main, resolva conflitos se existirem e depois repita git push. A flag --rebase coloca os seus commits no topo dos remotos, mantendo o histórico linear.

Como desfazer o último commit que ainda não foi enviado para o GitHub?

git reset --soft HEAD~1: o commit desaparecerá, mas as alterações permanecerão no índice (staged). Pode corrigir e voltar a fazer commit. Se as alterações não forem necessárias de todo, aplique git reset --hard HEAD~1, mas tenha cuidado: o reset hard descarta ficheiros de forma irreversível.

O que se segue: o seu primeiro fluxo de trabalho

O panorama geral após este guia: o Git está instalado, a chave SSH está associada, o repositório está criado e sincronizado. Passou do zero para um ambiente pronto a usar.

A seguir, é a prática. Comece com pouco: faça três commits significativos num projeto de teste, abra um ramo com git switch -c, adicione um ficheiro e envie um pull request para integrar no main. Este ciclo exato (commit → ramo → PR → merge) repete-se diariamente em qualquer equipa.

E quando se sentir confortável, volte para tópicos avançados: git rebase, stash interativo, resolução de conflitos de merge e configuração de CI/CD com GitHub Actions.