Tutorial Git: instalar e configurar o Git em Windows, macOS e Linux

Este capítulo instala o Git, acerta os três parâmetros sem os quais o teu primeiro commit será recusado e trata da autenticação no GitHub ou no GitLab. Conta com uns quinze minutos, chave SSH incluída.

Se chegaste diretamente aqui, a diferença entre o Git e o GitHub e o detalhe do percurso estão explicados na introdução do tutorial.

Instalar o Git

O Git já está provavelmente na tua máquina se usas macOS ou Linux. Verifica antes de instalares o que quer que seja:

git --version

Se o comando devolver um número de versão, o Git está instalado e podes passar à configuração. Se responder que o comando não existe, segue a secção correspondente ao teu sistema.

Windows

O mais simples é o gestor de pacotes integrado no Windows:

winget install --id Git.Git -e --source winget

Em alternativa, descarrega o instalador em git-scm.com/install/windows e deixa as opções predefinidas. A última versão publicada à data desta verificação é o Git for Windows 2.55.0(5), de 20 de agosto de 2026. A instalação traz o Git Bash, um terminal que reproduz o ambiente Unix. Usa-o em vez da linha de comandos do Windows: todos os comandos deste tutorial funcionam lá tal como estão.

macOS

O Git vem com as ferramentas de linha de comandos do Xcode. A primeira invocação do git propõe instalá-las, ou podes forçar a instalação:

xcode-select --install

Esta versão é fiável, mas costuma estar uns meses atrasada face à versão oficial. Para te manteres atualizado, passa pelo Homebrew:

brew install git

Linux

Usa o gestor de pacotes da tua distribuição.

# Debian, Ubuntu e derivadas
sudo apt update && sudo apt install git

# Fedora, RHEL, Rocky
sudo dnf install git

# Arch
sudo pacman -S git

# Alpine
sudo apk add git

A versão instalada depende da sua distribuição, e a diferença é por vezes grande. As versões registadas a 7 de setembro de 2026 são dadas na secção « Resultado medido » no fim deste capítulo. O Ubuntu 24.04 fornece o Git 2.43, lançado no fim de 2023: é largamente suficiente para tudo o que este tutorial faz, já que os comandos mais recentes que usamos datam do Git 2.23.

Declarares quem és: nome e endereço de e-mail

O Git inscreve o autor de cada commit no histórico. Enquanto não lhe disseres quem és, recusa-se a registar o que quer que seja:

Author identity unknown

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'root@23d1d26b6831.(none)')

Define então os dois valores antes de mais:

git config --global user.name "Damien Flandrin"
git config --global user.email "dam@example.com"

A opção --global escreve no teu ficheiro pessoal e vale para todos os teus projetos. Sem ela, a definição só abrange o repositório atual, o que dá jeito quando usas um endereço profissional em certos projetos e um endereço pessoal noutros.

Usa um endereço que aceites tornar público: aparece no histórico, e o histórico é distribuído a toda a gente que clona o projeto. O GitHub propõe um endereço de substituição em @users.noreply.github.com se preferires não expor o teu.

Escolher o nome da branch predefinida

É o ponto sobre o qual circula mais informação falsa. Lê-se muitas vezes que o Git passou a criar uma branch main. Não é verdade. Eis o que produz o git init com o Git 2.55, a versão atual em setembro de 2026:

hint: Using 'master' as the name for the initial branch. This default branch name
hint: will change to "main" in Git 3.0. To configure the initial branch name
hint: to use in all of your new repositories, which will suppress this warning,
hint: call:
hint:
hint: 	git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: 	git branch -m <name>
hint:
hint: Disable this message with "git config set advice.defaultBranchName false"
Initialized empty Git repository in /root/a1/.git/

A branch chama-se mesmo master, e o próprio Git anuncia que o valor por omissão passará a main a partir da versão 3.0. O que mudou foram os alojamentos: o GitHub cria os repositórios novos com uma branch main desde outubro de 2020, o GitLab desde a versão 14. Daí o desfasamento permanente entre o que faz a tua máquina e o que faz o servidor.

Resolve a questão de uma vez por todas:

git config --global init.defaultBranch main

A mensagem desaparece e os repositórios criados a seguir arrancam em main. Atenção: esta definição só se aplica aos repositórios novos. Para um repositório que já existe e cuja branch se chama master:

git branch -m master main

Verificar a configuração

Três comandos chegam para saber em que ponto estás:

git config --global --list                # o que está definido
git config --global --list --show-origin  # e em que ficheiro
git config --global --edit                # abrir o ficheiro

A configuração pessoal é um simples ficheiro de texto, ~/.gitconfig, que podes ler e alterar diretamente:

[user]
	name = Damien Flandrin
	email = dam@example.com
[init]
	defaultBranch = main

Há mais duas definições que vale a pena arrumar já. O editor que o Git usa para as mensagens de commit, sem o qual vais mais cedo ou mais tarde cair no Vim sem saber sair de lá:

git config --global core.editor "code --wait"   # Visual Studio Code
git config --global core.editor "nano"          # ou qualquer editor de terminal

E o comportamento do git pull, que detalharemos no capítulo sobre as branches:

git config --global pull.rebase true

Autenticares-te no GitHub ou no GitLab

Impõe-se aqui um esclarecimento de vocabulário, porque faz perder muito tempo a quem começa. A tua palavra-passe do GitHub já não serve de nada para o Git. O GitHub deixou de aceitar as palavras-passe de conta nas operações Git a 13 de agosto de 2021. Eis o que o servidor responde se tentares mesmo assim:

Cloning into 'depot-prive'...
remote: Invalid username or token. Password authentication is not supported for Git operations.
fatal: Authentication failed for 'https://github.com/damienflandrin/depot-prive.git/'

Restam dois métodos válidos: a chave SSH ou o token de acesso pessoal. A chave SSH leva cinco minutos a montar e nunca mais volta a ser pedida. É a que recomendamos.

Criar uma chave SSH

ssh-keygen -t ed25519 -C "dam@example.com"

Aceita o caminho proposto por omissão. A frase-passe é facultativa, mas recomendada: protege a chave se a tua máquina for comprometida.

Generating public/private ed25519 key pair.
Created directory '/root/.ssh'.
Your identification has been saved in /root/.ssh/id_ed25519
Your public key has been saved in /root/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:s5YjDRbNgv3/o8SvEFh4A6hzpWddSsquX0l0k4aUptw dam@example.com

Foram criados dois ficheiros. O id_ed25519 é a chave privada: nunca sai da tua máquina, não se copia para lado nenhum, não se cola em formulário nenhum. O id_ed25519.pub é a chave pública, aquela que entregas ao servidor.

Mostra a chave pública e copia a linha inteira:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINjiBkboRdOPXk2UWn3UUMSv2qr8G9cGvzKsTd+ZyYCa dam@example.com

Cola-a depois em Settings > SSH and GPG keys > New SSH key no GitHub, ou em Preferências > Chaves SSH no GitLab.

Verificar que a chave funciona

ssh -T git@github.com

A primeira ligação pede-te para confirmares a impressão digital do servidor. A do GitHub para as chaves Ed25519 é SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU, compara-a com a que o GitHub publica antes de responderes yes. Se estiver tudo em ordem, o GitHub responde com uma mensagem de boas-vindas que menciona o teu nome de utilizador e precisa que o acesso à shell não é permitido, o que é normal. Se obtiveres antes:

git@github.com: Permission denied (publickey).

é porque a chave pública não ficou registada na tua conta, ou porque colaste a chave privada por engano.

A alternativa: o token de acesso pessoal

Se o SSH estiver bloqueado na tua rede, ou num script de integração contínua, usa um token de acesso pessoal. No GitHub, cria-o em Settings > Developer settings > Personal access tokens, preferindo os tokens de âmbito restrito (fine-grained), que limitam o acesso a um repositório concreto e expiram sozinhos. No GitLab, o equivalente está em Preferências > Tokens de acesso.

O token usa-se no lugar da palavra-passe quando o Git a pede. Para não o voltares a escrever a cada comando, ativa um gestor de credenciais:

git config --global credential.helper store    # simples, mas o token fica escrito em claro
git config --global credential.helper osxkeychain  # macOS, guardado no porta-chaves

No Windows, o Git Credential Manager vem instalado e ativado por omissão com o Git for Windows.

Trata um token exatamente como uma palavra-passe: não vai para um repositório, nem para um ficheiro de configuração versionado, nem para um URL que partilhes.

O teu posto está pronto. O capítulo seguinte cria um repositório no GitHub ou no GitLab e liga-o a uma pasta da tua máquina.

Resultado medido

Versão do Git instalada pelo gestor de pacotes na imagem oficial de cada distribuição, registada a 7 de setembro de 2026:

Todas servem: o comando mais recente usado neste tutorial, git switch, data do Git 2.23.