Questão de Engenharia de Software — Github e Gitlab — FCC 2025

GitFlow, merge e rebase: resolvendo sobrescrita no branch develop

Gabarito: letra E. A estratégia correta é utilizar o rebase no branch feature para reorganizar os commits e alinhar o histórico com o branch develop antes de realizar um novo merge. Isso resolve o problema de sobrescrita ao reaplicar as mudanças da feature sobre a versão mais recente do develop, evitando conflitos e preservando um histórico linear. As demais alternativas apresentam comandos inexistentes, ferramentas incorretas ou políticas que não previnem o erro descrito.

O GitFlow é um modelo de ramificação que organiza o desenvolvimento em branches com papéis bem definidos: main (produção), develop (integração), feature/* (novas funcionalidades), release/* (preparação de versões) e hotfix/* (correções urgentes). Quando uma funcionalidade é concluída, o branch feature é integrado ao develop — normalmente via merge. O problema descrito na questão é que um merge mal executado sobrescreveu código existente no develop, ou seja, o histórico do branch de integração foi corrompido por uma integração incorreta.

A solução mais adequada nesse cenário é o rebase. O comando git rebase reaplica os commits do branch atual sobre a ponta de outro branch, reescrevendo o histórico de forma linear. Ao fazer git checkout feature e git rebase develop, os commits da feature são aplicados um a um sobre o estado mais recente do develop. Isso permite resolver conflitos de forma incremental e garante que, ao final, o merge da feature no develop seja um fast-forward — sem criar um commit de merge e sem risco de sobrescrever código, pois a base já está atualizada. Essa é a prática recomendada para manter o histórico limpo e evitar integrações problemáticas.

A alternativa E é a única que ataca diretamente a causa do problema: a falta de alinhamento entre o branch feature e o develop antes da integração. Ao rebasear, a equipe garante que as mudanças da feature sejam aplicadas sobre a versão mais recente do develop, eliminando a possibilidade de sobrescrita acidental. Além disso, o rebase é uma técnica padrão do Git, amplamente utilizada em fluxos como o GitFlow para manter a linearidade do histórico.

As demais alternativas falham por motivos específicos: a letra A usa um comando inexistente (git reset -- hard não é válido — o correto seria git reset --hard), além de ser uma medida drástica que descarta commits; a letra B menciona "Operation Request Approvals" no GitHub, que não existe (o recurso correto seria Merge Request Approvals no GitLab ou Pull Request Reviews no GitHub), e políticas de revisão não previnem sobrescrita de código; a letra C cita git stepback, comando que não existe no Git; e a letra D propõe um Webhook para rejeitar merges com conflitos, mas conflitos são resolvidos pelo desenvolvedor, não rejeitados automaticamente — além de não tratar a sobrescrita já ocorrida.

A pegadinha da banca está em explorar comandos e ferramentas fictícias ou mal aplicadas, testando se o candidato conhece as operações reais do Git e as boas práticas de integração contínua. O rebase é a técnica correta para alinhar históricos antes do merge, e é exatamente isso que a alternativa E propõe.

Alternativa A — ❌ Incorreta

O comando git reset -- hard não existe no Git. O correto seria git reset --hard, que descarta todas as alterações não commitadas e move o ponteiro do branch para um commit específico. Além disso, essa ação é drástica e não resolve o problema de forma cirúrgica: ela descartaria commits inteiros do develop, forçando a equipe a refazer o trabalho. A alternativa confunde o comando e sugere uma solução destrutiva, inadequada para um ambiente de integração contínua.

Alternativa B — ❌ Incorreta

A alternativa menciona "Operation Request Approvals" no GitHub, recurso que não existe. No GitHub, o mecanismo de aprovação é o Pull Request Review, e no GitLab, o Merge Request Approvals. Além disso, políticas de revisão opcionais não previnem sobrescrita de código — elas apenas adicionam uma etapa de aprovação humana, que não detecta conflitos de merge ou sobrescritas acidentais. A alternativa mistura ferramentas e conceitos, tornando-a incorreta.

Alternativa C — ❌ Incorreta

O comando git stepback não existe no Git. Não há uma operação nativa com esse nome. A alternativa inventa um comando e sugere que ele desfaria apenas os commits problemáticos sem afetar o histórico — o que não é possível com um único comando no Git. Para desfazer commits específicos, seria necessário usar git revert (que cria um novo commit desfazendo as alterações) ou git reset (que move o ponteiro do branch), mas nenhum deles se chama stepback.

Alternativa D — ❌ Incorreta

Configurar um Webhook no GitLab para rejeitar merges que causam conflitos ou sobrescritas não é uma prática viável. Webhooks são usados para notificar eventos, não para bloquear operações. Além disso, conflitos de merge são resolvidos pelo desenvolvedor durante a integração, não rejeitados automaticamente. A alternativa confunde o papel dos Webhooks e não oferece uma solução para o problema de sobrescrita já ocorrido.

Alternativa E — ✅ Correta ⟵ GABARITO

A alternativa E propõe utilizar a estratégia rebase no branch feature para reorganizar os commits e alinhar o histórico com o branch develop antes de realizar um novo merge. Essa é a prática correta: git checkout feature seguido de git rebase develop reaplica os commits da feature sobre a versão mais recente do develop, permitindo resolver conflitos de forma incremental e garantindo que o merge posterior seja limpo, sem sobrescrita. O rebase é uma técnica fundamental do Git para manter um histórico linear e evitar integrações problemáticas, sendo a solução mais adequada para o cenário descrito.

Gabarito: letra E