Todo desenvolvedor já passou por isso: você altera um arquivo, o sistema quebra e não lembra mais como estava antes. Ou salva projeto-final-v2-agora-vai.zip na área de trabalho. O Git resolve esses problemas guardando o histórico de cada alteração do seu código, e o GitHub permite hospedar esse histórico na nuvem, colaborar com outras pessoas e montar seu portfólio.
Este guia de Git e GitHub para iniciantes mostra, com prints reais do terminal, o caminho completo: instalar e configurar o Git, fazer o primeiro commit, comparar alterações, trabalhar com branches, fazer merge e publicar o projeto no GitHub.
Git e GitHub não são a mesma coisa
É a primeira confusão de quem começa, então vamos esclarecer logo:
- Git é um programa que roda no seu computador. Ele controla versões de arquivos e funciona totalmente offline. Foi criado em 2005 por Linus Torvalds para o desenvolvimento do kernel Linux.
- GitHub é um serviço na web que hospeda repositórios Git. Ele adiciona recursos de colaboração: pull requests, revisão de código, issues, automações (GitHub Actions) e páginas de projeto.
Existem alternativas ao GitHub, como GitLab e Bitbucket, e todas usam o mesmo Git por baixo. O que você aprender aqui vale para qualquer uma delas.
Os três estados de um arquivo no Git
Antes dos comandos, entenda o fluxo que o Git usa. Todo arquivo passa por três áreas:
| Área | O que é | Como o arquivo chega lá |
|---|---|---|
| Working directory | A pasta do projeto, onde você edita os arquivos | Editando normalmente |
| Staging area | Uma “sala de espera” com o que vai entrar no próximo commit | git add |
| Repositório | O histórico permanente de commits | git commit |
Pense no commit como uma fotografia do projeto. O git add escolhe quem vai aparecer na foto, e o git commit tira a foto e a guarda no álbum com uma legenda.
Passo 1: instalando o Git
- Windows: baixe o instalador em git-scm.com. Ele instala também o Git Bash, um terminal que aceita os mesmos comandos do Linux. As opções padrão do instalador atendem bem.
- macOS: rode
git --versionno Terminal. Se não estiver instalado, o sistema oferece instalar as Command Line Tools. Outra opção ébrew install git. - Linux (Ubuntu/Debian):
sudo apt install git.
Passo 2: configurando nome e e-mail
O Git registra o autor de cada commit. Configure isso uma única vez por computador:
git config --global user.name "Seu Nome"
git config --global user.email "seu-email@exemplo.com"
git config --global init.defaultBranch main
Use o mesmo e-mail cadastrado no GitHub, assim seus commits aparecem vinculados ao seu perfil. A terceira linha define main como nome da branch inicial, o padrão atual do GitHub.
Passo 3: criando um repositório com git init
Entre na pasta do projeto e transforme-a em um repositório:
mkdir meu-projeto
cd meu-projeto
git init
O comando cria uma pasta oculta .git, onde fica todo o histórico. Nunca apague essa pasta — sem ela, o histórico se perde.
Crie dois arquivos quaisquer (aqui, README.md e app.js) e rode o comando que você mais vai usar na vida:
git status
O git status diz exatamente o que está acontecendo: em qual branch você está, quais arquivos são novos (untracked), quais foram modificados e quais estão prontos para o commit. Na dúvida, rode git status.
Para adicionar os arquivos à staging area:
git add README.md app.js # arquivos específicos
git add . # tudo o que mudou na pasta
Passo 4: o primeiro commit
Com os arquivos na staging area, registre a versão:
git commit -m "Primeiro commit: README e app.js"
Agora altere o app.js, adicionando uma linha. Antes de commitar, veja exatamente o que mudou com git diff, e depois consulte o histórico com git log:
Detalhes que valem ouro:
- No
git diff, linhas com+foram adicionadas e linhas com-foram removidas. - O
git commit -am "mensagem"faz oadde ocommitde uma vez, mas só para arquivos já rastreados. Arquivos novos ainda precisam degit add. - Cada commit tem um identificador único (o hash, como
61fe324). Com ele você consegue voltar a qualquer versão.
Como escrever boas mensagens de commit
A mensagem é para o você do futuro e para seus colegas. Algumas regras simples:
- Use o imperativo e seja específico: “Adiciona validação de CPF no cadastro” em vez de “ajustes”.
- Um commit por mudança lógica. Não misture correção de bug com refatoração.
- Muitas equipes seguem o padrão Conventional Commits:
feat: adiciona login,fix: corrige cálculo de frete,docs: atualiza README.
Passo 5: trabalhando com branches
Uma branch é uma linha paralela de desenvolvimento. Você cria uma branch para cada funcionalidade ou correção, trabalha nela sem afetar a main e, quando estiver pronto, junta as alterações (merge).
git switch -c feature/login # cria a branch e muda para ela
# ... edita arquivos, git add, git commit ...
git switch main # volta para a main
git merge feature/login # traz as alterações da feature
Nesse exemplo o merge foi do tipo fast-forward: como a main não tinha recebido commits novos enquanto trabalhávamos na feature, o Git apenas “avançou o ponteiro”. Quando as duas branches têm commits diferentes, o Git cria um commit de merge — e, se as mesmas linhas foram alteradas nos dois lados, acontece um conflito.
Resolvendo conflitos de merge
Conflitos assustam, mas são simples. O Git marca o trecho no arquivo assim:
<<<<<<< HEAD
console.log("Versão da main");
=======
console.log("Versão da feature");
>>>>>>> feature/login
Edite o arquivo deixando apenas o conteúdo correto (removendo as marcações), depois rode git add arquivo e git commit. Editores como o VS Code mostram botões para aceitar uma versão, a outra ou ambas.
Passo 6: publicando o projeto no GitHub
- Crie uma conta em github.com (é gratuito, inclusive para repositórios privados).
- Clique em New repository, dê um nome (por exemplo
meu-projeto) e não marque a opção de criar README, já que o seu projeto já tem um. - Copie a URL do repositório e conecte-a ao seu projeto local:
git remote add origin https://github.com/seu-usuario/meu-projeto.git
git push -u origin main
O origin é apenas um apelido para a URL remota. O -u (ou --set-upstream) liga a branch main local à main do GitHub, e a partir daí basta digitar git push e git pull.
Autenticação no GitHub
O GitHub não aceita mais a senha da conta no terminal. Você tem três opções:
- GitHub CLI: instale o
ghe rodegh auth login. É o caminho mais simples. - Personal Access Token (PAT): gere em Settings → Developer settings → Personal access tokens e use no lugar da senha quando o Git pedir.
- Chave SSH: gere com
ssh-keygen -t ed25519 -C "seu-email", cadastre a chave pública no GitHub e use a URL no formatogit@github.com:usuario/repo.git.
O arquivo .gitignore
Nem tudo deve ir para o repositório. Dependências, arquivos gerados e, principalmente, credenciais ficam de fora. Crie um .gitignore na raiz:
# Dependências
node_modules/
vendor/
# Configurações locais e segredos
.env
# Sistema e editores
.DS_Store
.vscode/
Um token de API publicado por engano no GitHub pode ser encontrado por robôs em minutos. Veja como organizar credenciais no tutorial Variáveis de ambiente e arquivo .env.
Comandos Git que você vai usar todo dia
git status # o que mudou?
git add . # prepara tudo para o commit
git commit -m "mensagem" # registra a versão
git log --oneline # histórico resumido
git diff # o que mudou e ainda não foi para o stage
git pull # baixa e integra as novidades do remoto
git push # envia seus commits
git switch nome-da-branch # muda de branch
git clone URL # baixa um repositório existente
git restore arquivo # descarta alterações não commitadas de um arquivo
Erros comuns de quem está começando com Git
“fatal: not a git repository” — você está fora da pasta do projeto ou esqueceu o git init. Confira com pwd.
“Author identity unknown” — faltou configurar user.name e user.email.
“rejected … (fetch first)” no push — o repositório remoto tem commits que você não tem localmente. Rode git pull antes de git push.
“Support for password authentication was removed” — use o GitHub CLI, um token de acesso pessoal ou SSH, como explicado acima.
Commitei um arquivo com senha — remover o arquivo em um novo commit não basta, porque ele continua no histórico. Considere o segredo comprometido: revogue e gere um novo imediatamente.
Perguntas frequentes sobre Git e GitHub
Git é difícil de aprender?
O básico (status, add, commit, push, pull e branches) se aprende em uma tarde e cobre 90% do uso diário. Recursos avançados como rebase interativo e cherry-pick podem esperar.
Preciso usar o terminal?
Não obrigatoriamente: VS Code, GitHub Desktop e outras ferramentas têm interfaces gráficas. Mas aprender os comandos ajuda a entender o que está acontecendo e a resolver problemas quando a interface não resolve.
Qual a diferença entre git pull e git fetch?
O git fetch apenas baixa as novidades do remoto, sem alterar seus arquivos. O git pull faz o fetch e em seguida integra as mudanças na sua branch atual.
Repositório privado no GitHub é pago?
Não. Repositórios privados são gratuitos para contas pessoais, com colaboradores ilimitados. Planos pagos adicionam recursos para empresas e mais minutos de automação.
Conclusão
Com este guia de Git e GitHub para iniciantes, você configurou o Git, criou um repositório, fez commits, comparou alterações, usou branches e merge e publicou o projeto no GitHub. A partir de agora, cada tutorial da nossa série pode (e deve) virar um repositório no seu perfil — é a melhor forma de montar um portfólio.
Continue com Minha primeira API em Node.js com Express e versione o projeto desde o primeiro arquivo. E, quando sua aplicação começar a integrar serviços externos, como SMS, WhatsApp e consultas de CEP e CNPJ da APIBrasil, lembre-se: tokens ficam no .env, nunca no Git.
