Git — o que é, princípios de funcionamento e comandos

O que é Git?

Git é um sistema de controle de versão distribuído (VCS) que rastreia alterações em arquivos e permite que vários desenvolvedores trabalhem no mesmo projeto simultaneamente. Ao contrário dos sistemas centralizados, no Git cada desenvolvedor tem uma cópia completa do repositório, incluindo todo o histórico de alterações, tornando o sistema resistente à perda de dados e não exigindo uma conexão constante a um servidor central.

A história do Git começou em 2005, quando Linus Torvalds criou um novo VCS depois que a BitKeeper revogou sua licença gratuita para os desenvolvedores do kernel Linux. Os objetivos eram: velocidade, simplicidade de arquitetura, suporte para desenvolvimento não linear através de ramificação e distribuição completa. Em 3 meses Torvalds escreveu o núcleo do Git, e dentro de um ano o projeto tornou-se autogerenciado sob a liderança de Junio Hamano.

De acordo com a pesquisa Stack Overflow (2024), o Git é usado por 93,9% dos desenvolvedores profissionais, tornando-o o sistema de controle de versão dominante na indústria. O concorrente mais próximo — Subversion (SVN) — é usado em apenas 5,2% dos projetos, principalmente em grandes ambientes corporativos com processos centralizados.

Como o Git funciona: repositório e commits

Repositório Git é um diretório onde o Git rastreia alterações em todos os arquivos. Dentro do diretório há uma pasta oculta .git que armazena todos os objetos do sistema: commits, árvores, blobs e referências. Quando um desenvolvedor cria um commit, o Git não copia os arquivos por completo — ele cria um instantâneo e salva uma referência a ele.

Cada commit contém: um hash SHA-1 único (40 caracteres), uma referência ao commit anterior (parent), autor, data, mensagem do commit e uma referência a uma árvore que descreve o estado dos arquivos no momento do commit. A cadeia de commits forma um grafo acíclico dirigido onde cada commit aponta para um ou mais pais.

# Inicialização do repositório
git init my-project
cd my-project

# Criação de commit
echo "Olá, Git" > README.md
git add README.md
git commit -m "Initial commit"

# Visualização do histórico
git log --oneline --graph --all

O Git usa três áreas principais: working directory (arquivos no disco), staging area (índice onde os arquivos preparados vão) e repository (histórico de commits). O comando git add move as alterações do diretório de trabalho para o staging, e git commit registra o conteúdo do staging no repositório. Essa separação permite que o desenvolvedor monte um commit significativo a partir de um conjunto de alterações sem confirmar cada edição separadamente.

Comandos básicos do Git

Comandos básicos do Git cobrem 90% das operações diárias de um desenvolvedor. O comando git clone cria uma cópia local de um repositório remoto, git pull busca alterações do servidor e as mescla com o ramo atual, e git push envia commits locais para o servidor. Esses três comandos formam o ciclo principal do fluxo de trabalho com Git.

Para ver o status, usa-se git status — ele mostra quais arquivos estão modificados, quais estão no staging e quais não estão sendo rastreados. git diff exibe alterações específicas nos arquivos antes de adicioná-los ao staging. Abaixo está uma tabela com os comandos mais usados:

Para desfazer alterações, o Git oferece várias opções. git reset move o ponteiro do ramo para um commit específico e pode redefinir o staging ou o diretório de trabalho. git revert cria um novo commit que reverte as alterações do commit especificado — esta é uma forma segura de reverter para ramos compartilhados porque o histórico não é reescrito.

Ramos no Git: main, feature e release

Ramos no Git são ponteiros móveis leves para um commit específico. Criar um novo ramo não copia arquivos, mas apenas cria um novo ponteiro, tornando a ramificação praticamente instantânea. O ramo main (anteriormente master) é o ramo principal do projeto que contém código estável pronto para lançamento.

A prática padrão é usar Git Flow ou GitHub Flow. Git Flow usa ramos: main (código de lançamento), develop(ramo de integração), feature/* (novas funcionalidades), release/*(preparação de lançamentos) e hotfix/*(correções urgentes). GitHub Flow é mais simples: apenas main e ramos feature, e todas as alterações são entregues via Pull Request.

# Criar e mudar de ramo
git branch feature-auth
git checkout feature-auth
# ou com um único comando:
git checkout -b feature-auth

# Lista de ramos
git branch --list
git branch -a  # todas as branches, incluindo as remotas

# Excluir ramo
git branch -d feature-auth

Uma característica importante da ramificação no Git é o cherry-pick: mover um commit individual de um ramo para outro usando o comando git cherry-pick <hash>. Isso é útil quando você precisa transferir uma correção de bug de um ramo feature para um release sem mesclar o ramo inteiro. O Git também suporta rebase e rebase interativo (git rebase -i) para compactar, reordenar e editar commits.

Merge e Rebase

Merge (mesclagem) cria um commit de merge especial que tem dois pais. Este commit registra o fato da fusão de dois ramos e preserva o histórico completo — é possível ver onde e quando a mesclagem ocorreu. O Merge preserva o histórico como foi criado, o que simplifica a auditoria, mas torna o grafo de commits mais complexo.

Rebase (rebase) em vez de criar um commit de merge, move os commits do ramo atual para o topo do ramo de destino. O histórico torna-se linear — criando a impressão de que o desenvolvimento foi sequencial. No entanto, o rebase reescreve o histórico, alterando os hashes SHA-1 dos commits, tornando-o perigoso para ramos compartilhados aos quais outros desenvolvedores têm acesso.

Recomendação: use merge para ramos públicos onde o histórico é visível para outros desenvolvedores (feature → develop), e rebase para trabalho local quando precisar aplicar alterações recentes do main ao seu ramo feature antes de criar um Pull Request. A regra é simples: se um commit já foi enviado ao servidor — não o rebeise.

Resolução de conflitos

Conflito de merge ocorre quando o Git não consegue mesclar automaticamente alterações em um único arquivo. O Git marca seções conflitantes no arquivo com marcadores especiais: <<<<<<< (nossas alterações), ======= (separador), >>>>>>> (alterações deles). O desenvolvedor edita manualmente o arquivo, escolhendo a opção desejada ou combinando ambas, e completa a mesclagem com um commit.

Trabalho com repositórios remotos

Repositório remoto (remote) é uma cópia de um repositório Git localizada em um servidor. GitHub, GitLab e Bitbucket são as plataformas mais populares para hospedar repositórios remotos. Elas fornecem uma interface web para visualizar código, gerenciar acesso, revisar código e integrar com sistemas CI/CD.

No Git, você pode configurar vários repositórios remotos para um projeto. Por padrão, o remoto principal é chamado origin. O comando git remote add adiciona um novo remoto, git fetch busca alterações sem mesclar, e git pull é uma abreviação de git fetch + git merge. Para trabalhar com código via Pull Request, um desenvolvedor cria um fork do repositório, clona-o, trabalha em um ramo feature e envia uma solicitação de mesclagem para o repositório original.

# Adicionar um repositório remoto
git remote add origin https://github.com/user/repo.git

# Visualizar repositórios remotos
git remote -v

# Enviar ramo para o servidor
git push -u origin feature-auth

# Buscar alterações de um ramo remoto
git pull origin main

Repositórios remotos suportam tagging para marcar versões de lançamento. As tags podem ser leves (apenas um ponteiro para um commit) ou anotadas (contêm metadados: autor, data, mensagem). Tags anotadas são recomendadas para versões de lançamento porque carregam informações completas da versão e podem ser assinadas com uma chave GPG para verificação de autoria.

Git Worktree para trabalho paralelo

Git Worktree permite trabalhar com vários ramos simultaneamente em diretórios diferentes sem alternar entre eles. O comando git worktree add ../feature-auth feature-auth cria um novo diretório de trabalho feature-auth onde você pode escrever código sem trocar de ramo no diretório principal. Worktree é útil para correções rápidas em um ramo release quando o diretório principal está ocupado com desenvolvimento de longo prazo.

Git Submodules para dependências

Git Submodules é um mecanismo para incluir um repositório Git dentro de outro. Um submódulo armazena uma referência a um commit fixo de um repositório externo, garantindo a reprodutibilidade da compilação. O comando git submodule add https://github.com/example/lib.git adiciona uma biblioteca externa como submódulo. Ao clonar um projeto com submódulos, é necessário executar git submodule update --init --recursive para baixar todas as dependências.