Git on kenji.blog

【Comandos Git】A diferença entre rebase e merge e como usá-los corretamente na prática

Sun, 13 Sep 2026 09:00:00 +0900

1. Introdução: Por que “merge ou rebase” é um dilema eterno

Git é um sistema de controle de versão indispensável no desenvolvimento de software moderno. Quando vários desenvolvedores alteram uma base de código simultaneamente, o poderoso modelo de branches do Git entra em ação. No entanto, no desenvolvimento em equipe, a discussão sobre “qual usar: merge ou rebase” é um tópico que sempre atormenta os desenvolvedores, de iniciantes a veteranos.

Neste artigo, desvendaremos a diferença entre os mecanismos de git merge e git rebase, explorando a estrutura interna do Git, como o DAG (Grafo Acíclico Direcionado) e as propriedades matemáticas dos hashes de commit. Além disso, explicaremos detalhadamente como usá-los corretamente na prática, com fluxos de trabalho específicos. Ao compreender as operações matemáticas que o Git realiza nos bastidores, e não apenas introduzir comandos, você perderá o medo de conflitos e poderá construir um histórico limpo e rastreável.

2. Estrutura interna do Git: Hashes de commit e modelo de objetos

Para entender como o Git integra o histórico, primeiro precisamos saber como ele armazena dados. O Git não armazena apenas as diferenças (patches) de alterações de arquivos, mas sim um instantâneo (snapshot) de todo o sistema de arquivos em um determinado momento.

2.1 Propriedades criptográficas dos hashes de commit

Cada commit no Git é identificado de forma única por um número hexadecimal de 40 dígitos gerado pela função de hash SHA-1 (Secure Hash Algorithm 1), calculada com base no seu conteúdo. Um objeto de commit é composto pelos seguintes elementos:

Ponteiro para o objeto Tree: O instantâneo da estrutura de diretórios e arquivos (Blob) naquele momento
Ponteiro para o commit pai: O valor do hash de um ou mais commits pais (o primeiro commit não tem pai e um commit de merge tem dois ou mais pais)
Informações do autor (Author): A pessoa que escreveu o código e a data/hora
Informações do committer (Committer): A pessoa que criou/aplicou o commit e a data/hora
Mensagem de commit: Texto explicando a intenção da alteração

Matematicamente, o valor do hash $H(C)$ para um objeto de commit $C$ é definido da seguinte forma:

$$ H(C) = \text{SHA-1}( \text{tree} \parallel \text{parent} \parallel \text{author} \parallel \text{committer} \parallel \text{message} ) $$

Aqui, $\parallel$ representa a concatenação de dados. Devido às propriedades da função de hash, mudar até mesmo um único caractere na mensagem de commit, ou ter um commit pai diferente, gerará um valor de hash completamente diferente. Ou seja, os commits são imutáveis (Immutable). Quando dizemos que o rebase, que será explicado mais adiante, “reescreve o histórico”, na verdade ele “cria novos commits com conteúdos semelhantes, mas com hashes diferentes”.

O tamanho do espaço de hash é $2^{160}$ e a probabilidade $P$ de ocorrer uma colisão (dois commits diferentes com o mesmo valor de hash) pode ser aproximada usando a teoria do Paradoxo do Aniversário (onde $n$ é o número de commits):

$$ P(\text{collision}) \approx 1 - \exp\left(-\frac{n^2}{2 \times 2^{160}}\right) $$

Essa probabilidade é extremamente baixa e, na prática, é quase impossível que os hashes de commit do Git colidam.

3. Teoria dos grafos e DAG: O modelo matemático do histórico do Git

O histórico de commits do Git é modelado como um “Grafo Acíclico Direcionado (DAG - Directed Acyclic Graph)” na teoria dos grafos.

3.1 O que é um DAG (Grafo Acíclico Direcionado)

Em um grafo $G = (V, E)$, $V$ é o conjunto de commits (vértices) e $E$ é o conjunto de arestas direcionadas que indicam as relações pai-filho entre os commits. No Git, a direção das arestas vai “do commit filho para o commit pai”. Isso ocorre porque um novo commit contém um ponteiro para um commit passado.

graph BT
A["Commit A (Inicial)"]
B["Commit B"]
C["Commit C (Main)"]
D["Commit D (Feature)"]
E["Commit E (Merge)"]
B --> A
C --> B
D --> B
E --> C
E --> D

A maior característica do DAG é a “ausência de ciclos (loops)”. Isso garante que algoritmos que rastreiam o histórico de commits nunca entrem em um loop infinito e alcancem com segurança o fim (o commit inicial).

3.2 Ordenação topológica e a ordem do histórico

Quando o histórico é exibido usando comandos como git log, o DAG é ordenado como uma lista unidimensional usando o algoritmo de Ordenação Topológica (Topological Sort). Para qualquer aresta direcionada $u \to v$ no DAG ($u$ é filho de $v$), ele é reorganizado para que $u$ venha antes de $v$ na lista.

4. Mecanismos e tipos de git merge

O comando mais básico para integrar alterações de uma branch é o git merge. No entanto, dependendo do estado atual, o Git escolhe automaticamente estratégias de merge diferentes.

4.1 Merge Fast-Forward (–ff)

Se a branch de destino (ex: main) for um ancestral direto da branch de origem (ex: feature), o Git executará um merge “Fast-Forward” (avanço rápido). Esta operação não cria um novo commit; ela simplesmente avança o ponteiro da branch.

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
merge feature

Um merge Fast-Forward mantém o histórico em linha reta, mas tem a desvantagem de perder o contexto de “quais commits agrupavam o desenvolvimento de uma única funcionalidade (feature)”.

4.2 Merge Non-Fast-Forward (–no-ff)

Ao especificar explicitamente git merge --no-ff, o Git sempre criará um novo “commit de merge”, mesmo que um Fast-Forward seja possível. Um commit de merge é um commit especial que tem dois pais.

gitGraph
commit id: "A"
commit id: "B"
branch feature
checkout feature
commit id: "C"
commit id: "D"
checkout main
commit id: "Trabalho Principal 1"
merge feature type: NORMAL

A vantagem desse método é que a existência e a história da branch da funcionalidade permanecem claras no DAG. Se ocorrer um problema, é possível desfazer (reverter) com segurança a funcionalidade inteira de uma vez, executando git revert -m 1 <hash do commit de merge>.

4.3 Algoritmo 3-Way Merge (Merge de 3 vias)

Se a branch de destino e a branch de origem tiverem seus próprios commits independentes, o Git executará um merge de 3 vias. Neste caso, o Git explora o DAG e encontra o “ancestral comum mais baixo” (LCA - Lowest Common Ancestor) das duas branches.

A complexidade computacional $T_{\text{LCA}}$ do algoritmo para encontrar o LCA pode ser executada em tempo linear em relação ao número de vértices $|V|$ e arestas $|E|$:

$$ T_{\text{LCA}} = \mathcal{O}(|V| + |E|) $$

O Git compara três estados: o “estado do LCA”, o “estado da branch atual” e o “estado da outra branch”. Se as alterações não entrarem em conflito, ele gerará um commit de merge automaticamente.

5. Mecanismo do git rebase e reconstrução do histórico

Enquanto o git merge “integra” o histórico, o git rebase “reconstrói (reorganiza)” o histórico.

5.1 O processo por trás do Rebase

Quando você faz o rebase da branch feature na branch main (git rebase main), as operações internas são as seguintes:

Encontra o ancestral comum (LCA) entre a branch feature e a branch main.
Salva as diferenças (diffs) dos commits, do LCA até o topo da branch feature, em uma área temporária.
Move o ponteiro da branch feature para o topo da branch main.
Aplica sequencialmente (Cherry-Pick) as diferenças salvas na nova base (o topo da main), criando novos commits um por um.

graph TD
A["Commit A"] --> B["Commit B"]
B --> C["Commit C (Main)"]
B --> D["Commit D (Feature Antigo)"]
D -.-> E["Commit D' (Novo Feature)"]
C --> E
style D stroke-dasharray: 5 5, fill: #f9f9f9, color: #999

O ponto crucial aqui é que o commit gerado pelo rebase, $D'$, tem um commit pai diferente do commit original $D$, portanto, ele tem um valor de hash completamente diferente (consulte a definição da função de hash $H(C)$ mencionada anteriormente).

5.2 Interactive Rebase (Rebase Interativo)

Ao usar git rebase -i (ou --interactive), você pode manipular o histórico de commits como quiser. Esta é a ferramenta mais poderosa para organizar seu histórico local.

pick: Mantém o commit como está.
reword: Altera apenas a mensagem do commit.
edit: Pausa para modificar o conteúdo do commit.
squash: Funde este commit com o commit anterior, combinando também suas mensagens.
fixup: Semelhante ao squash, mas descarta a mensagem deste commit.
drop: Remove o commit completamente.

Matematicamente, se uma branch tem $N$ commits, as variações de histórico linear (permutações) $P$ que podem ser geradas pela reordenação no rebase são:

$$ P = N! $$

O Git dá aos desenvolvedores $N!$ opções, permitindo-lhes manter o histórico lógico e elegante.

6. A Regra de Ouro do Rebase (The Golden Rule of Rebase)

Embora o rebase seja muito poderoso, existe uma regra absoluta:

“Nunca faça rebase em um histórico público compartilhado.” (Never rebase public history)

6.1 Por que você não deve fazer rebase em um histórico público?

O Git é distribuído. Os commits que você enviou para o origin/main também foram clonados nos repositórios locais de outros desenvolvedores. Se você fizer rebase de commits já enviados, reescrever o histórico e sobrescrever à força com git push --force, o que acontecerá?

O DAG no repositório local de outros desenvolvedores divergiria fundamentalmente do DAG remoto. Quando outros desenvolvedores executarem git pull, o Git tentará forçar o merge de grupos de commits com históricos diferentes, gerando um número massivo de conflitos e commits duplicados (mesmo conteúdo, mas hashes diferentes), deixando o repositório em pânico.

O rebase só deve ser executado em “branches locais que você ainda não compartilhou com ninguém”.

7. Resolução de conflitos e git rebase –continue

Se várias pessoas alterarem a mesma parte do mesmo arquivo, ocorrerá um conflito. O processo de resolução de conflitos é diferente entre merge e rebase.

7.1 Resolução de conflitos no Merge

Com o git merge, a resolução de conflitos ocorre apenas uma vez. Antes de criar o commit de merge final, você corrige todas as partes conflitantes de uma só vez.

7.2 Resolução de conflitos no Rebase

Com o git rebase, como os commits são reaplicados um por um, podem ocorrer conflitos em cada commit.

Se ocorrer um conflito durante um rebase, o Git irá pausar o processo. O fluxo de resolução é o seguinte:

Abra seu editor ou IDE (como VS Code) e resolva manualmente os marcadores de conflito (<<<<<<<, ====== e >>>>>>>).
Adicione os arquivos modificados ao índice:
1

git add <arquivo_modificado>
Retome o processo de rebase sem criar um novo commit:
1

git rebase --continue

Se você quiser cancelar o rebase e retornar ao estado original, execute o seguinte comando:

1

git rebase --abort

(Se a resolução do conflito não for necessária e você quiser pular aquele commit específico, use git rebase --skip)

8. Uso correto na prática (Workflow prático)

Então, como devemos escolher entre merge e rebase no desenvolvimento real? Aqui apresentamos a abordagem mais padrão e segura.

8.1 [Cenário 1] Organizar o histórico de trabalho local (Uso do Rebase)

Imagine que, ao desenvolver em uma branch de funcionalidade, muitos commits pequenos (“correção de erro de digitação”, “salvamento temporário”, etc.) se acumularam. Antes de abrir um Pull Request (PR), você usa o rebase interativo para organizá-los em unidades significativas.

1
2
3


# Execute enquanto estiver na branch feature
git rebase -i HEAD~5
# (O editor será aberto. Use squash ou fixup para limpar o histórico)

Isso criará um histórico de commits limpo e fácil para os revisores entenderem sua intenção.

8.2 [Cenário 2] Acompanhar as atualizações da branch main (Uso do Rebase)

Se o desenvolvimento demorar e alterações de outras pessoas continuarem sendo mescladas na branch main, sua branch feature ficará desatualizada. Neste caso, faça o rebase da sua branch feature na branch main mais recente.

1
2
3
4
5


# Obtenha as informações mais recentes da main
git fetch origin

# Faça o rebase da branch feature na versão mais recente da main
git rebase origin/main

Isso mantém o histórico linear e evita conflitos em merges futuros. Também evita a criação de commits de merge desnecessários (“Merge branch ‘main’ into feature”).

8.3 [Cenário 3] Integrar uma funcionalidade concluída (Uso do Merge)

O desenvolvimento na branch feature está concluído e é hora de integrá-lo à branch main. Aqui, usamos git merge --no-ff (equivalente a escolher “Create a merge commit” em um Pull Request do GitHub).

1
2
3


git checkout main
git merge --no-ff feature -m "Merge feature: Implementação da funcionalidade de login de usuário"
git push origin main

Isso deixa um ponto de conexão histórico (commit de merge) no DAG da branch main dizendo que “uma funcionalidade foi mesclada aqui”. Ao olhar para o histórico mais tarde, será mais fácil rastrear o código por funcionalidade.

9. Conclusão

Na operação do Git, as abordagens extremas de “fazer tudo com Merge” ou “manter tudo linear com Rebase” têm seus prós e contras.

A melhor prática no mundo real é uma abordagem híbrida: “organize o histórico privado local de forma elegante com rebase e deixe o contexto no histórico público de integração com merge –no-ff”.

Local (Espaço de trabalho pessoal): Use o rebase para eliminar commits desnecessários e acompanhar a linha principal mais recente para manter um histórico linear.
Global (Espaço de trabalho compartilhado): Use merge --no-ff para registrar a existência da branch de funcionalidade como um commit de merge no DAG, facilitando a reversão e o rastreamento.

Ao compreender a matemática e a arquitetura por trás da estrutura DAG e da função hash, os comandos Git passam da simples memorização para um “design de histórico intencional”. Seguindo a Regra de Ouro do Rebase, vamos selecionar os comandos adequados à situação e construir um histórico de commits limpo, legível e de fácil manutenção para toda a equipe.

Erros comuns de iniciantes no Git e comandos de solução (resolução de conflitos, etc.)

Sat, 12 Sep 2026 17:00:00 +0900

Erros comuns de iniciantes no Git e comandos de solução (resolução de conflitos, etc.)

1. Introdução: Por que cometemos erros no Git?

No desenvolvimento de software, o Git tornou-se tão indispensável quanto o ar ou a água. No entanto, para muitos iniciantes (e às vezes até para os mais experientes), o Git pode parecer uma “terrível caixa preta mágica”. Commits que desaparecem, grandes quantidades de alterações empurradas para a branch errada, ou mensagens de erro de conflito nunca vistas enchendo a tela… Ao cair nessas “armadilhas do Git”, o progresso do trabalho é completamente interrompido e, no pior dos casos, você é tomado pelo medo de acabar destruindo o código-fonte.

Por que o Git é tão difícil e propenso a erros? O maior motivo é que “as pessoas decoram comandos superficiais e os usam sem entender o que está acontecendo dentro do Git”. Embora o Git seja baseado em uma filosofia de design robusta como um sistema de controle de versão distribuído (DVCS), sua interface (CLI) nem sempre é intuitiva.

Neste artigo, categorizamos muitos “deslizes (erros comuns)” que os iniciantes no Git frequentemente encontram na prática, e apresentamos os comandos específicos de solução para cada um deles. No entanto, não será apenas uma lista de comandos (cheat sheet). Iremos explorar a fundo, com um volume de mais de 10.000 caracteres, “por que esses erros ocorrem” e “como os dados se movem internamente no Git ao executar esse comando”, utilizando a estrutura do diretório .git, a base matemática do algoritmo Diff em segundo plano e diagramas no Mermaid.

Ao terminar de ler este artigo, você deverá estar livre do sentimento de “o Git assusta” e, em vez disso, estará convencido de que “não há parceiro mais confiável do que o Git”. Então, vamos mergulhar no mundo profundo do Git.

2. O abismo do Git: Entendendo a estrutura interna do diretório `.git`

O primeiro passo para facilitar muitas resoluções de problemas é saber como o Git armazena os dados. A pasta oculta .git presente no diretório raiz do seu projeto é o próprio coração do Git. O Git não é apenas um sistema que registra sequencialmente as diferenças (patches) de arquivos, mas gerencia os dados como um fluxo de snapshots.

2.1 Modelo de objetos: Blob, Tree, Commit

O Git usa principalmente três objetos para representar o estado do repositório. Esses objetos são armazenados em .git/objects.

Blob (Binary Large Object) É o objeto que armazena o próprio conteúdo do arquivo. Informações como nome do arquivo ou permissões não estão incluídas aqui. Sequências de bytes puras são compactadas com zlib e identificadas por um valor de hash SHA-1 (40 caracteres hexadecimais).
Tree É o objeto que representa a estrutura de diretórios. O objeto Tree contém ponteiros (valores de hash SHA-1) para outros objetos Tree (subdiretórios) ou objetos Blob (arquivos), bem como seus nomes de arquivos e permissões de acesso. Desempenha um papel semelhante a um diretório UNIX.
Commit Mantém um ponteiro para o objeto Tree de nível superior do repositório em um determinado momento, metadados (autor, data e hora do commit, mensagem do commit) e um ponteiro para o commit imediatamente anterior (commit pai).

graph TD
Commit1["Commit (Hash: 9f8a)"] --> Tree1["Tree (Hash: 4b82)"]
Tree1 --> Blob1["Blob (Hash: 8d7e) : index.js"]
Tree1 --> Tree2["Tree (Hash: 3a2c) : src/"]
Tree2 --> Blob2["Blob (Hash: 5f1b) : app.js"]

2.2 A verdadeira natureza do HEAD e das Referências (Refs)

Ao trabalhar com o Git, a palavra HEAD é vista com frequência. Esta é uma referência simbólica (Symbolic Reference) que aponta para a branch (ou commit) atualmente verificada (checked out). Se você abrir o arquivo .git/HEAD em um editor de texto, verá uma string escrita assim:

1

ref: refs/heads/main

Isso significa que “o estado atual está na ponta da branch main”. E se você abrir .git/refs/heads/main, encontrará um hash SHA-1 de 40 caracteres, que aponta para o objeto Commit mais recente. A branch do Git é simplesmente um ponteiro leve (arquivo) que aponta para um commit específico. Sabendo desse fato, o medo de “se eu deletar a branch, todos os meus arquivos sumirão?” desaparece.

3. Decifrando o Git com matemática: Algoritmo Diff e função Hash

Quando o Git detecta conflitos ou exibe diferenças em arquivos, algoritmos avançados estão em execução internamente.

3.1 Algoritmo Diff de Myers

O algoritmo de detecção de diferença padrão do Git é o algoritmo idealizado por Eugene W. Myers. Quando temos dois arquivos de texto $A$ e $B$, o problema de encontrar o “menor procedimento de edição (inserções e exclusões)” para transformar $A$ em $B$ pode ser modelado como o problema do caminho mais curto na teoria dos grafos.

Deixe os comprimentos das strings serem $N, M$, respectivamente, e a soma seja $V = N + M$. No algoritmo de Myers, procuramos a distância de edição (Edit Distance) $D$. A complexidade de tempo desse algoritmo é expressa pela seguinte fórmula:

$$ \mathcal{O}(V \cdot D) $$

Aqui, se as diferenças entre os arquivos forem pequenas (ou seja, $D$ é pequeno), o algoritmo será executado muito rápido $\mathcal{O}(V)$. No entanto, se os arquivos forem completamente diferentes, teremos $D \approx V$, e a pior complexidade computacional será $\mathcal{O}(V^2)$.

3.2 Patience Diff e Histogram Diff

Embora o algoritmo de Myers seja aprimorado, ele pode gerar diferenças que não são intuitivas (não fazem sentido) para os humanos quando, por exemplo, a ordem das funções ou classes for significativamente alterada. Para resolver isso, o Git implementou o Patience Diff e o Histogram Diff.

O Patience Diff se concentra em “linhas únicas que aparecem apenas uma vez em ambos os arquivos” e encontra a maior subsequência comum (Longest Common Subsequence: LCS) delas. Se o número de elementos únicos for $U$, o cálculo da LCS pode ser resolvido com a seguinte complexidade computacional:

$$ \mathcal{O}(U \log U) $$

Quando você acha difícil resolver um conflito, usar git diff --histogram ou especificar esse algoritmo na estratégia de merge (git merge -s recursive -X histogram) é uma alternativa.

3.3 SHA-1 e a probabilidade de colisão

O Git gerencia todos os objetos usando valores de hash SHA-1. O tamanho do espaço de hash é $2^{160}$. Aproximando a probabilidade de colisão de hash (conteúdos diferentes tendo o mesmo valor de hash) usando o Paradoxo do Aniversário (Birthday Paradox), o número de objetos $k$ necessário para que a probabilidade de colisão $p$ chegue a 50% é o seguinte:

$$ k \approx \sqrt{2 \ln(2)} \cdot 2^{80} \approx 1.2 \times 2^{80} $$

Esse é um número astronômico e, no desenvolvimento de software normal, a probabilidade de uma colisão não intencional é virtualmente zero. Portanto, o Git opera confiando no valor do hash como uma “ID única absoluta”.

4. Estudo de caso 1: Fiz o commit na branch errada!

[Situação] Sem perceber que estava trabalhando na branch main, você escreveu todo o código da nova funcionalidade e, para piorar, até executou um git commit. A intenção original era criar uma branch chamada feature/login e trabalhar lá!

Solução: `git reset` e criação de branch

No Git, os commits são objetos independentes e as branches são apenas ponteiros. Portanto, o problema pode ser resolvido instantaneamente com a operação: “criar uma nova branch e retroceder o ponteiro da branch atual”.

1
2
3
4
5
6
7
8
9


# 1. Crie uma nova branch apontando para o commit atual (o commit feito por engano)
$ git branch feature/login

# 2. Retroceda o ponteiro da branch main para o commit anterior (HEAD~1)
# O uso do --keep permite que você redefina de forma segura, mantendo as alterações não confirmadas no diretório de trabalho.
$ git reset --keep HEAD~1

# 3. Mude para a branch correta
$ git checkout feature/login

Ilustração: O que aconteceu internamente?

Vamos visualizar o movimento do ponteiro da branch neste momento usando o gitGraph do Mermaid.

gitGraph
commit id: "Initial commit"
commit id: "Bugfix"
commit id: "Mistaken Commit" type: HIGHLIGHT
branch feature/login
checkout feature/login
checkout main

Inicialmente, main e HEAD apontavam para “Mistaken Commit”, mas com git branch feature/login, um novo ponteiro é criado lá. Após isso, apenas o ponteiro main retorna à posição de “Bugfix” por causa do git reset. Os objetos em si não foram excluídos.

5. Estudo de caso 2: Quero desfazer um commit já feito por push!

[Situação] Você fez o commit de um código cheio de bugs escrito durante a madrugada e, além disso, publicou-o no repositório remoto com git push origin main. Você percebe o bug grave e empalidece.

Solução 1: Cancelar o histórico com `git revert` (Recomendado/Seguro)

No desenvolvimento em equipe, é estritamente proibido alterar o histórico de commits que já foram enviados usando git reset ou afins. Isso causará inconsistência com os repositórios locais de outros desenvolvedores. A abordagem correta é “criar um novo commit inverso que desfaça completamente as alterações do commit errado”. Este é o git revert.

1
2
3
4
5
6
7


# Crie um commit que desfaça o commit mais recente
$ git revert HEAD
[main 7f3a8b2] Revert "Mensagem do commit incorreto"
 1 file changed, 1 insertion(+), 10 deletions(-)

# Faça o push para o remoto
$ git push origin main

gitGraph
commit id: "Commit A"
commit id: "Commit B (Mistake)"
commit id: "Revert Commit B" type: REVERSE

O histórico continua avançando e apenas o estado do código volta ao que era.

Solução 2: Alterar o histórico com `git push --force-with-lease`

Se você acabou de fazer push para uma branch que só você usa, alterar o histórico pode ser tolerado.

1
2
3
4
5
6
7


# Redefina o commit localmente e corrija
$ git reset --hard HEAD~1
$ git add .
$ git commit -m "Correct implementation"

# Substituição forçada do histórico remoto
$ git push origin feature/login --force-with-lease

O --force-with-lease é um push forçado seguro para evitar o acidente de sobrescrever acidentalmente o trabalho de outras pessoas.

6. Estudo de caso 3: Quero mudar para outra branch no meio do trabalho (A mágica do Stash)

[Situação] Durante a implementação de um novo recurso na branch feature/A, o código-fonte ainda está pela metade e nem sequer compila. De repente, seu chefe ordena: “Há um bug crítico no ambiente de produção da branch main, corrija-o agora mesmo!”

Solução: Salvar o trabalho com `git stash`

O git stash é um comando que salva temporariamente as alterações não confirmadas (uncommitted) em uma área temporária.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 1. Salve o trabalho atual
$ git stash push -m "WIP: feature A partially implemented"

# 2. Torne possível mudar para a branch main
$ git checkout main
# ... (Faça a correção do bug crítico, commit e push) ...

# 3. Volte para a branch original quando terminar o trabalho
$ git checkout feature/A

# 4. Restaure as alterações salvas
$ git stash pop

Ao executar o git stash, o Git gera internamente dois objetos de commit especiais e os salva em uma referência chamada refs/stash. Ou seja, o Stash, afinal de contas, é apenas “um commit temporário sem nome”.

7. Estudo de caso 4: O estado aterrorizante de “Detached HEAD”

[Situação] Você executou git checkout 9f8a7b6 porque queria verificar o código em um ponto específico do passado. Então, apareceu You are in 'detached HEAD' state.. Você fez um commit mesmo assim, mas quando mudou de branch, o commit desapareceu!

O mecanismo do Detached HEAD

Normalmente, o HEAD aponta para uma branch como refs/heads/main. No entanto, se você fizer o checkout diretamente em um commit específico, o HEAD passará a apontar diretamente para o objeto Commit. Isso é chamado de Detached HEAD (HEAD separado).

graph TD
A["Commit A"] --> B["Commit B"]
B --> C["Commit C"]
C --> D["Commit D"]
BranchMain["Branch: main"] --> D
HEAD["HEAD"] --> B
style HEAD fill:#f9f,stroke:#333,stroke-width:4px

Mesmo que você adicione commits neste estado, nenhuma branch rastreará esse novo commit. No instante em que você mudar para outra branch, o novo commit se perderá.

Solução: Salvar como uma nova branch

Pode ser resolvido criando uma nova branch no local onde você está agora.

1
2


# Crie uma nova branch na posição atual do HEAD e mude para ela
$ git checkout -b feature/recovered-work

8. Estudo de caso 5: Resolução de conflitos em Merge e Rebase

[Situação] Ao executar git merge ou git rebase, foi exibido CONFLICT (content) e o processo foi interrompido.

A diferença entre Merge e Rebase

Merge Executa um merge de 3 vias (3-way merge) usando os commits mais recentes de duas branches e seu ancestral comum, criando um commit de merge.
Rebase Salva temporariamente os commits da branch atual e os reaplica na ponta do alvo. O histórico se torna uma linha reta.

gitGraph
commit id: "M1"
commit id: "M2"
branch feature
checkout feature
commit id: "F1"
commit id: "F2"
checkout main
commit id: "M3"
merge feature

Método para resolução de conflitos

Marcadores como os abaixo são inseridos nos arquivos em que ocorreu um conflito.

1
2
3
4
5


<<<<<<< HEAD
const apiUrl = "https://api.production.example.com";
=======
const apiUrl = "https://api.staging.example.com";
>>>>>>> feature/new-api

O procedimento de resolução é extremamente simples.

Exclua os marcadores e corrija para o código correto.

1
2
3


const apiUrl = process.env.NODE_ENV === 'production'
 ? "https://api.production.example.com"
 : "https://api.staging.example.com";

Adicione os arquivos resolvidos à área de staging (preparação). git add tem o papel de “informar ao Git que o conflito foi resolvido”.
1

$ git add index.js

Conclua o processo.

1
2
3
4
5


# No caso de um merge
$ git commit -m "Resolve merge conflict in index.js"

# No caso de um rebase
$ git rebase --continue

Se você entrar em pânico, poderá cancelar a qualquer momento com $ git merge --abort ou $ git rebase --abort.

9. Estudo de caso 6: O histórico de commits está uma bagunça! `git rebase -i`

[Situação] Muitos commits pequenos ocorreram, como “Correção de erro de digitação”, “Correção novamente”, “Adição de testes”. Se você mesclar com main assim mesmo, o histórico ficará sujo.

Solução: Rebase Interativo

Usando git rebase -i (interactive), você pode alterar a ordem dos commits anteriores, mesclar (squash) vários commits em um só ou corrigir mensagens de commit.

1
2


# Organize os últimos 3 commits
$ git rebase -i HEAD~3

O editor será aberto e as seguintes informações serão exibidas.

1
2
3


pick 1a2b3c4 Correção de erro de digitação
pick 2b3c4d5 Correção novamente
pick 3c4d5e6 Adição de testes

Reescreva isto da seguinte forma.

1
2
3


pick 1a2b3c4 Implementação do recurso X
squash 2b3c4d5 Correção novamente
squash 3c4d5e6 Adição de testes

Ao salvar e fechar, esses três commits serão lindamente consolidados em um só.

10. Estudo de caso 7: Não sei quando o bug foi introduzido! `git bisect`

[Situação] Há um bug na branch main atual, mas estava normal durante a versão lançada um mês atrás. Quero identificar em qual commit o bug foi introduzido, mas há mais de 100 commits e é impossível fazer isso manualmente!

Solução: Identificação de bugs usando busca binária

O Git possui uma ferramenta embutida para encontrar o commit no qual um bug foi introduzido usando a busca binária matemática (Binary Search). A complexidade computacional é $\mathcal{O}(\log N)$, portanto, mesmo que você tenha 1000 commits, você pode identificá-lo em cerca de 10 testes.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Inicie a busca
$ git bisect start

# O commit atual tem o bug (bad)
$ git bisect bad

# 1 mês atrás (por exemplo, o hash a1b2c3d) estava normal (good)
$ git bisect good a1b2c3d

# O Git automaticamente verificará o commit intermediário, então execute os testes
# Se o teste for bem-sucedido:
$ git bisect good
# Se o teste falhar:
$ git bisect bad

Repetindo isso, o Git informará com precisão “Este é o primeiro commit Bad”. Ao terminar, reverta ao estado original com $ git bisect reset.

11. A rede de segurança definitiva: `git reflog`

O trunfo final contra qualquer “deslize” no Git é o git reflog. O Git registra todo o histórico de operações locais (histórico de movimentos do HEAD) por um determinado período de tempo. Mesmo que você exclua uma branch ou faça um reset incorreto, você pode recuperar a situação encontrando o hash antigo com git reflog e executando git reset --hard para ele.

1
2
3


$ git reflog
9f8a7b6 (HEAD -> main) HEAD@{0}: commit: Add new feature
1a2b3c4 HEAD@{1}: reset: moving to HEAD~1

12. Conclusão

Explicamos detalhadamente os erros comuns de iniciantes no Git, os mecanismos do Git por trás deles e suas soluções. Fazer commit na branch errada, desfazer commits já enviados (pushed), utilizar o Stash, sobreviver ao Detached HEAD e resolver conflitos. O mais importante em tudo isso é imaginar “que objetos e ponteiros o Git está manipulando nos bastidores”.

As diferenças dos arquivos são calculadas por algoritmos Diff rigorosos expressos em fórmulas matemáticas, e a consistência histórica é garantida por funções hash criptográficas. Se você entender essa bela filosofia de design, descobrirá que o Git não é de forma alguma uma “caixa preta indescritível”, mas sim o escudo mais forte para proteger seu código-fonte.

Na próxima vez que você pensar “Fiz besteira!”, não se apresse em fechar o terminal; respire fundo e digite git status. O Git sempre fornecerá dicas de recuperação.

Git on kenji.blog

【Comandos Git】A diferença entre rebase e merge e como usá-los corretamente na prática

1. Introdução: Por que “merge ou rebase” é um dilema eterno

2. Estrutura interna do Git: Hashes de commit e modelo de objetos

2.1 Propriedades criptográficas dos hashes de commit

3. Teoria dos grafos e DAG: O modelo matemático do histórico do Git

3.1 O que é um DAG (Grafo Acíclico Direcionado)

3.2 Ordenação topológica e a ordem do histórico

4. Mecanismos e tipos de git merge

4.1 Merge Fast-Forward (–ff)

4.2 Merge Non-Fast-Forward (–no-ff)

4.3 Algoritmo 3-Way Merge (Merge de 3 vias)

5. Mecanismo do git rebase e reconstrução do histórico

5.1 O processo por trás do Rebase

5.2 Interactive Rebase (Rebase Interativo)

6. A Regra de Ouro do Rebase (The Golden Rule of Rebase)

6.1 Por que você não deve fazer rebase em um histórico público?

7. Resolução de conflitos e git rebase –continue

7.1 Resolução de conflitos no Merge

7.2 Resolução de conflitos no Rebase

8. Uso correto na prática (Workflow prático)

8.1 [Cenário 1] Organizar o histórico de trabalho local (Uso do Rebase)

8.2 [Cenário 2] Acompanhar as atualizações da branch main (Uso do Rebase)

8.3 [Cenário 3] Integrar uma funcionalidade concluída (Uso do Merge)

9. Conclusão

Erros comuns de iniciantes no Git e comandos de solução (resolução de conflitos, etc.)

Erros comuns de iniciantes no Git e comandos de solução (resolução de conflitos, etc.)

1. Introdução: Por que cometemos erros no Git?

2. O abismo do Git: Entendendo a estrutura interna do diretório .git

2.1 Modelo de objetos: Blob, Tree, Commit

2.2 A verdadeira natureza do HEAD e das Referências (Refs)

3. Decifrando o Git com matemática: Algoritmo Diff e função Hash

3.1 Algoritmo Diff de Myers

3.2 Patience Diff e Histogram Diff

3.3 SHA-1 e a probabilidade de colisão

4. Estudo de caso 1: Fiz o commit na branch errada!

Solução: git reset e criação de branch

Ilustração: O que aconteceu internamente?

5. Estudo de caso 2: Quero desfazer um commit já feito por push!

Solução 1: Cancelar o histórico com git revert (Recomendado/Seguro)

Solução 2: Alterar o histórico com git push --force-with-lease

6. Estudo de caso 3: Quero mudar para outra branch no meio do trabalho (A mágica do Stash)

Solução: Salvar o trabalho com git stash

7. Estudo de caso 4: O estado aterrorizante de “Detached HEAD”

O mecanismo do Detached HEAD

Solução: Salvar como uma nova branch

8. Estudo de caso 5: Resolução de conflitos em Merge e Rebase

A diferença entre Merge e Rebase

Método para resolução de conflitos

9. Estudo de caso 6: O histórico de commits está uma bagunça! git rebase -i

Solução: Rebase Interativo

10. Estudo de caso 7: Não sei quando o bug foi introduzido! git bisect

Solução: Identificação de bugs usando busca binária

11. A rede de segurança definitiva: git reflog

12. Conclusão

2. O abismo do Git: Entendendo a estrutura interna do diretório `.git`

Solução: `git reset` e criação de branch

Solução 1: Cancelar o histórico com `git revert` (Recomendado/Seguro)

Solução 2: Alterar o histórico com `git push --force-with-lease`

Solução: Salvar o trabalho com `git stash`

9. Estudo de caso 6: O histórico de commits está uma bagunça! `git rebase -i`

10. Estudo de caso 7: Não sei quando o bug foi introduzido! `git bisect`

11. A rede de segurança definitiva: `git reflog`