Se preferir, já salve este artigo nos favoritos, pois ele será útil para consultar quando as dúvidas aparecerem!

O que é Git e por que usá-lo?

• Versionamento de código: possibilita revisar versões anteriores do projeto, identificar responsáveis por determinadas alterações e até mesmo reverter mudanças, se necessário.

• Colaboração eficiente: cada integrante da equipe (ou colaborador open source) pode trabalhar em paralelo, criando suas próprias ramificações (branches) e enviando suas contribuições para o repositório remoto (GitHub, GitLab, Bitbucket etc.).

• Organização e escalabilidade: desde pequenos projetos pessoais até grandes sistemas em produção, o Git se adapta perfeitamente.

Configuração inicial

Configurando o nome de usuário e e-mail

• --global: significa que essas configurações serão aplicadas em todos os repositórios do seu usuário no computador.

• --local: as configurações valem apenas para o repositório atual.

• --system: configurações para todos os usuários e todos os repositórios da máquina (geralmente requer privilégios de administrador).

Comandos para repositórios

1. Inicializando um repositório

• Esse comando cria uma pasta oculta chamada .git/, onde o Git armazenará todo o histórico, metadados e configurações internas do projeto.

• Após executar git init, você pode conferir a nova pasta .git/ rodando ls -a no terminal (ou exibindo arquivos ocultos na sua IDE).

Utilize git status logo após o git init para verificar o estado do novo repositório e entender quais arquivos já estão sendo rastreados.

2. Clonando um repositório existente

• O Git baixará o repositório completo, incluindo todo o histórico de commits, branches, tags e demais metadados.

• Esse é o ponto de partida quando você deseja colaborar em um projeto open source ou em um repositório da sua equipe.

Caso o repositório seja privado, será necessário ter permissão de acesso ou usar tokens/chaves SSH conforme a plataforma em questão.

3. Criando o arquivo .gitignore

• Diretórios de dependências (ex:. node_modules/).

• Arquivos de configuração local (ex.: .env).

• Pastas de build ou distribuição (ex.: dist/, build/).

É importante manter informações sensíveis fora do repositório. Se por acaso você versionou algo que não deveria (como senhas ou chaves de API), revise seu histórico e remova esses dados o quanto antes para evitar problemas de segurança.

Trabalhando com alterações

1. Verificando o status do repositório

• Exibe quais arquivos foram criados, modificados, removidos ou ainda não rastreados (untracked) desde o último commit.

• É o comando principal para verificar o que está acontecendo no seu repositório a qualquer momento.

Rodar git status frequentemente ajuda a manter o controle do que foi alterado e do que ainda precisa ser adicionado ou commitado.

2. Adicionando alterações à área de staging

• Após o git add, as alterações ficam prontas para serem incluídas no próximo commit.

• Área de staging (também chamada de index): é como uma “sala de preparação”, onde você coloca apenas as mudanças que deseja enviar ao histórico.

Suponha que você alterou vários arquivos, mas quer fazer um commit específico apenas no index.html. Basta fazer git add index.html para que apenas esse arquivo seja colocado na área de staging.

3. Criando um commit

• Ao criar um commit, você “tira uma foto” do estado do seu projeto naquele momento.

• A mensagem de commit deve ser clara e concisa, descrevendo o que foi feito e, preferencialmente, por que foi feito.

📽️

Gostou do conteúdo? Confira esse video onde o Diego Fernandes explica como ele faz para criar os commits:

4. Visualizando as diferenças

• git diff exibe as mudanças linha a linha, permitindo que você revise tudo antes de confirmar o commit.

• Excelente recurso para verificar pequenas alterações ou certificar-se de que não está enviando algo indevido ao repositório.

Se você editou um arquivo CSS e quer ter certeza de que as alterações estão corretas, use git diff style.css para ver a comparação exata do que foi modificado.

5. Visualizando o histórico de commits

• git log permite navegar pelo histórico de commits, visualizar mensagens, autores, datas e até mesmo merges.

• Você pode combinar opções como -oneline e -graph para enxergar melhor as ramificações do seu projeto.

Se o histórico estiver muito longo, use git log --oneline --graph --decorate para ver commits em apenas uma linha, com visualização das branches e tags.

Gerenciamento de branches (ramificações)

1. Listando, criando e removendo branches

• Use git branch para ver em qual branch você está e quais outras existem no repositório.

• É comum usar nomes que descrevam a funcionalidade ou correção sendo desenvolvida, como feature/login ou fix/navbar-bug.

Quando iniciar uma nova funcionalidade, crie uma branch com git branch feature/nome-da-feature. Assim, mantém o trabalho organizado e independente das outras partes do projeto.

2. Mudando entre branches

• git checkout <nome-da-branch> permite alternar entre diferentes linhas de desenvolvimento.

• A flag b cria a branch e já realiza o checkout em uma única etapa.

No Git mais recente, você também pode usar git switch <branch> ou git switch -c <branch> para se mover entre branches, dependendo da sua versão do Git.

3. Juntando branches

• Depois que você concluir o desenvolvimento na branch feature/login, pode mesclar as alterações na branch principal (geralmente chamada de main ou master).

• Se houver conflitos, resolva-os manualmente ou usando ferramentas de merge e finalize com um git commit.

4. Reorganizando o histórico (rebase)

• O rebase move os commits da branch atual para o topo de outra, criando um histórico mais linear.

• Use com cautela: reescreve o histórico, podendo causar problemas em branches compartilhadas por muitas pessoas.

Você quer que sua feature/dashboard seja baseada na versão mais recente de main. Usar git rebase main “cola” os seus commits da feature no topo do branch main, resultando em um histórico sem merges adicionais.

Colaboração e repositórios remotos

1. Adicionando e visualizando remotos

• origin é o nome padrão que indica o repositório remoto principal, mas você pode usar outros nomes se quiser.

• Use git remote -v para confirmar se o repositório foi configurado corretamente.

Em um hackathon interno na Rocketseat, a Laís cria um repositório no GitHub e compartilha o link com o time. Cada membro utiliza git remote add origin <link> para associar o projeto local ao repositório remoto.

2. Enviando commits para o repositório remoto

• Publica as alterações locais na branch main do repositório remoto.

• Se estiver em outra branch, substitua main por feature/login, hotfix/bug-123 ou qualquer outro nome de branch.

Se for a primeira vez que está enviando uma nova branch, use git push -u origin <nome-da-branch> para criar a branch no servidor remoto e associar a branch local à remota.

3. Baixando alterações do repositório remoto

• Combina git fetch (baixa alterações) e git merge (mescla alterações) em um único passo.

• Mantém seu repositório local sincronizado com as atualizações do time.

Se a Fernanda fez commits na branch main e você quer ter essas modificações, basta rodar git pull origin main para receber tudo.

4. Obtendo somente os metadados (fetch)

• Atualiza as referências locais das branches remotas, mas não mescla automaticamente as mudanças no seu código.

• Útil para conferir o que mudou no repositório remoto antes de tomar decisões de merge ou rebase.

Você quer saber se há atualizações em develop, mas ainda não quer incorporá-las ao seu trabalho. Basta dar um git fetch e depois olhar com calma as diferenças.

Desfazendo alterações

1. Descartando alterações não adicionadas

• Restaura o arquivo index.html para o estado do último commit.

• Útil quando você alterou um arquivo, mas mudou de ideia antes de adicioná-lo ao staging com git add.

Essa ação é irreversível. Tudo que estiver no arquivo (e não estiver em algum commit) será perdido.

2. Removendo arquivo da área de staging

• Remove o arquivo style.css da área de staging, mas mantém as alterações no seu diretório local.

• É ideal quando você adicionou algo por engano, mas não quer perder as alterações que fez.

Você fez várias modificações e usou git add ., mas depois percebeu que style.css não deveria estar no próximo commit. Basta git reset style.css para tirá-lo da área de staging.

3. Retornando a commits anteriores

• -soft: “desfaz” o commit, mas preserva todas as modificações na área de staging.

• -mixed (padrão): remove as alterações do staging, porém ainda deixa as modificações no seu diretório de trabalho.

• -hard: desfaz o commit e descarta todas as alterações. Use apenas se tiver certeza de que não precisa delas.

HEAD~1 representa “um commit antes do atual”. Você pode usar HEAD~2 para voltar dois commits, e assim por diante.

4. Revertendo um commit específico (criando um novo commit)

• Em vez de remover o commit do histórico, o git revert cria um novo commit que “desfaz” as mudanças do commit original.

• É a forma mais segura de lidar com alterações indesejadas em projetos colaborativos, pois mantém o histórico intacto.

Quando usar? Se você já fez push do commit para um repositório remoto e outras pessoas trabalharam em cima dele, git revert é a melhor opção para evitar complicações no histórico.

Trabalhando com stash

Como funciona na prática?

1. Você está trabalhando em uma nova tela de cadastro e precisa mudar rapidamente de branch para corrigir um bug crítico.

2. Em vez de fazer um commit incompleto, use git stash para “guardar” suas alterações.

3. Mude de branch, faça as correções e volte para a branch anterior.

4. Use git stash pop para recuperar as mudanças e continuar de onde parou.

Adicionar uma breve descrição com git stash push -m "Mensagem" ajuda a identificar facilmente cada stash na lista.

Resolvendo conflitos

1. Identifique o conflito
Use o comando:
O Git listará os arquivos em que há conflito.

2. Edite manualmente o arquivo em conflito
Ao abrir o arquivo, você verá algo assim:
• HEAD representa o seu código local.
• branch-remota representa o código que está vindo de outra branch. Combine manualmente as duas versões ou escolha apenas uma delas, removendo as linhas de marcação.

3. Marque o conflito como resolvido
Depois de ajustar o arquivo, adicione-o ao staging:

4. Finalize a mesclagem
Confirme as mudanças com:
Esse commit completará a mesclagem, registrando a resolução do conflito no histórico.

5. Ferramentas de merge (opcional)
O Git pode ser configurado para usar softwares visuais que auxiliam na resolução de conflitos:

Ferramentas como o VSCode oferecem uma experiência interativa para resolver conflitos, permitindo que você escolha qual bloco de código manter ou mesclar sem precisar editar manualmente todas as marcações.

Dicas avançadas

1. git cherry-pick

• “Pega” um commit específico de outra branch e o aplica na branch atual.

• Muito útil se você precisa de uma correção rápida que já foi feita em outro lugar, sem precisar mesclar toda a branch.

2. git bisect

• Permite encontrar o commit exato que introduziu um bug via busca binária.

• O Git vai dividir a linha do tempo em vários passos até descobrir o commit que causou o problema.

3. Aliases

• Permite criar atalhos para comandos frequentes, economizando tempo no dia a dia.

Agora você pode digitar git co <branch> ou git st em vez de escrever o comando completo.

4. git shortlog e git blame

• git shortlog: mostra um resumo dos commits agrupados por autor.

• git blame <arquivo>: exibe quem modificou cada linha de um arquivo e em qual commit.

Boas práticas

• Commits frequentes e descritivos: ajuda a manter um histórico claro e facilita o rastreio de alterações.

• Uso de branches para features: cada nova funcionalidade ou correção de bug deve ser desenvolvida numa branch própria (ex.: feature/login, fix/typo-header).

• Sempre fazer pull antes do push: evita conflitos e problemas de sincronização entre o seu repositório local e o repositório remoto.

• Nunca commitar informações sensíveis: utilize o .gitignore para credenciais, chaves de API e outros dados privados.

• Revisar suas alterações: comandos como git diff e git log podem te poupar de erros e commits desnecessários.

Resumo dos principais comandos

Esses comandos formam um fluxo de trabalho essencial para praticamente qualquer desenvolvedor.

Conclusão: quer se aprofundar ainda mais?

1. Inscreva-se na nossa newsletter para receber conteúdos exclusivos sobre programação e ficar por dentro das novidades da Rocketseat.

2. Faça parte da nossa comunidade: Junte-se a milhares de devs que trocam experiências, dúvidas e oportunidades diariamente em nossas redes e fóruns.

3. Explore outros artigos do blog da Rocketseat, onde abordamos desenvolvimento web, mobile, back-end e várias tecnologias para impulsionar seu aprendizado.