1. Configuração Básica do Git (Basic Setup)
Antes de começar a usar o Git de forma eficiente, é essencial configurar sua identidade no sistema. Essa configuração informa ao Git quem você é, permitindo que todos os commits realizados no repositório fiquem registrados corretamente. No arquivo anexo, estes são os primeiros comandos apresentados.
1.1 Definindo nome e e-mail
git config --global user.name "Seu Nome"
Este comando registra o nome do autor dos commits.
Ele atua como uma assinatura digital simples: cada commit que você fizer apresentará esse nome.
Exemplo prático:
git config --global user.name "Carlos Delfino Carvalho Pinheiro"
git config --global user.email "seu.email@exemplo.com"
Assim como o nome, o e-mail é associado a cada commit. Plataformas como GitHub, GitLab e Bitbucket usam esse e-mail para vincular commits ao seu perfil.
Exemplo:
git config --global user.email "consultoria@carlosdelfino.eti.br"
1.2 Verificando suas configurações
git config --list
Mostra todas as configurações do Git ativas no sistema, incluindo nome, e-mail e parâmetros definidos automaticamente.
Este comando é útil quando você não tem certeza se configurou tudo corretamente ou deseja confirmar valores antes de iniciar um projeto.
Exemplo de saída esperada:
user.name=Carlos Delfino Carvalho Pinheiro
user.email=consultoria@carlosdelfino.eti.br
core.editor=vim
color.ui=auto
Explicação didática e fluxo de uso
Imagine que você está montando um laboratório de desenvolvimento. Antes de trabalhar com qualquer projeto, você precisa se identificar como membro da equipe. O Git funciona da mesma forma: ele registra cada mudança e precisa saber quem mexeu no código.
Configurar o user.name e user.email garante:
- autoria correta dos commits
- rastreabilidade do histórico
- integração adequada com plataformas online
- segurança e transparência no histórico do projeto
Depois de fazer isso uma vez com --global, você não precisa repetir para cada repositório.
2. Inicialização e Clonagem de Repositórios (git init / git clone)
Conteúdo baseado exclusivamente no PDF Dicas para melhor uso do GIT.pdf .
2.1 Criando um repositório do zero
git init
O comando git init transforma uma pasta comum em um repositório Git.
Ele cria um diretório oculto chamado .git contendo toda a estrutura necessária para registrar versões, histórico e configurações.
Quando usar?
- Ao iniciar um projeto novo
- Ao versionar um código antigo que não tinha Git
- Ao construir scripts, artigos ou documentação que você deseja rastrear
Exemplo prático:
mkdir meu-projeto
cd meu-projeto
git init
Depois disso seu repositório está pronto para receber commits, branches e pushes.
2.2 Clonando um repositório existente
git clone <repo-url>
Este comando copia um repositório remoto (por exemplo, GitHub) para o seu computador, preservando todo o histórico, branches e estrutura.
Ele é usado quando você não está criando um projeto novo, mas participando de um já existente.
Exemplo:
git clone https://github.com/carlosdelfinobr/meu-repo.git
Ao executar este comando, o Git irá:
- Criar uma pasta com o nome do repositório
- Baixar todo o conteúdo
- Conectar automaticamente ao repositório remoto (
origin)
Assim, você pode imediatamente começar a programar, criar branches, aplicar correções e enviar novas versões.
Fluxo didático e exemplos do dia a dia
Situação 1 — você inicia um projeto sozinho
Você cria os arquivos localmente, e então usa:
git init
Agora já pode versionar tudo com git add e git commit.
Situação 2 — você entrou em uma equipe que já tem repositório
Ao invés de criar um do zero, você baixa tudo com:
git clone https://github.com/equipe/projeto.git
Assim já começa pronto para trabalhar junto com os demais desenvolvedores.
Dica prática para evitar problemas
Ao clonar um repositório, você automaticamente recebe um branch configurado (geralmente main).
Caso o projeto tenha vários branches importantes, sempre faça:
git branch -a
para visualizar tudo e decidir por qual branch iniciar seu trabalho.
3. Trabalhando com Modificações (add, commit, amend)
Este é o conjunto de comandos que você usará diariamente. Eles compõem o fluxo básico de versionamento: preparar, revisar e registrar mudanças. A seguir, explicarei cada um de forma didática, com exemplos práticos e situações típicas.
3.1 Preparando arquivos para commit
git add <file>
Este comando coloca um arquivo específico na área de preparação (stage).
Significa que você está dizendo ao Git: “Esta alteração deve entrar no próximo commit”.
Exemplo:
git add main.c
git add .
O ponto significa “adicionar tudo que foi modificado, criado ou removido no diretório atual”.
É o comando mais usado no dia a dia, especialmente antes de um commit que envolve múltiplos arquivos.
Exemplo:
git add .
Quando usar?
- Quando você fez vários ajustes e deseja incluir todos no commit.
- Quando está trabalhando sozinho e não precisa granularidade extrema.
Quando evitar?
- Em equipes grandes, para não incluir sem querer arquivos que não deveriam entrar no commit.
3.2 Registrando alterações (commit)
git commit -m "mensagem"
Cria um ponto no histórico contendo tudo que está no stage.
A mensagem deve ser clara e descrever o que mudou.
Exemplo:
git commit -m "Correção do cálculo de PWM"
Esse comando é um registro permanente: o commit passa a fazer parte da linha do tempo do projeto.
git commit -am "mensagem"
É uma abreviação muito útil: combina add + commit num único comando.
Mas um detalhe importante: ele só funciona para arquivos já rastreados, ou seja, arquivos que já foram adicionados ao Git no passado.
Exemplo:
git commit -am "Ajuste na lógica de interrupções"
Quando usar?
- Alterou apenas arquivos que já existiam.
- Está fazendo ajustes rápidos e frequentes.
3.3 Ajustando o último commit
git commit --amend
Este comando substitui o último commit por um novo.
Ele é útil em duas situações:
- Você esqueceu de incluir um arquivo no último commit
- Deseja alterar a mensagem do commit
Exemplo 1 — corrigindo mensagem:
git commit --amend -m "Mensagem corrigida do commit anterior"
Exemplo 2 — adicionando um arquivo que faltou:
git add arquivo_faltante.c
git commit --amend
O Git abrirá seu editor para confirmar a nova mensagem.
Atenção:
Se você já enviou o commit para o GitHub, não use --amend a menos que saiba o que está fazendo, pois alterará o histórico remoto e pode causar conflito para outras pessoas.
3.4 Verificando o estado atual
Embora este item pertença a outra seção do PDF, faz parte natural do mesmo fluxo, então integro aqui:
git status
Mostra exatamente:
- Arquivos modificados
- Arquivos adicionados
- Arquivos não rastreados
- Branch atual
- Instruções do Git para próximos passos
Exemplo comum de saída:
modified: main.c
untracked files: config_temp.h
É o comando mais seguro para evitar erros: você sempre deve conferir o status antes de fazer commit.
Resumo didático do fluxo
- Você altera um arquivo → modificado
- Depois decide incluí-lo no commit →
git add - Então registra a mudança →
git commit -m - Se quiser revisar, usa
git status - Se cometer um erro, corrige com
git commit --amend
Esse fluxo é a espinha dorsal do Git.
4. Status & Logs (git status, git log, git log –oneline)
Essa categoria é fundamental para entender o que está acontecendo no repositório: quais arquivos mudaram, qual é o histórico de commits e como visualizar esses commits de forma mais clara e organizada. Esses comandos ajudam você a navegar no passado e no presente do projeto.
4.1 Verificando o estado do repositório
git status
Esse comando mostra uma fotografia do repositório naquele instante.
Ele informa:
- em qual branch você está
- quais arquivos foram modificados
- quais já estão no stage
- quais ainda não foram adicionados
- se há arquivos não rastreados (untracked)
- dicas sobre como prosseguir (add, commit etc.)
Exemplo típico de saída:
On branch main
Changes not staged for commit:
modified: main.c
Untracked files:
new_feature.h
Quando usar?
- Sempre antes de fazer um commit
- Sempre após editar arquivos
- Sempre que ficar inseguro sobre o estado atual
O git status é como um “painel de controle”.
4.2 Visualizando o histórico completo
git log
Exibe todo o histórico de commits do repositório, incluindo:
- hash completo do commit
- autor
- data
- mensagem do commit
Use esse comando para navegar no tempo, entender mudanças e confirmar quem alterou o quê.
Exemplo de saída:
commit 8a4e1b5c9e...
Author: Carlos Delfino Carvalho Pinheiro <email>
Date: Tue Nov 25 14:32 2025 -0300
Ajuste no algoritmo de filtragem ADC
Opções úteis (não mencionadas no PDF, mas importantes):
git log --stat→ mostra arquivos alterados e quantidade de linhas modificadasgit log --patch→ mostra o diff completo entre commits
(O PDF menciona apenas os dois principais, e seguiremos fielmente.)
4.3 Exibindo o histórico de forma compacta
git log --oneline
Mostra cada commit em uma linha, com:
- hash abreviado
- mensagem do commit
Isso torna o histórico muito mais legível, principalmente quando você está procurando um ponto específico.
Exemplo:
8a4e1b5 Ajuste nos drivers PWM
d19ac23 Implementação inicial do protocolo I2C
745af80 Criação do repositório
Esse formato é excelente para visualizar:
- organização das features
- sequência do desenvolvimento
- onde rebases podem ser aplicados
4.4 Quando usar cada um deles?
Para auditoria detalhada:
git log
Para entender rapidamente o histórico:
git log --oneline
Para saber o que está acontecendo agora:
git status
Para investigar um problema no código:
git log --onelinepara localizar o commitgit logpara detalhesgit show <commit>(comando que veremos em grupo futuro)
5.1 Criando e gerenciando branches
Branches (“ramificações”) permitem desenvolver funcionalidades, corrigir bugs ou testar ideias sem afetar o código principal. Pense em cada branch como uma linha do tempo independente.
git branch <branch-name>
Cria uma nova branch, mas não muda para ela.
Exemplo:
git branch feature-login
Agora a branch existe, porém você ainda está na branch anterior (geralmente main ou master).
Quando usar?
- Quando você deseja apenas criar uma branch, sem começar a trabalhar nela imediatamente.
git checkout <branch-name>
Usado para trocar de branch.
Exemplo:
git checkout feature-login
Agora tudo o que você alterar passa a ser registrado na branch feature-login.
git checkout -b <branch-name>
Cria e já alterna para a nova branch — um atalho muito usado.
Exemplo:
git checkout -b fix-bug-encoder
Este comando reduz para uma única etapa aquilo que normalmente exigiria dois comandos (git branch + git checkout).
5.2 Unindo linhas de desenvolvimento
Depois de terminar uma funcionalidade, você precisa juntar o trabalho da sua branch com a branch principal.
Existem duas formas principais: merge e rebase.
Cada uma tem suas vantagens e seu estilo.
git merge <branch-name>
Une o conteúdo de uma branch à branch atual.
Se você estiver em main e fizer:
git merge feature-login
O Git tenta unir as mudanças. Se tudo for compatível, cria um commit de merge que representa a junção das linhas de desenvolvimento.
Vantagens do merge:
- Preserva o histórico completo
- Mantém a sequência real dos acontecimentos
Desvantagens:
- Pode gerar histórico mais “poluído” quando há muitos merges
git rebase <branch-name>
Reaplica os commits da sua branch em cima da branch base.
Ele não une — ele reorganiza.
Exemplo:
git rebase main
Significa: “Pegue meus commits e coloque-os como se tivessem sido feitos depois da branch main”.
Vantagens:
- Histórico mais limpo
- Sem commits de merge
- Mais fácil de ler em projetos individuais
Desvantagens:
- Altera o histórico
- Deve ser usado com cautela em projetos colaborativos
5.3 Rebase interativo
git rebase -i HEAD~<n>
Permite editar a história dos últimos n commits.
Você pode:
- reorganizar commits
- alterar mensagens
- unir commits (squash)
- remover commits
Exemplo:
git rebase -i HEAD~5
O Git abrirá uma lista dos últimos 5 commits. Você pode interagir e definir que ação deseja sobre cada commit.
Uso comum:
- Limpar o histórico antes de entregar uma branch
- Combinar commits pequenos em um único commit maior
- Corrigir mensagens de commit antigas
5.4 Excluindo branches
git branch -d <branch-name>
Remove uma branch local que já foi mesclada.
Exemplo:
git branch -d feature-login
git branch -D <branch-name>
Força a remoção, mesmo que a branch não esteja mesclada.
Use com cuidado: isso pode apagar trabalho não integrado.
5.5 Comparando branches
Embora pertença a outra seção do PDF, está relacionado:
git diff <branch1> <branch2>
Compara o conteúdo de duas branches.
Exemplo:
git diff main feature-login
Mostra o que seria alterado caso você mesclasse feature-login na main.
Resumo didático deste grupo
Este conjunto de comandos define a base para trabalhar em equipe:
- Criar branch para cada tarefa
→git checkout -b minha-feature - Desenvolver a feature isoladamente
- Trazer atualizações da branch principal se necessário
→git rebase mainougit merge main - Finalizar
→git mergeourebase + merge - Apagar a branch que não será mais usada
→git branch -d minha-feature
Branches ajudam você a manter organização, padronização e controle.
6. Lidando com Conflitos de Merge (git diff, resolução manual, comparação entre branches)
Trabalhar com branches inevitavelmente leva a conflitos de merge. O Git apresenta ferramentas para identificar o que mudou e ajudar você a resolver conflitos de forma clara. Esta seção explica como interpretar essas situações e como usar os comandos do PDF para lidar com elas.
6.1 Comparando mudanças no diretório de trabalho
git diff
O comando git diff mostra exatamente o que mudou nos arquivos antes de adicionar ao stage.
Ele lista:
- linhas removidas
- linhas adicionadas
- local das alterações
- contexto do código
Exemplo:
git diff
Este comando é excelente para revisar alterações antes do commit, para evitar erros do tipo “commit acidental”.
6.2 Comparando branches
git diff <branch1> <branch2>
Este comando compara duas branches diretamente, mostrando o que uma branch tem que a outra ainda não possui.
Exemplo:
git diff main feature-login
O que isso permite?
- verificar se a branch da feature está atualizada
- antecipar conflitos de merge
- visualizar as diferenças entre versões de um mesmo arquivo
Essa análise é especialmente útil antes de um merge, pois evita surpresas.
6.3 Como ocorrem conflitos de merge
Um conflito surge quando:
- duas pessoas editam a mesma parte do mesmo arquivo
- uma pessoa remove algo que a outra modificou
- duas branches divergem e as mudanças não podem ser unidas automaticamente
Ao tentar mesclar:
git merge nome-da-branch
se houver conflito, o Git interrompe o processo e marca os arquivos problemáticos.
O arquivo fica assim:
<<<<<<< HEAD
Código da sua branch atual
=======
Código vindo da branch que está sendo mesclada
>>>>>>> feature-login
6.4 Como resolver conflitos
O processo é sempre:
1. Abrir o arquivo com conflito
Você verá os blocos delimitados por:
<<<<<<<(seu código atual)=======(separação)>>>>>>>(código da outra branch)
2. Editar manualmente
Você escolhe:
- manter seu código
- manter o código da outra branch
- combinar os dois
3. Remover as marcações
Remova todas as linhas com:<<<<<<<, =======, >>>>>>>
4. Colocar no stage
git add arquivo-com-conflito.c
5. Finalizar
Se for merge:
git commit
Se for rebase:
git rebase --continue
6.5 Dicas práticas de resolução
- Sempre rode
git statusapós um conflito — ele mostrará exatamente o que precisa ser resolvido. - Use
git diffpara entender o que causou o conflito. - Evite grandes commits — quanto menores e mais específicos os commits, menos conflitos.
- Atualize a branch com frequência usando
git pullougit fetch + merge/rebase. - Se o arquivo for muito complexo, ferramentas visuais como VSCode e Meld ajudam muito.
6.6 Resumo didático desta seção
- Use
git diffpara visualizar alterações antes do commit. - Use
git diff branch1 branch2para comparar branches e prever conflitos. - Quando ocorrer conflito, edite manualmente os arquivos.
- Remova as marcações, adicione ao stage e finalize o merge ou rebase.
- Conflitos não são erros — são parte natural do trabalho colaborativo.
7. Repositórios Remotos (Remote Repositories)
Trabalhar com repositórios remotos é essencial para colaboração, backup, integração com CI/CD e deploy. Esta seção do PDF apresenta os comandos fundamentais para conectar seu repositório local ao GitHub, GitLab, Bitbucket ou qualquer outro servidor Git.
7.1 Adicionando e configurando um repositório remoto
git remote add origin <url>
Este comando conecta seu repositório local a um repositório remoto chamado origin, que será o “destino padrão” para push e pull.
Exemplo:
git remote add origin https://github.com/carlosdelfinobr/meuprojeto.git
Isso não envia arquivos — apenas registra o endereço do repositório remoto.
git remote -v
Lista os repositórios remotos configurados, exibindo tanto a URL usada para fetch quanto para push.
Exemplo de saída:
origin https://github.com/carlosdelfinobr/meuprojeto.git (fetch)
origin https://github.com/carlosdelfinobr/meuprojeto.git (push)
Útil para confirmar se configurou tudo corretamente.
git remote set-url origin <new-url>
Serve para alterar a URL do repositório remoto — muito usado quando:
- você muda o nome do repositório no GitHub
- troca HTTPS por SSH
- muda o servidor (ex.: GitHub → GitLab)
Exemplo:
git remote set-url origin git@github.com:carlosdelfinobr/meuprojeto.git
git remote rename <old-name> <new-name>
Permite renomear um remote.
O mais comum é renomear origin para outro nome em ambientes com múltiplos remotes.
Exemplo:
git remote rename origin upstream
Agora o remote se chama upstream.
7.2 Enviando e recebendo dados do repositório remoto
git push -u origin <branch-name>
Envia sua branch local para o remoto.
A opção -u define a branch remota como upstream, ou seja, como a padrão para push e pull futuros.
Exemplo:
git push -u origin main
Depois disso, basta usar:
git push
git pull
sem precisar repetir o nome da branch.
git pull origin <branch-name>
Baixa as atualizações do remoto e já faz merge com sua branch local.
Exemplo:
git pull origin main
Cuidados importantes:
pullpode gerar conflitos- sempre revise suas modificações antes de puxar mudanças remotas
- se quiser mais controle, prefira
fetch + merge
git fetch
Baixa todas as atualizações do repositório remoto sem fazer merge automaticamente.
Isso é essencial para quem quer trabalhar com segurança e previsibilidade.
Exemplo:
git fetch
git fetch <remote>
Baixa as atualizações apenas de um remote específico.
Exemplo:
git fetch origin
7.3 Diferenças entre push, pull e fetch
| Comando | O que faz | Quando usar |
|---|---|---|
git push | envia commits para o remoto | quando deseja publicar seu trabalho |
git pull | baixa atualizações e mescla automaticamente | ao sincronizar rapidamente |
git fetch | só baixa atualizações, sem mesclar | para análise segura antes do merge |
7.4 Situações práticas
1. Você acabou de criar um repositório novo no GitHub
git remote add origin <url>
git push -u origin main
2. Você quer ver alterações remotas antes de integrar
git fetch
git diff main origin/main
3. Você mudou a URL do repositório
git remote set-url origin <nova-url>
4. Você trabalha com dois remotos (upstream + origin)
git remote rename origin upstream
git remote add origin <minha-fork-url>
Resumo didático desta seção
git remote addvincula seu repositório ao GitHub.git remote -vajuda a confirmar tudo.git push -udefine o fluxo automático para push/pull.git pullatualiza e mescla.git fetchatualiza sem mesclar (método mais seguro).- Renomear e ajustar remotes é comum em projetos maiores.
8. Desfazendo Mudanças (Undoing Changes)
Esta seção é crucial para qualquer desenvolvedor, pois todos cometemos erros, fazemos commits equivocados, alteramos arquivos indevidamente ou precisamos voltar no tempo para corrigir algo. O Git oferece diferentes níveis de “desfazer”, desde pequenas correções até resets completos no histórico.
A seguir, explico cada comando de forma clara, com exemplos práticos e comparação entre eles.
8.1 Tirando arquivos do stage
git reset <file>
Remove o arquivo da área de preparação (stage) sem alterar o conteúdo dele.
Exemplo:
git reset config.json
Quando usar:
- Quando você adicionou um arquivo por engano (usou
git add ., por exemplo). - Quando quer separar commits (organizar melhor a lógica do histórico).
O arquivo continuará modificado, apenas sai do stage.
8.2 Desfazendo o último commit (mantendo ou não as alterações)
A série de comandos reset tem três modos, cada um com uma função específica.
O PDF traz os três: soft, mixed, hard.
git reset --soft HEAD~1
Desfaz o último commit, mas mantém todos os arquivos no stage.
É como “voltar no tempo”, mas com tudo pronto para um novo commit.
Exemplo:
git reset --soft HEAD~1
Uso comum:
- você escreveu a mensagem errada no commit
- quer juntar vários commits em um só
- quer reorganizar commits sem perder nada
git reset --mixed HEAD~1
Desfaz o último commit e retira os arquivos do stage, porém mantém todas as alterações no diretório de trabalho.
Esse é o reset padrão e também o mais seguro dos três.
Exemplo:
git reset --mixed HEAD~1
Quando usar:
- quando você cometeu cedo demais
- quando quer revisar o que está prestes a commitar
- quando deseja dividir ou reorganizar o commit
git reset --hard HEAD~1
Remove completamente o commit e também descarta todas as alterações.
Esse comando é destrutivo — use com extremo cuidado.
Exemplo:
git reset --hard HEAD~1
Uso típico:
- quando você quer voltar a um estado totalmente estável
- quando gerou muitos arquivos temporários
- quando os testes quebraram tudo e você quer recomeçar limpo
⚠️ Atenção:
Depois do --hard, o que foi descartado não pode ser recuperado, a menos que esteja no reflog (que veremos mais adiante).
8.3 Revertendo commits já publicados
git revert <commit-id>
Diferente do reset, o revert não apaga um commit.
Ele cria um novo commit que desfaz as alterações de um commit específico.
Exemplo:
git revert a7e3b12
Quando usar:
- quando o commit já foi enviado para o GitHub
- quando você está trabalhando em equipe
- quando deseja manter o histórico intacto
O revert é o método mais seguro de desfazer mudanças em projetos colaborativos.
8.4 Revertendo uma faixa de commits
O PDF também menciona:
git revert <commit-id1>..<commit-id2>
Reverte múltiplos commits de uma só vez.
Exemplo:
git revert abc123..def456
Isso cria commits de reversão para todos os commits do intervalo.
Resumo didático deste grupo
| Comando | O que faz | Quando usar |
|---|---|---|
git reset <file> | tira do stage | erro ao usar add . |
reset --soft | desfaz commit, mantém stage | reorganizar commits |
reset --mixed | desfaz commit, mantém alterações | revisão antes de novo commit |
reset --hard | apaga tudo | recomeçar limpo |
revert | desfaz alterações criando novo commit | histórico já publicado |
Vamos continuar com o oitavo grupo, baseado exclusivamente no arquivo Dicas para melhor uso do GIT.pdf .
8. Desfazendo Mudanças (Undoing Changes)
Esta seção é crucial para qualquer desenvolvedor, pois todos cometemos erros, fazemos commits equivocados, alteramos arquivos indevidamente ou precisamos voltar no tempo para corrigir algo. O Git oferece diferentes níveis de “desfazer”, desde pequenas correções até resets completos no histórico.
A seguir, explico cada comando de forma clara, com exemplos práticos e comparação entre eles.
8.1 Tirando arquivos do stage
git reset <file>
Remove o arquivo da área de preparação (stage) sem alterar o conteúdo dele.
Exemplo:
git reset config.json
Quando usar:
- Quando você adicionou um arquivo por engano (usou
git add ., por exemplo). - Quando quer separar commits (organizar melhor a lógica do histórico).
O arquivo continuará modificado, apenas sai do stage.
8.2 Desfazendo o último commit (mantendo ou não as alterações)
A série de comandos reset tem três modos, cada um com uma função específica.
O PDF traz os três: soft, mixed, hard.
git reset --soft HEAD~1
Desfaz o último commit, mas mantém todos os arquivos no stage.
É como “voltar no tempo”, mas com tudo pronto para um novo commit.
Exemplo:
git reset --soft HEAD~1
Uso comum:
- você escreveu a mensagem errada no commit
- quer juntar vários commits em um só
- quer reorganizar commits sem perder nada
git reset --mixed HEAD~1
Desfaz o último commit e retira os arquivos do stage, porém mantém todas as alterações no diretório de trabalho.
Esse é o reset padrão e também o mais seguro dos três.
Exemplo:
git reset --mixed HEAD~1
Quando usar:
- quando você cometeu cedo demais
- quando quer revisar o que está prestes a commitar
- quando deseja dividir ou reorganizar o commit
git reset --hard HEAD~1
Remove completamente o commit e também descarta todas as alterações.
Esse comando é destrutivo — use com extremo cuidado.
Exemplo:
git reset --hard HEAD~1
Uso típico:
- quando você quer voltar a um estado totalmente estável
- quando gerou muitos arquivos temporários
- quando os testes quebraram tudo e você quer recomeçar limpo
⚠️ Atenção:
Depois do --hard, o que foi descartado não pode ser recuperado, a menos que esteja no reflog (que veremos mais adiante).
8.3 Revertendo commits já publicados
git revert <commit-id>
Diferente do reset, o revert não apaga um commit.
Ele cria um novo commit que desfaz as alterações de um commit específico.
Exemplo:
git revert a7e3b12
Quando usar:
- quando o commit já foi enviado para o GitHub
- quando você está trabalhando em equipe
- quando deseja manter o histórico intacto
O revert é o método mais seguro de desfazer mudanças em projetos colaborativos.
8.4 Revertendo uma faixa de commits
O PDF também menciona:
git revert <commit-id1>..<commit-id2>
Reverte múltiplos commits de uma só vez.
Exemplo:
git revert abc123..def456
Isso cria commits de reversão para todos os commits do intervalo.
Resumo didático deste grupo
| Comando | O que faz | Quando usar |
|---|---|---|
git reset <file> | tira do stage | erro ao usar add . |
reset --soft | desfaz commit, mantém stage | reorganizar commits |
reset --mixed | desfaz commit, mantém alterações | revisão antes de novo commit |
reset --hard | apaga tudo | recomeçar limpo |
revert | desfaz alterações criando novo commit | histórico já publicado |
9. Stashing — Salvando Alterações Temporariamente (git stash)
O stash é uma das funcionalidades mais úteis do Git quando você está no meio de uma tarefa, mas precisa interromper o trabalho rapidamente — seja para trocar de branch, corrigir um bug urgente ou atualizar o repositório. Ele cria um espaço temporário para guardar suas modificações sem precisar fazer commit.
A seguir, explico cada comando do PDF de forma didática, com exemplos práticos e situações reais de uso.
9.1 Guardando alterações temporariamente
git stash
Guarda todas as alterações pendentes (arquivos modificados e não rastreados, dependendo da configuração) em um “pacote temporário”.
Depois disso, o diretório de trabalho volta ao estado limpo, como se nada tivesse sido alterado.
Exemplo:
git stash
Uso comum:
- você estava desenvolvendo uma feature, mas precisa mudar para outra branch imediatamente
- precisa atualizar sua branch com
git pullsem conflitos - deseja testar outra funcionalidade sem perder o que fez
9.2 Listando stashes criados
git stash list
Mostra todos os stashes armazenados até o momento.
Exemplo de saída:
stash@{0}: WIP on main: 745af80 Ajustes no PWM
stash@{1}: WIP on feature-login: d19ac23 Criando formulário
Cada stash recebe um índice {n} e uma descrição automática.
Você pode ter quantos stashes quiser.
9.3 Recuperando alterações e removendo o stash
git stash pop
Aplica o stash mais recente e o remove da lista.
Exemplo:
git stash pop
Quando usar:
- quando você tem certeza de que deseja restaurar as alterações do stash
- quando estava apenas pausando o trabalho por alguns minutos
⚠️ Este comando pode gerar conflitos ao aplicar mudanças — o que é normal.
9.4 Recuperando alterações sem remover o stash
git stash apply
Aplica o stash, mas mantém o stash na lista.
Exemplo:
git stash apply stash@{1}
Muito útil quando você quer reaplicar o mesmo stash em múltiplas branches.
9.5 Removendo todos os stashes
git stash clear
Apaga todos os stashes armazenados.
Exemplo:
git stash clear
Use com cuidado: essa operação não pode ser desfeita.
9.6 Situações práticas de uso do stash
1. Você está no meio de uma feature e surge um bug urgente
git stash
git checkout main
2. Você quer sincronizar sua branch, mas tem modificações pendentes
git stash
git pull
git stash pop
3. Você está testando uma abordagem alternativa
git stash
git checkout -b nova-abordagem
4. Você quer aplicar as mesmas alterações em outra branch
git stash apply stash@{0}
Resumo didático desta seção
| Comando | Função |
|---|---|
git stash | guarda alterações temporariamente |
git stash list | lista os stashes armazenados |
git stash pop | recupera e remove o stash |
git stash apply | recupera sem remover |
git stash clear | remove todos os stashes |
O stash é uma ferramenta essencial para manter o fluxo de trabalho sem precisar criar commits desnecessários.
9. Stashing – Salvando Alterações Temporariamente
O stash é uma área temporária onde você pode guardar modificações sem precisar commitar.
Ele é extremamente útil quando você está no meio de algo, mas precisa trocar de branch, atualizar o repositório ou resolver um conflito.
9.1 Armazenando mudanças
git stash
Salva todas as modificações não commitadas e limpa seu diretório de trabalho, deixando tudo como se estivesse sem alterações.
Exemplo de uso típico:
Você está desenvolvendo uma nova funcionalidade, mas precisa mudar para outra branch para corrigir um bug urgente:
git stash
git checkout main
9.2 Listando stashes
git stash list
Mostra tudo o que está guardado no stash.
Exemplo de saída:
stash@{0}: WIP on main: 8a4e1b5 Ajuste de PWM
stash@{1}: WIP on feature-login: d19ac23 Tela inicial
9.3 Restaurando e removendo
git stash pop
Reaplica o stash e remove da lista.
Ideal quando você sabe que aquele stash era temporário mesmo.
git stash pop
git stash apply
Reaplica o stash sem remover da lista.
Bom quando você quer testar ou reutilizar o mesmo stash mais tarde.
git stash apply stash@{1}
git stash clear
Apaga todos os stashes.
Use com cuidado: essa ação é definitiva.
git stash clear
Resumo didático do Stash
- stash → guarda tudo rapidamente
- list → mostra o que foi guardado
- pop → recupera e remove
- apply → recupera e mantém
- clear → apaga tudo
Stash é excelente para manter seu trabalho organizado quando surge uma interrupção inesperada.
10. Advanced Operations – Operações Avançadas
Agora avançamos para comandos poderosos usados em fluxos mais experientes.
10.1 Selecionando commits específicos
git cherry-pick <commit-id>
Traz um commit específico de outra branch para sua branch atual.
Exemplo:
git cherry-pick a7e3b12
Isso aplica exatamente as alterações realizadas naquele commit.
Quando usar?
- backport de correções para versões antigas
- puxar apenas um fix sem trazer o restante da branch
- integrar mudanças urgentes sem precisar fazer merge completo
git cherry-pick <start-id>^..<end-id>
Aplica um intervalo de commits.
Exemplo:
git cherry-pick abc123^..def456
Traz todos os commits entre abc123 e def456.
10.2 Tags
git tag <tag-name>
Usado para marcar versões importantes, como releases.
Exemplo:
git tag v1.0.0
git tag -d <tag-name>
Remove uma tag local.
git tag -d v1.0.0
10.3 Reflog – histórico completo de ações
git reflog
Mostra tudo que aconteceu no repositório, inclusive ações que não aparecem no git log, como:
- resets
- branch switches
- commits descartados
- rebase
- stash
Exemplo:
git reflog
É a ferramenta mais importante para recuperar commits “perdidos”.
git reflog show <branch-name>
Mostra o reflog apenas daquela branch.
10.4 Inspeção de commits
git show <commit-id>
Exibe o conteúdo detalhado de um commit: mudanças, metadados, autor, data.
Exemplo:
git show a7e3b12
10.5 Localizando bugs com Git Bisect
git bisect start
Inicia o processo de busca binária para descobrir em qual commit um bug foi introduzido.
Depois disso, você marca:
git bisect good
git bisect bad
E o Git automaticamente encontra o commit problemático.
Resumo didático das operações avançadas
- cherry-pick → extrai commits específicos
- tag → marca versões importantes
- reflog → histórico secreto (recuperação)
- show → inspeciona commits
- bisect → ajuda a encontrar bugs no histórico
Para obter o arquivo PDF, solicite no Whatsapp.
