Questão de Engenharia de Software — Desenvolvimento de Software — FGV 2024
Engenharia de Software›Desenvolvimento de Software
Código
fg086159
Banca
FGV
Órgão
INPE
Ano
2024
Nível
Superior
Cargo
Tecnologista Pleno I - Desenvolvimento de Produtos de Sensoriamento Remoto para o Monitoramento de Queimadas
Em um sistema de versionamento Git, é possível obter um histórico de commits linear e mais simples de ser seguido através da combinação de patches de mais de um branch no branch principal, antes do merge.Essa combinação de patches é executada pelo comando
Agit merge.
Bgit rebase.
Cgit cherry-pick.
Dgit blend.
Egit combine.
Revelar gabarito e comentário▾
GabaritoB — git rebase.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Sistema de versionamento Git – Comandos
Gabarito: letra B. O comando git rebase é o responsável por reaplicar commits de uma branch sobre outra, gerando um histórico linear e simplificado, diferente do merge que cria um commit de merge. A descrição do enunciado — combinação de patches de mais de um branch no branch principal, antes do merge — é exatamente a finalidade do rebase.
No Git, existem três principais formas de integrar mudanças entre branches: merge, rebase e cherry-pick. Cada uma possui comportamento distinto:
Comando
Efeito
Histórico resultante
git merge
Cria um novo commit de merge que combina as alterações de duas branches
Não linear (inclui commit de merge)
git rebase
Reaplica os commits da branch atual sobre a branch alvo, um a um
Linear (sem commits de merge)
git cherry-pick
Aplica commits específicos de uma branch em outra
Linear (apenas commits selecionados)
Integração de branches (Git): Merge (Cria commit de merge, Histórico não linear); Rebase (Reaplica commits um a um, Histórico linear); Cherry-pick (Aplica commits avulsos, Histórico linear (parcial))
Alternativa A — ❌ Incorreta
git merge integra branches, mas não lineariza o histórico; ele cria um commit extra de merge, o que mantém os ramos originais visíveis. A questão pede um histórico mais simples e linear, o que não é alcançado pelo merge.
Alternativa B — ✅ Correta ⟵ GABARITO
git rebase pega os commits da branch de feature e os reaplica sobre a branch principal, como se tivessem sido feitos diretamente nela. O resultado é um histórico limpo e linear, exatamente o descrito no enunciado.
Alternativa C — ❌ Incorreta
git cherry-pick permite aplicar commits avulsos (selecionados) de uma branch em outra, mas não reaplica toda a sequência de patches de uma branch. É útil para trazer correções pontuais, não para linearizar todo o histórico.
Alternativa D — ❌ Incorreta
git blendnão existe como comando no Git. É um distrator.
Alternativa E — ❌ Incorreta
git combinenão existe como comando no Git. É outro distrator.
NÃO CAIA NESSA!
A banca explora a confusão entre merge e rebase. Enquanto o merge é mais conhecido e intuitivo para integrar branches, o rebase é a ferramenta correta quando se deseja um histórico linear. Lembre-se: merge cria um commit de merge; rebase reescreve a história.
PEGA ESSA DICA!
Na prova, sempre que o enunciado falar em "histórico linear", "limpo" ou "simples", associe imediatamente ao git rebase. Já "combinação com commit extra" ou "preservação de ramos" apontam para git merge.