Git

O que é Git?

Git é um sistema de controle de versão distribuído que rastreia alterações em arquivos ao longo do tempo. Ele permite que você salve snapshots do seu projeto a qualquer momento, compare versões, reverta erros e colabore com outras pessoas sem sobrescrever o trabalho uns dos outros.

Criado por Linus Torvalds em 2005 para gerenciar o kernel do Linux, o Git tornou-se o sistema de controle de versão mais utilizado no mundo. Esteja você construindo um projeto paralelo sozinho ou contribuindo para uma base de código com milhares de desenvolvedores, o Git é a ferramenta que torna isso possível.

A ideia central é simples: em vez de salvar uma única cópia do seu projeto, o Git salva uma série de commits — snapshots de cada arquivo rastreado em um momento específico. Você pode viajar no tempo, comparar versões, criar branches para testar novas ideias e fazer o merge do seu trabalho quando ele estiver pronto. Esse modelo escala de uma única pessoa para milhares.

Por que o controle de versão é importante

Sem controle de versão, a colaboração é um caos. Duas pessoas editando o mesmo arquivo significa que o trabalho de alguém será sobrescrito. Um bug introduzido na semana passada significa desfazer manualmente horas de alterações. Um experimento de funcionalidade que deu errado significa começar do zero.

O Git resolve todos esses problemas:

• Rastreie cada alteração — quem mudou o quê, quando e por quê. O histórico completo está sempre disponível.
• Reverta com segurança — volte para qualquer estado anterior sem perder o trabalho atual.
• Trabalhe em paralelo — branches permitem que várias pessoas trabalhem em diferentes funcionalidades simultaneamente.
• Colabore sem medo — o Git mescla as alterações de forma inteligente e sinaliza conflitos para que você os resolva.
• Trabalhe offline — tudo é local até que você decida fazer o push para um servidor remoto.

O controle de versão não é opcional para o desenvolvimento profissional. É uma habilidade fundamental que todo desenvolvedor precisa, independentemente da linguagem, framework ou plataforma.

Como o Git funciona

O Git opera em três áreas principais: o working directory, a staging area e o repository.

Seu working directory é onde você edita os arquivos. Quando você executa git add, as alterações movem-se para a staging area — uma zona de preparação para o próximo commit. Quando você executa git commit, as alterações preparadas são salvas como um novo snapshot no repository.

# Edit a file in your working directory
echo "Hello, Git!" > hello.txt

# Stage the change
git add hello.txt

# Commit the staged change
git commit -m "Add hello.txt"

Esse fluxo de três etapas — editar, preparar (stage), commitar — oferece controle preciso sobre o que entra em cada snapshot. Você pode adicionar partes de um arquivo à staging area, preparar múltiplos arquivos juntos e criar commits que representem cada um uma única mudança lógica.

Internamente, o Git armazena os dados como um grafo acíclico dirigido (DAG) de objetos de commit. Cada commit aponta para o seu pai, formando uma cadeia de histórico. Branches são apenas ponteiros leves para commits específicos, e o HEAD é um ponteiro para o commit em que você está atualmente.

Instalando o Git

O Git está disponível para todos os principais sistemas operacionais:

macOS:

# Using Homebrew
brew install git

# Or install Xcode Command Line Tools
xcode-select --install

Windows:

# Download from git-scm.com or use winget
winget install Git.Git

Linux:

# Debian/Ubuntu
sudo apt install git

# Fedora
sudo dnf install git

# Arch
sudo pacman -S git

Verifique a instalação:

git --version
# git version 2.45.0

Após a instalação, configure sua identidade — essas informações são incluídas em cada commit que você fizer:

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

Comandos essenciais do Git

Criando um repositório

# Start a new repository in the current directory
git init

# Clone an existing repository
git clone https://github.com/user/repo.git

git init cria uma pasta oculta .git/ que contém todos os dados de rastreamento do Git. git clone copia um repositório existente — incluindo todo o seu histórico — para a sua máquina.

Rastreando alterações

# See which files are modified, staged or untracked
git status

# Stage a specific file
git add filename.js

# Stage all changes
git add .

# Commit with a message
git commit -m "Add user authentication"

git status é o comando que você executará com mais frequência. Ele informa o que mudou, o que está no stage e o que o Git não está rastreando. Sempre verifique o status antes de fazer um commit.

Visualizando o histórico

# Show commit history
git log

# Compact one-line format
git log --oneline

# Show changes in each commit
git log -p

# Show a visual branch graph
git log --oneline --graph --all

O histórico de commits é a linha do tempo do seu projeto. Use-o para entender como o código evoluiu, quem fez as alterações e por que certas decisões foram tomadas.

Comparando alterações

# Diff between working directory and staging area
git diff

# Diff between staging area and last commit
git diff --staged

# Diff between two commits
git diff abc1234 def5678

git diff mostra exatamente o que mudou, linha por linha. É essencial para revisar seu próprio trabalho antes do commit e para entender o que outra pessoa alterou em um pull request.

Desfazendo alterações

# Discard changes in working directory
git checkout -- filename.js

# Unstage a file
git reset HEAD filename.js

# Amend the last commit
git commit --amend -m "Updated commit message"

# Revert a commit (creates a new commit that undoes it)
git revert abc1234

O Git torna a experimentação segura porque você sempre pode voltar atrás. A chave é entender a diferença entre descartar alterações, removê-las do stage e criar novos commits que revertam os anteriores.

Trabalhando com branches

# List branches
git branch

# Create a new branch
git branch feature-login

# Switch to a branch
git checkout feature-login

# Create and switch in one command
git checkout -b feature-signup

# Delete a branch
git branch -d feature-login

Branches são o superpoder do Git. Elas permitem que você trabalhe em novas funcionalidades, corrija bugs ou experimente sem afetar a base de código principal. Quando seu trabalho estiver pronto, você faz o merge da branch de volta.

Merging e rebasing

Quando uma branch está pronta, você a integra novamente à linha principal. git merge cria um merge commit que une os dois históricos, enquanto git rebase reaplica seus commits no topo de outra branch para gerar um histórico linear:

# Merge a feature branch into main
git checkout main
git merge feature-login

# Rebase a feature branch onto the latest main
git checkout feature-login
git rebase main

Se as mesmas linhas foram alteradas em ambas as branches, o Git para e marca os arquivos como conflituosos. Edite os arquivos para manter o conteúdo correto, remova os marcadores de conflito (<<<<<<<, =======, >>>>>>>), depois adicione ao stage e continue:

git add .
git merge --continue   # or: git rebase --continue

Para manter o histórico organizado, um squash merge condensa cada commit de uma feature branch em um único commit na branch de destino:

git checkout main
git merge --squash feature-dark-mode
git commit -m "Add dark mode feature"

Use merge quando quiser preservar todo o histórico da branch; use rebase ou squash quando quiser uma branch principal limpa e linear. Nunca faça rebase ou squash de commits que já foram enviados (pushed) para uma branch compartilhada.

Sincronizando com remotos

# Add a remote server
git remote add origin https://github.com/user/repo.git

# Push commits to remote
git push origin main

# Pull latest changes
git pull origin main

# Fetch without merging
git fetch origin

Remotos são cópias do seu repositório hospedadas em servidores. O remoto padrão geralmente é chamado de origin. O push envia seus commits para o remoto, e o pull baixa e integra as alterações remotas na sua branch.

O arquivo .gitignore

Nem tudo deve ser monitorado. Dependências, outputs de build, arquivos de ambiente e configurações de IDE são tipicamente ignorados:

# Dependencies
node_modules/
vendor/

# Build output
dist/
build/

# Environment variables
.env
.env.local

# IDE settings
.vscode/
.idea/

# OS files
.DS_Store
Thumbs.db

Coloque um arquivo .gitignore na raiz do seu repositório. O Git irá pular qualquer arquivo ou diretório que corresponda a esses padrões. Se você já commitou arquivos que deseja ignorar, remova-os do rastreamento primeiro:

git rm -r --cached node_modules/
git commit -m "Remove node_modules from tracking"

Entendendo commits

Um commit é a unidade fundamental do Git. Cada commit contém:

• Um hash único — um identificador SHA-1 de 40 caracteres como a1b2c3d4e5f6...
• Uma mensagem — uma descrição do que mudou e por quê
• Um autor — quem fez a alteração
• Um timestamp — quando a alteração foi feita
• Um pai — o commit no qual ele se baseia (exceto o primeiro commit)
• Um snapshot — o estado de todos os arquivos rastreados naquele momento

Boas mensagens de commit seguem uma convenção. A primeira linha é um resumo curto no modo imperativo (com menos de 72 caracteres). Um corpo opcional explica o contexto:

git commit -m "Fix null pointer in user authentication

The login endpoint was throwing a 500 error when the email
field was missing from the request body. Added a null check
before accessing user properties."

Cada commit deve representar uma única mudança lógica. Isso torna fácil entender, revisar e reverter alterações individuais sem afetar trabalhos não relacionados.

Workflows comuns de Git

Workflow centralizado

Todos trabalham na branch main. Simples, mas arriscado para equipes:

git pull origin main
# make changes
git add .
git commit -m "Update feature"
git push origin main

Workflow de feature branch

Cada funcionalidade ou correção tem sua própria branch. Os merges acontecem via pull requests:

git checkout -b feature-user-profile
# make changes
git push origin feature-user-profile
# open a pull request on GitHub

Workflow Gitflow

Um modelo estruturado com branches main, develop, feature, release e hotfix. Ideal para projetos com releases agendadas:

git checkout -b develop
git checkout -b feature-new-login
# work on feature
git checkout develop
git merge feature-new-login
git checkout -b release-v1.0
# finalize release
git checkout main
git merge release-v1.0
git tag v1.0.0

Trunk-based development

Todos fazem commit no main (o tronco) com frequência, utilizando feature flags de curta duração. Popular em empresas como Google e Meta:

git checkout main
# make small, frequent changes
git add .
git commit -m "Add feature flag for new dashboard"
git push origin main

Melhores práticas

• Faça commits cedo e com frequência — commits pequenos são mais fáceis de entender e reverter.
• Escreva mensagens de commit claras — use o modo imperativo e explique o porquê, não apenas o quê.
• Crie branches para cada feature — mantenha a main limpa e pronta para deploy.
• Faça pull antes do push — sempre integre as alterações remotas antes de compartilhar seu trabalho.
• Revise seu próprio diff — execute git diff --staged antes de fazer o commit para evitar erros.
• Nunca faça commit de segredos — use variáveis de ambiente e .gitignore.
• Tagueie as releases — use tags de versionamento semântico como v1.0.0 para facilitar o rollback.
• Mantenha o histórico limpo — faça rebase em branches de feature antes do merge para evitar merge commits confusos.

Erros comuns

• Fazer commits com muitas alterações não relacionadas em um único commit.
• Usar mensagens vagas como “fix” ou “update” que não explicam nada.
• Fazer force-push em branches compartilhadas e sobrescrever o trabalho de outras pessoas.
• Não configurar o .gitignore, resultando no commit de node_modules ou arquivos .env.
• Trabalhar na main em vez de criar uma feature branch.
• Esquecer de fazer pull antes do push, causando conflitos de merge.
• Não fazer backup de repositórios remotos — apenas o local não é suficiente.

O que aprender a seguir

Agora você já domina os fundamentos do Git: repositórios, commits, branches, merging e remotes. A partir daqui, o próximo passo natural é o GitHub para colaboração na nuvem, issues, pull requests e Actions. Escolha um projeto, construa algo real e deixe a prática acumular.