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.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"

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

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

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

git clone https://github.com/carlosdelfinobr/meu-repo.git

Ao executar este comando, o Git irá:

1. Criar uma pasta com o nome do repositório
2. Baixar todo o conteúdo
3. 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

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

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

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 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 .

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"

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"

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:

1. Você esqueceu de incluir um arquivo no último commit
2. Deseja alterar a mensagem do commit

Exemplo 1 — corrigindo mensagem:

git commit --amend -m "Mensagem corrigida do commit anterior"

git commit --amend -m "Mensagem corrigida do commit anterior"

Exemplo 2 — adicionando um arquivo que faltou:

git add arquivo_faltante.c
git commit --amend

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

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

1. Você altera um arquivo → modificado
2. Depois decide incluí-lo no commit → git add
3. Então registra a mudança → git commit -m
4. Se quiser revisar, usa git status
5. 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

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

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 modificadas
• git 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

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

git log

Para entender rapidamente o histórico:

git log --oneline

git log --oneline

Para saber o que está acontecendo agora:

git status

git status

Para investigar um problema no código:

1. git log --oneline para localizar o commit
2. git log para detalhes
3. git 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

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

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

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

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

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

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 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

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:

1. Criar branch para cada tarefa
   → git checkout -b minha-feature
2. Desenvolver a feature isoladamente
3. Trazer atualizações da branch principal se necessário
   → git rebase main ou git merge main
4. Finalizar
   → git merge ou rebase + merge
5. 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

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

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

<<<<<<< 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

git add arquivo-com-conflito.c

5. Finalizar

Se for merge:

git commit

git commit

Se for rebase:

git rebase --continue

git rebase --continue

6.5 Dicas práticas de resolução

• Sempre rode git status após um conflito — ele mostrará exatamente o que precisa ser resolvido.
• Use git diff para 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 pull ou git 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

1. Use git diff para visualizar alterações antes do commit.
2. Use git diff branch1 branch2 para comparar branches e prever conflitos.
3. Quando ocorrer conflito, edite manualmente os arquivos.
4. Remova as marcações, adicione ao stage e finalize o merge ou rebase.
5. 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

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)

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 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

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

git push -u origin main

Depois disso, basta usar:

git push
git pull

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

git pull origin main

Cuidados importantes:

• pull pode 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

git fetch <remote>

Baixa as atualizações apenas de um remote específico.

Exemplo:

git fetch origin

git fetch origin

7.3 Diferenças entre push, pull e fetch

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

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

git fetch
git diff main origin/main

3. Você mudou a URL do repositório

git remote set-url origin <nova-url>

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>

git remote rename origin upstream
git remote add origin <minha-fork-url>

Resumo didático desta seção

1. git remote add vincula seu repositório ao GitHub.
2. git remote -v ajuda a confirmar tudo.
3. git push -u define o fluxo automático para push/pull.
4. git pull atualiza e mescla.
5. git fetch atualiza sem mesclar (método mais seguro).
6. 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

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

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

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

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

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

git revert abc123..def456

Isso cria commits de reversão para todos os commits do intervalo.

Resumo didático deste grupo

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

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

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

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

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

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

git revert abc123..def456

Isso cria commits de reversão para todos os commits do intervalo.

Resumo didático deste grupo

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

git stash

Uso comum:

• você estava desenvolvendo uma feature, mas precisa mudar para outra branch imediatamente
• precisa atualizar sua branch com git pull sem 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

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

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}

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

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

git stash
git checkout main

2. Você quer sincronizar sua branch, mas tem modificações pendentes

git stash
git pull
git stash pop

git stash
git pull
git stash pop

3. Você está testando uma abordagem alternativa

git stash
git checkout -b nova-abordagem

git stash
git checkout -b nova-abordagem

4. Você quer aplicar as mesmas alterações em outra branch

git stash apply stash@{0}

git stash apply stash@{0}

Resumo didático desta seção

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

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

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 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 apply stash@{1}

git stash clear

Apaga todos os stashes.

Use com cuidado: essa ação é definitiva.

git stash clear

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

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

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 v1.0.0

git tag -d <tag-name>

Remove uma tag local.

git tag -d v1.0.0

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

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

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

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.

The post Guia Completo de Comandos Git: Configuração, Branches, Merge, Rebase, Stash, Reversões e Trabalho com Repositórios Remotos first appeared on MCU & FPGA.