A analista Jéssica administra o Gitlab do TCE SP. Jéssica atribuiu ao projeto TCEMóvel a estratégia de merge na qual, após feito o merge, o hash do último commit do branch de destino torna-se idêntico ao hash do último commit do branch de origem. A estratégia escolhida por Jéssica visa preservar a quantidade e a linearidade do histórico de commits, exigindo, porém, que o branch de origem esteja atualizado em relação ao destino para a efetuação do merge. Jéssica atribuiu para o TCEMóvel a estratégia de merge:
- A)merge commit;
Errada, porque merge commit cria um novo commit de junção, o que não faz o hash final do destino ficar idêntico ao do origem.
- B)three-way merge;
Errada, porque three-way merge é um método de resolução de merge, não a estratégia que faz o destino apenas avançar para o commit do origem.
- C)squash and merge;
Errada, porque squash and merge junta as alterações em um único commit novo, alterando o hash final em vez de manter o mesmo commit.
- D)fast-forward merge;
Certa, porque no fast-forward merge o branch de destino apenas avança até o commit mais recente do branch de origem, mantendo histórico linear.
- E)semi-linear merge commit.
Errada, porque semi-linear merge commit ainda envolve commit de merge, embora tente preservar parte da linearidade do histórico.
Gabarito: D
Em Git, a forma de fazer merge muda o desenho do histórico. Algumas estratégias criam um novo commit de junção, outras preservam uma linha mais limpa e linear. A questão descreve exatamente o caso em que, depois do merge, o hash do último commit do branch de destino passa a ser o mesmo do último commit do branch de origem, porque o destino apenas avança até apontar para o mesmo commit, sem criar um commit extra de merge. Isso é o famoso fast-forward merge. A ideia é simples: se o branch de destino não fez novos commits desde que se separou do branch de origem, o Git consegue "adiantar" o ponteiro do destino até o topo do origem. Resultado: histórico linear, sem ramificação adicional no gráfico. É por isso que essa estratégia é associada à preservação da linearidade do histórico. Mas tem um detalhe importante, e a banca adora esse ponto: para o fast-forward acontecer, o branch de origem precisa estar atualizado em relação ao destino, ou seja, o destino não pode ter seguido em frente com commits próprios. Se isso acontecer, aí o Git já não consegue simplesmente avançar o ponteiro e será necessário outra estratégia. Logo, o gabarito é D, porque o enunciado descreve o comportamento típico do fast-forward merge: o branch de destino passa a apontar para o mesmo commit do branch de origem, sem commit de merge e com histórico linear. Em Git e na prática de configuração de software, isso é o clássico "sem drama, só avanço".