Questão de Engenharia de Software — Gerência de Configuração — Quadrix 2025

Git: rebase, merge e a reescrita de histórico

Gabarito: letra B. O comando git rebase é o adequado para reescrever o histórico do branch de funcionalidade, reposicionando seus commits sobre o ponto mais atual do main, resultando em um histórico linear e sem merge commits. O git merge, por outro lado, integraria as mudanças criando um commit de merge, preservando o histórico ramificado.

O git rebase é uma operação de reescrita de histórico que pega os commits do branch atual e os reaplica, um a um, sobre a ponta de outro branch (no caso, o main). Isso faz com que o branch de funcionalidade pareça ter sido criado a partir do estado mais recente do main, eliminando a necessidade de um commit de merge e mantendo o histórico linear. É uma ferramenta poderosa, mas que deve ser usada com cautela, pois reescreve o histórico e pode causar problemas se os commits já tiverem sido compartilhados com outros desenvolvedores.

A principal distinção entre merge e rebase está na forma como integram as mudanças e no resultado final do histórico. O merge cria um novo commit (o merge commit) que une as duas linhas de desenvolvimento, preservando o histórico ramificado. O rebase reescreve o histórico, aplicando os commits de um branch sobre o outro, resultando em uma linha do tempo linear. A escolha entre um e outro depende da estratégia de versionamento da equipe: equipes que valorizam um histórico limpo e linear tendem a preferir o rebase; equipes que preferem preservar o contexto de quando e como as mudanças foram feitas tendem a usar o merge.

Na prática, o desenvolvedor executaria git rebase main estando no branch de funcionalidade. O Git pegaria os commits exclusivos do branch de funcionalidade e os reaplicaria sobre o commit mais recente do main. Se houver conflitos, eles precisam ser resolvidos durante o processo. O resultado é um histórico linear, como se o trabalho tivesse sido feito diretamente sobre o main atualizado.

A pegadinha desta questão está em confundir rebase com merge. O enunciado descreve explicitamente a reescrita do histórico e a ausência de merge commits, o que aponta diretamente para o rebase. O merge é a operação mais comum de integração, mas não atende aos requisitos de linearidade e ausência de merge commits. Guarde a fronteira entre merge e rebase: é exatamente nela que as alternativas se dividem.

Alternativa A — ❌ Incorreta

O git merge integra as mudanças de um branch em outro, mas cria um merge commit para unir as linhas de desenvolvimento. Isso preserva o histórico ramificado, o que contraria o requisito do enunciado de manter um histórico linear e limpo, sem merge commits.

Alternativa B — ✅ Correta ⟵ GABARITO

O git rebase reescreve o histórico do branch de funcionalidade, reaplicando seus commits sobre o ponto mais atual do main. Isso resulta em um histórico linear, sem merge commits, exatamente como descrito no enunciado. É a ferramenta adequada para essa estratégia.

Alternativa C — ❌ Incorreta

O git cherry-pick é usado para aplicar um commit específico de um branch em outro, mas não reescreve o histórico de um branch inteiro sobre outro. Ele copia commits individuais, não reposiciona a base do branch. Não atende ao objetivo de trazer todas as atualizações do main e reescrever o histórico.

Alternativa D — ❌ Incorreta

O git clone é usado para criar uma cópia local de um repositório remoto. Ele não tem relação com a integração de branches ou com a reescrita de histórico. É uma operação de cópia, não de integração.

Alternativa E — ❌ Incorreta

O git fetch baixa as atualizações do repositório remoto para o repositório local, mas não as integra ao branch de trabalho. Ele apenas atualiza as referências remotas, deixando a integração (via merge ou rebase) para um passo posterior. Não reescreve o histórico do branch local.

Gabarito: letra B