Alternativa Correta: E

O tema central da questão é a Gerência de Configuração no contexto de controle de versões usando o GitLab. A gerência de configuração é crucial para garantir que o desenvolvimento de software seja bem organizado, evitando sobrescritas indesejadas e conflitos, além de assegurar a integridade do código. O conhecimento necessário envolve o entendimento das operações básicas de Git, como merge e rebase, e a habilidade de configurar sistemas de controle de versão para prevenir erros comuns.

Resumo teórico: Gerenciar branches no GitLab, especialmente usando o modelo de branching como o GitFlow, é essencial para um fluxo de trabalho eficiente. O rebase é uma estratégia que permite reorganizar a sequência de commits, o que pode alinhar o histórico de um branch com outro antes de realizar um merge final. Isso ajuda a evitar conflitos e sobrescritas.

Fonte relevante: Para mais detalhes técnicos sobre o uso de rebase e merge, a documentação oficial do Git é uma excelente referência: Git Documentation.

Justificativa da alternativa correta (E): A estratégia de rebase no branch feature ajuda a reorganizar os commits de modo a alinhá-los com o branch develop antes de realizar um novo merge. Esta abordagem reduz a possibilidade de conflitos ao integrar novas funcionalidades, pois o histórico do branch feature é reescrito para que pareça que todos os commits foram criados após os commits no develop.

Análise das alternativas incorretas:

• A: Utilizar git reset --hard pode ser perigoso, pois essa operação apaga permanentemente os commits após o ponto de reset, potencialmente resultando em perda de trabalho.
• B: A configuração de políticas de revisão opcionais no Github não se aplica ao GitLab, que é o contexto da questão. Além disso, revisões opcionais podem não prevenir erros.
• C: O termo sit stepback não é uma operação padrão no Git, sugerindo que a alternativa é inválida.
• D: Configurar um Webhook para rejeitar merges não é uma prática comum ou recomendada para gerenciar sobrescritas, pois, por si só, não trata a causa raiz dos conflitos de código.

Gostou do comentário? Deixe sua avaliação aqui embaixo!

Resposta, letra E

Utilizar rebase no branch feature para reorganizar commits e alinhar com develop

✔️ O rebase reorganiza o histórico da feature em cima do develop, antes de mesclar.

✔️ Isso evita sobrescrita de código, pois o merge será mais previsível.

A solução é preventiva, ou seja:

Trata-se de uma estratégia que deverá ser adotada pela equipe a fim de evitar que o erro ocorra novamente no futuro, mas não corrige o erro de sobrescrita que já aconteceu.

Fonte: ChatGPT

Pra quem não acertou, acredito que caberia recurso, pois, na minha interpretação, a resposta correta não cumpre integralmente o enunciado (não resolve o problema de sobrescrita que já ocorreu)

O GitFlow (ou sua variação GiFlow) recomenda que o develop seja o branch principal de desenvolvimento contínuo, e as branches feature derivem dele. O erro mencionado envolve sobrescrita de código durante um merge da feature para develop, o que indica que houve divergência de histórico e falta de alinhamento entre os dois.

Ao usar git rebase develop dentro da branch feature, você reaplica os commits da feature sobre a versão mais recente do develop. Isso:

• Garante que a feature esteja baseada no estado mais atualizado do develop;
• Reduz a chance de conflitos durante o merge posterior;
• Melhora a linearidade do histórico Git, facilitando rastreamento e revisão.

Análise das demais alternativas:

• A) git reset --hard pode apagar alterações importantes e é perigoso em ambientes colaborativos, principalmente se os commits já foram compartilhados.
• B) "Operation Request Approvais" é um termo incorreto e, ainda que revisões ajudem, não evitam tecnicamente sobrescrita acidental.
• C) "sit stepback" não é um comando Git conhecido.
• D) Webhooks não têm controle direto sobre conflitos de merge. Essas verificações devem ser feitas por merge requests com políticas de proteção e revisão.

Gabarito: E