Git: comandos essenciais para desenvolvedores
Rocketseat
Conheça o Rocketseat Para Empresas
Oferecemos soluções personalizadas para empresas de todos os portes.
O controle de versão com Git se tornou parte fundamental do cotidiano de desenvolvedores, e em 2025 isso é mais verdade do que nunca. Seja você iniciante no Git ou um dev experiente, dominar os comandos Git é essencial para colaborar em projetos de código de forma segura e eficiente. O Git, criado por Linus Torvalds em 2005, revolucionou a maneira como equipes desenvolvem software, tornando o versionamento distribuído um padrão da indústria. Hoje, ao completar 20 anos de existência, o Git continua evoluindo e se mantendo relevante, com novos recursos e boas práticas modernas adaptadas aos times atuais. Neste tutorial, vamos explorar do básico (como iniciar um repositório e salvar alterações) até técnicas de colaboração eficaz (como branches, pull requests e resolução de conflitos), tudo em linguagem acessível. Você terá em mãos um documento repleto de exemplos práticos e dicas valiosas, pronto para usar no dia a dia do desenvolvimento.
Preparado para dar um boost seu conhecimento em Git? Então vamos lá!
Benefícios do Git
Antes de mergulharmos nos comandos, vale entender por que o Git é tão valorizado pelos desenvolvedores e empresas. Alguns dos principais benefícios do Git incluem:
- Histórico completo e rastreabilidade: o Git registra cada alteração no código, permitindo que você volte a qualquer versão anterior quando preciso. Isso significa que é possível rastrear quem alterou o quê e quando, facilitando identificar a origem de bugs ou revertendo mudanças problemáticas.
- Segurança e integridade: o sistema de versionamento do Git foi construído com foco na segurança do histórico. Cada commit é identificado por um hash criptográfico (SHA-1), garantindo que o histórico de mudanças não seja adulterado sem detecção. Em outras palavras, você pode confiar que o código e seu histórico estão íntegros e protegidos contra alterações inesperadas.
- Colaboração eficiente: com o Git, múltiplos desenvolvedores podem trabalhar em paralelo no mesmo projeto sem pisar no código um do outro. Por meio de branches e merges, cada um desenvolve suas funcionalidades isoladamente e depois integra as contribuições ao projeto principal. O Git facilita a colaboração em equipe, evitando conflitos e consolidando as contribuições de forma organizada.
- Padrão do mercado: Git não é apenas mais uma ferramenta – é o padrão de fato em controle de versão hoje. Plataformas como GitHub, GitLab e Bitbucket adotaram o Git, e praticamente qualquer projeto profissional ou open source utiliza Git para versionamento de código. Ou seja, dominar o Git é praticamente obrigatório para desenvolvedores que querem atuar no mercado atual.
Além desses pontos, vale mencionar que o Git é rápido, gratuito e distribuído (você tem uma cópia completa do repositório localmente), o que traz flexibilidade para trabalhar mesmo sem conexão com a internet. Com esses benefícios em mente, vamos configurar o Git e colocar a mão na massa!
Configuração inicial com git config
Antes de começar a versionar código, é importante fazer uma configuração inicial do Git para associar suas informações de identificação aos commits. Isso garante que as mudanças enviadas tenham um autor reconhecido. Os comandos mais importantes nessa etapa são:
# Configurar o nome de usuário git config --global user.name "Seu Nome" # Configurar o e-mail do usuário git config --global user.email "seu-email@exemplo.com" # Verificar configurações (opcional) git config --list
Use o parâmetro
--global para que essas configurações se apliquem a todos os seus repositórios (normalmente, você faz isso uma vez só). O nome e e-mail fornecidos serão anexados a cada commit que você criar, servindo como assinatura digital das suas contribuições. Certifique-se de usar o mesmo e-mail associado ao seu GitHub ou outra plataforma de git, pois isso permite que seus commits sejam vinculados à sua conta. Outra configuração recomendada é definir o nome padrão da branch principal como
main (historicamente chamada de master). Versões recentes do Git já utilizam main por padrão, mas não custa garantir:# Define 'main' como branch padrão ao iniciar um novo repositório git config --global init.defaultBranch main
Com essas configurações iniciais prontas, você já pode começar a usar o Git nos seus projetos. Vamos agora ver o ciclo básico de versionamento, do git init ao git log.
Ciclo de versionamento: do git init ao git log
Vamos agora passar pelo fluxo básico de versionamento de código com Git, passo a passo. Esse ciclo se repete constantemente no dia a dia do desenvolvimento:
git init: inicia um novo repositório Git. Execute esse comando dentro da pasta do seu projeto para transformá-la em um repositório Git (será criada uma pasta oculta .git/ com todo o histórico). Por exemplo:git init
Após isso, seu projeto passa a ser versionado pelo Git.
Criar/editar arquivos: depois de iniciar o repositório, crie ou modifique arquivos no projeto. Por exemplo, crie um arquivo
index.html ou edite arquivos existentes. Inicialmente, esses arquivos modificados estão apenas na sua cópia de trabalho (working directory) e o Git ainda não os rastreia. git status: verifica o estado do repositório após alterações. Este comando lista quais arquivos estão modificados, novos (não rastreados) ou prontos para serem commitados. É um comando de consulta, que você deve usar com frequência para se orientar. Por exemplo, logo após criar ou modificar um arquivo, git status vai listá-lo como untracked (não rastreado) ou modified (modificado), indicando que há mudanças não versionadas ainda. git add: adiciona mudanças à staging area (área de preparo) para serem commitadas. Você pode adicionar um arquivo específico (git add arquivo.txt) ou adicionar todos de uma vez (git add .). Esse passo permite selecionar quais mudanças irão compor o próximo commit. Exemplo:git add index.html
Depois de adicionar, o arquivo
index.html sai do estado modified/untracked e passa para staged, pronto para o commit. git commit: grava as mudanças adicionadas em um novo commit (uma espécie de “foto” do estado do projeto). Cada commit representa um ponto no histórico do projeto. Ao executar git commit, use a opção -m "mensagem" para incluir uma mensagem resumindo a alteração. Por exemplo:git commit -m "Adicionar página inicial"
Isso criará um commit contendo as mudanças preparadas e uma mensagem explicativa. Após o commit, a staging area fica vazia novamente (as mudanças foram salvas no histórico) e o repositório local avança no histórico com esse novo snapshot do projeto.
git log: exibe o histórico de commits do repositório. Com esse comando, você pode ver a sequência de commits (os mais recentes geralmente no topo), com seus identificadores (hashes), autor, data e mensagem. É útil para revisitar o histórico ou confirmar se seus commits foram registrados corretamente. Uma variação útil é git log --oneline para ver cada commit em uma linha resumida. No fluxo acima, cobrimos o ciclo completo: inicializamos um repositório, fizemos alterações, adicionamos essas alterações e criamos um commit com uma mensagem. Esse ciclo se repete sempre que você faz novas mudanças no código. Lembre-se de verificar o
git status frequentemente e escrever mensagens de commit claras que descrevam o que foi feito (falaremos mais sobre boas práticas de commits adiante). Agora que você já sabe criar um histórico local, vamos explorar como o Git lida com ramificações utilizando branches.Branches: criação, navegação e merge
Um dos recursos mais poderosos do Git é a capacidade de trabalhar com branches (ramificações). Branches permitem desenvolver funcionalidades ou corrigir bugs isoladamente, sem interferir no código principal, e depois unir as mudanças. Em 2025, usar branches faz parte do fluxo de trabalho padrão em praticamente todos os projetos.
Criando uma nova branch: Para criar uma branch, use
git branch <nome_da_branch>. Por exemplo:git branch minha-feature
Isso cria uma nova ramificação chamada
minha-feature, que inicialmente é uma cópia do estado atual da branch em que você está (por exemplo, da main). Note que apenas criamos, mas não mudamos para ela ainda. Uma maneira prática de criar e já mudar para a nova branch em um só comando é:git checkout -b minha-feature
O comando acima cria a branch
minha-feature e já faz o checkout dela automaticamente. Em versões recentes do Git, você pode usar git switch -c minha-feature para o mesmo efeito (o Git introduziu o comando switch para tornar a sintaxe mais clara ao trocar de branch).
Listando branches existentes: Basta rodar git branch sem argumentos para ver todas as branches no repositório e qual está ativa no momento (marcada com um *). Isso ajuda a se situar no projeto, especialmente quando há várias ramificações. Trocando de branch (navegação): para mudar para outra branch existente, use
git checkout <nome> ou, de forma equivalente nas versões atuais, git switch <nome_da_branch>. Por exemplo:git switch minha-feature
Agora qualquer commit que você fizer será na branch
minha-feature. Importante: o comando tradicional git checkout ainda funciona e é muito utilizado em tutoriais e documentação, mas o git switch foi introduzido para deixar claro que estamos apenas trocando de contexto (sem alterar arquivos específicos). Ambos fazem a mesma coisa ao mudar de branch.Mesclando branches (merge): depois de trabalhar em uma branch separada, chega a hora de integrar as mudanças de volta à branch principal (por exemplo, a
main). Para isso, usamos o git merge. O fluxo comum é:Primeiro, certifique-se de estar na branch de destino (por exemplo,
main):git checkout main
Em seguida, execute o merge da branch de funcionalidade na branch atual. Por exemplo, para mesclar
minha-feature na main:git merge minha-feature
Ao rodar o merge, o Git tentará juntar as alterações da branch feature na branch atual. Se não houver conflitos, podem ocorrer duas situações:
- Se a
mainnão teve novos commits desde que aminha-featurefoi criada, o Git simplesmente moverá o ponteiro damain(fast-forward), incorporando todos os commits da feature.
- Se houver commits na
mainno meio do caminho, o Git criará um commit de merge, combinando o histórico das duas branches.
Após o merge, as mudanças da
minha-feature farão parte da main. É recomendável então excluir a branch que já foi integrada, para manter o repositório organizado:git branch -d minha-feature
(Dica: o
-d de delete só apagará a branch se ela já estiver mesclada; caso contrário, use -D para forçar, mas cuidado ao forçar a exclusão de branch não mesclada.)Mesclar branches é um processo normalmente tranquilo quando todos atualizam seu código com frequência. Entretanto, em casos onde duas branches modificam o mesmo trecho de código, podem surgir conflitos. Veremos adiante como resolver conflitos Git de merge passo a passo. Antes disso, vamos entender como compartilhar seu código com outros desenvolvedores usando repositórios remotos.
Colaboração remota: git remote, git push, git pull, git fetch e pull requests
Trabalhar sozinho em um repositório local é útil, mas o verdadeiro poder do Git aparece quando colaboramos remotamente via plataformas como GitHub ou GitLab. Um repositório remoto é uma copia do seu projeto hospedada na nuvem, permitindo que você e outros devs sincronizem mudanças. Vamos ver os comandos chave para colaboração remota.
Clonando um repositório existente: se o projeto já possui um repositório remoto (por exemplo, no GitHub), o jeito mais fácil de obter uma copia é usando
git clone. Por exemplo:git clone https://github.com/usuario/nome-do-repo.git
Esse comando baixa todos os arquivos e todo o histórico do repositório para sua máquina, criando uma pasta
nome-do-repo. Além disso, o Git já configura automaticamente o apelido origin apontando para o repositório remoto. A partir daí, você já tem um repositório Git funcional conectado ao remoto. Adicionando um remoto a um repositório local: caso você tenha iniciado um repositório local do zero (com
git init) e depois criado um repositório remoto vazio (no GitHub, por exemplo), será preciso conectar os dois. Isso é feito com git remote add. Por convenção, chama-se o remoto principal de origin:git remote add origin https://github.com/usuario/meu-projeto.git
Agora seu repositório local sabe a URL do remoto chamado
origin. Você pode verificar os remotos configurados com git remote -v. Enviando commits para o servidor (
git push): o comando git push envia seus commits locais para o repositório remoto. Supondo que você esteja na branch main e queira enviá-la para o origin, faça:git push -u origin main
A primeira vez usamos
-u (abreviação de --set-upstream) para salvar a relação entre a branch local e a remota, de modo que nas próximas vezes basta git push. Após esse comando, seus commits estarão no GitHub (ou outro servidor) e qualquer colaborador com acesso poderá obtê-los. Atualizando seu repositório local (
git pull): para trazer as alterações do remoto para sua máquina, usamos git pull. Esse comando combina dois passos em um: primeiro ele faz um fetch (baixa os novos commits do servidor) e em seguida faz um merge automático desses commits na branch atual. Por exemplo, para atualizar a branch main com o que há no remoto:git pull origin main
Depois de executar, seu repositório local ficará sincronizado com o remoto. É uma boa prática rodar um pull com frequência (por exemplo, ao começar o dia de trabalho) para ter o código atualizado e reduzir chances de conflito. Obs.: Se você tiver commits locais que o remoto ainda não tem, o
git pull tentará mesclar as mudanças; caso encontre conflitos, será necessário resolvê-los manualmente.Buscando alterações sem mesclar (
git fetch): em algumas situações, você pode querer apenas ver as novas mudanças do remoto sem integrá-las imediatamente. O git fetch faz exatamente isso: baixa as referências de commits e branches do servidor, atualizando seu repositório local oculto (refs remotas), mas não mexe nos seus arquivos nem na sua branch atual. Após um fetch, você pode usar git log ou git diff para inspecionar as novidades e então decidir mesclar (por exemplo, fazendo um git merge manual ou utilizando git pull depois). Resumindo: git fetch traz as novidades e deixa você decidir o que fazer, enquanto git pull já traz e aplica as novidades.Pull Requests (PRs): no dia a dia da colaboração, não basta enviar código – é importante passá-lo por revisão. É aí que entram os Pull Requests, uma funcionalidade oferecida por plataformas como GitHub e GitLab. Um Pull Request (ou Merge Request, no GitLab) é, essencialmente, um pedido para mesclar as mudanças de uma branch (geralmente uma branch de feature) em outra (geralmente a
main ou develop). O fluxo comum é o seguinte: você cria uma branch para sua funcionalidade, faz commits nela, e ao terminar, faz o push da branch para o remoto:git push origin minha-feature
Em seguida, pelo site do GitHub/GitLab, você abre um Pull Request da branch
minha-feature em direção à branch principal (por exemplo, main). A equipe então pode revisar o código, fazer comentários e até commits adicionais no PR. Somente após a aprovação, a branch é mesclada e o PR é fechado. De forma geral, esse processo de Pull Request segue estas etapas: o desenvolvedor cria a feature numa branch dedicada, publica a branch no repositório remoto e abre um PR; o time revisa, discute e possivelmente ajusta o código; e por fim, o mantenedor do projeto faz o merge da feature no repositório oficial e encerra o PR.Os Pull Requests promovem boas práticas Git como revisão de código e integração contínua. Eles evitam que mudanças sejam mescladas sem avaliação, melhoram a qualidade do software e também servem como documentação das alterações (já que ficam registrados com comentários e aprovações). Portanto, sempre que for colaborar em equipe, utilize branches e PRs ao invés de enviar commits diretamente para a branch principal.
Reversão de mudanças: git checkout (restore), git reset e git revert
Nem sempre tudo sai perfeito, e às vezes precisamos desfazer ou reverter mudanças no Git. Aqui entram três comandos importantes:
git checkout (no contexto de desfazer alterações em arquivos), git reset e git revert. Cada um tem seu propósito e boas práticas associadas.Descartando alterações não commitadas: se você editou um arquivo mas quer descartar as mudanças (voltar ao último commit), use
git restore <arquivo> (ou o equivalente antigo git checkout -- <arquivo>). Por exemplo:git restore App.js
Esse comando abandona quaisquer modificações feitas em
App.js desde o último commit, efetivamente revertendo o arquivo para o estado em que estava no commit registrado. Cuidado: as mudanças descartadas assim serão perdidas permanentemente. Use com atenção para não jogar fora trabalho importante por engano.Removendo mudanças da staging area (unstage): Caso você tenha usado
git add num arquivo errado e queira removê-lo da área de staging, utilize git reset HEAD <arquivo>. Isso não altera o conteúdo do arquivo, apenas o retira da área de preparo, voltando ao estado de modificado. É útil para corrigir seleção de arquivos antes do commit. Desfazendo commits locais (
git reset): git reset movimenta a referência de HEAD e, opcionalmente, atualiza a staging area e o working directory, permitindo "apagar" commits do histórico local. Por exemplo, se você acabou de fazer um commit indevido, pode voltar atrás:git reset HEAD~1
Esse comando desfaz o último commit localmente. As mudanças daquele commit retornarão para a área de trabalho (ou staging, dependendo do modo). Por padrão (
--mixed), o commit é removido do histórico e as modificações ficam como não adicionadas, para você corrigir e commitar novamente. Se usar --soft, as mudanças permanecem staged; e com --hard, o commit é removido e as mudanças são descartadas (perdidas). Use --hard com extrema cautela, pois ele apaga alterações definitivamente.O
git reset é ótimo para corrigir a história antes de compartilhar com o time (por exemplo, ajustar o último commit ou limpar commits de teste). Contudo, evite usá-lo em commits que já foram enviados ao remoto, pois isso reescreve o histórico e causará divergência para quem já baixou aquele commit.Revertendo commits já aplicados (
git revert): para desfazer um commit que já foi realizado sem apagar o histórico, utilizamos git revert. Esse comando cria um novo commit que introduz mudanças inversas ao commit especificado. Por exemplo, para reverter um commit específico:git revert 1a2b3c4
Isso gerará um novo commit que anula as alterações feitas no commit
1a2b3c4 (use o hash do commit alvo). O Git abrirá o editor para você confirmar/editar a mensagem do commit de reversão (por padrão, algo como "Revert '<mensagem do commit original>'"). Após salvar, o novo commit será criado, efetivamente adicionando ao histórico a informação de que aquele commit foi revertido.A grande vantagem do revert é a segurança: ele preserva todo o histórico, simplesmente adicionando um antídoto para um commit problemático. Isso é fundamental quando o commit já está no repositório remoto compartilhado – não devemos alterar a história que outros já baixaram. Em vez disso, fazemos um revert. Conforme a documentação, se tentássemos usar reset para remover um commit já publicado, teríamos conflitos porque o remoto não "esquece" um commit simplesmente. Portanto, git revert é a forma mais segura de desfazer um commit já compartilhado.
git reset vs git revert: Em resumo, o reset apaga ou move commits na linha do tempo do seu repositório local (reescrevendo o histórico), enquanto o revert cria um commit inverso que desfaz mudanças mantendo o histórico intacto. Use git reset para ajustar commits locais (antes de fazer push) e use git revert para desfazer alterações já enviadas ou quando desejar manter um registro claro da reversão. Seguindo essas boas práticas, você evita perdas de código e mantém o histórico consistente para todos os colaboradores.Resolução de conflitos de merge: passo a passo
Conflitos de merge são uma parte natural do trabalho em equipe com Git. Eles ocorrem quando duas pessoas (ou duas branches) modificam a mesma parte de um arquivo de formas diferentes, e o Git não consegue decidir automaticamente qual versão manter. Ao contrário do que parece, um conflito não é um bicho de sete cabeças – significa apenas que você precisa intervir manualmente para combinar as mudanças.
Vamos simular um cenário simples: imagine que a branch
main e a branch feature editaram a mesma linha em script.js. Quando tentarmos mesclar a branch feature na main (git merge feature estando na main), o Git avisará algo como "Automatic merge failed; fix conflicts and commit the result." e marcará o arquivo como em conflito.Identificando arquivos em conflito: O próprio output do
git merge listará os arquivos com conflito. Você também pode rodar git status, que mostrará quais arquivos estão em estado de merge conflict. Digamos que script.js esteja conflitando.Entendendo os marcadores de conflito: Abra o arquivo
script.js no seu editor. Você verá trechos assim:<<<<<<< HEAD let mensagem = "Olá do Main"; ======= let mensagem = "Olá do Feature"; >>>>>>> feature
No exemplo acima, o que está entre
<<<<<<< HEAD e ======= é o conteúdo da versão HEAD (ou seja, da branch atual, main), e o que está entre ======= e >>>>>>> feature é o conteúdo da branch que está sendo mesclada (no caso, chamada feature). Seu trabalho é editar esse trecho para chegar ao conteúdo final desejado. Resolvendo o conflito: decida o que fazer com as diferenças. Talvez você queira manter a versão da feature, ou a da main, ou até combinar as duas. Por exemplo, poderíamos alterar para:
let mensagem = "Olá do Main e Feature"; // combinação das mudanças
Remova todos os marcadores (
<<<<<<<, =======, >>>>>>>) e ajuste o código conforme necessário até que o arquivo faça sentido novamente. Marcando como resolvido e concluindo o merge: depois de editar todos os conflitos no arquivo, salve-o. Então execute:
git add script.js
Para informar ao Git que o conflito em
script.js foi resolvido. Repita o processo para quaisquer outros arquivos conflitantes (adicionando cada um após resolver). Quando todos estiverem marcados como resolvidos, finalize o merge com:Conheça o Rocketseat Para Empresas
Oferecemos soluções personalizadas para empresas de todos os portes.
Artigos_
Explore conteúdos relacionados
Descubra mais artigos que complementam seu aprendizado e expandem seu conhecimento.
NewsletterReceba conteúdos inéditos e novidades gratuitamente