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

Versionamento com Git: a prática correta para evitar conflitos

Gabarito: letra D. A prática correta de versionamento para evitar conflitos é criar uma branch separada para as alterações, realizar commits frequentes e solicitar um pull request para revisão antes da integração — é o fluxo padrão de trabalho colaborativo com Git, que isola o trabalho de cada desenvolvedor e submete as mudanças a um processo de revisão antes de mesclá-las à branch principal. As demais alternativas violam princípios básicos de controle de versão, como trabalhar diretamente na branch principal, ignorar o repositório remoto ou resolver conflitos manualmente sem usar as ferramentas adequadas.

O controle de versão é uma das atividades centrais da gerência de configuração de software. Ele existe para gerenciar as diferentes versões de um sistema em desenvolvimento, permitindo que vários desenvolvedores trabalhem simultaneamente sem que as alterações de um interfiram nas do outro. Quando um desenvolvedor altera componentes diretamente no código principal do repositório remoto, ele está ignorando o mecanismo que o Git oferece justamente para isolar o trabalho: as branches. Uma branch é uma linha independente de desenvolvimento, que parte de um ponto do histórico e permite que o desenvolvedor faça suas modificações sem afetar o código que outros membros da equipe estão usando. Ao final, essa branch é integrada à principal por meio de um merge ou pull request, que passa por revisão e testes antes de ser incorporada.

O fluxo de trabalho com branches é a base do desenvolvimento colaborativo moderno. O desenvolvedor cria uma branch a partir da branch principal, faz seus commits (registros de alteração) de forma incremental e frequente, e então solicita um pull request — um pedido formal para que suas alterações sejam revisadas e integradas. Esse processo permite que outros membros da equipe revisem o código, apontem problemas e sugiram melhorias antes que as mudanças entrem no código principal. É exatamente o que o desenvolvedor do enunciado deveria ter feito: em vez de alterar diretamente a branch principal, ele deveria ter criado uma branch própria, trabalhado nela e solicitado a revisão antes da integração. Isso teria evitado os conflitos que comprometeram as partes da aplicação que estavam sendo testadas por outros membros da equipe.

A alternativa D também está alinhada com as práticas ágeis adotadas pelo projeto. Em metodologias ágeis, como Scrum e XP, a integração contínua e a revisão de código são práticas fundamentais. O pull request é o mecanismo que materializa essas práticas no contexto do Git: ele permite que o trabalho seja revisado por pares, que a qualidade seja verificada e que o código seja integrado de forma controlada. Além disso, commits frequentes são recomendados porque criam um histórico claro e rastreável das alterações, facilitando o entendimento do que foi feito e a identificação de problemas.

A pegadinha desta questão está em confundir a prática correta com atalhos que parecem acelerar o desenvolvimento, mas que na verdade geram mais problemas do que resolvem. A alternativa A, por exemplo, sugere trabalhar diretamente na branch principal para acelerar o desenvolvimento — mas é exatamente isso que causa conflitos, pois todos os desenvolvedores estariam alterando o mesmo código simultaneamente. A alternativa E sugere resolver conflitos manualmente, sem usar comandos de versionamento — o que é arriscado, pois o Git oferece ferramentas para resolver conflitos de forma segura e controlada. As alternativas B e C simplesmente ignoram o repositório remoto, o que inviabiliza o trabalho colaborativo. A prática correta é sempre isolar o trabalho em branches e integrar por meio de revisão.

Guarde o critério decisivo: a prática correta de versionamento é aquela que isola o trabalho (branch), registra as alterações (commits) e submete à revisão (pull request) antes da integração. É exatamente esse fluxo que as alternativas incorretas distorcem.

Alternativa A — ❌ Incorreta

Fazer alterações diretamente na branch principal (main ou master) é a causa exata do problema descrito no enunciado. Quando todos os desenvolvedores trabalham diretamente na branch principal, as alterações de um conflitam com as do outro, comprometendo o código que está sendo testado. A branch principal deve ser protegida e estável, e as alterações devem ser integradas a ela somente após revisão e testes. Essa alternativa contraria o princípio fundamental do versionamento colaborativo.

Alternativa B — ❌ Incorreta

Apagar o repositório remoto e criar um novo com as modificações já aplicadas é uma prática absurda que destrói todo o histórico de versionamento do projeto. O repositório remoto é a fonte central de verdade do código, e apagá-lo eliminaria o histórico de commits, as branches e as referências de todos os desenvolvedores. Além disso, não resolve o problema de conflitos — apenas os esconde temporariamente, pois os outros membros da equipe teriam que se adaptar a um repositório completamente novo. O correto é usar o versionamento para gerenciar as alterações, não para recomeçar do zero.

Alternativa C — ❌ Incorreta

Baixar o repositório em formato ZIP, editar o código localmente e enviar o arquivo por e-mail ao líder técnico é uma prática que ignora completamente o controle de versão. O ZIP é uma fotografia estática do código em um determinado momento, sem histórico, sem rastreabilidade e sem mecanismos de integração. Enviar por e-mail não permite que o líder técnico revise as alterações de forma estruturada, nem que o código seja integrado ao repositório de forma controlada. Essa alternativa é totalmente incompatível com o trabalho colaborativo e com as práticas ágeis.

Alternativa D — ✅ Correta ⟵ GABARITO

Criar uma nova branch para suas alterações, realizar commits frequentes e solicitar um pull request para revisão antes da integração é exatamente a prática correta de versionamento. A branch isola o trabalho do desenvolvedor, evitando que suas alterações interfiram no código que outros membros da equipe estão usando. Os commits frequentes criam um histórico claro e rastreável das alterações. O pull request submete as mudanças à revisão de outros membros da equipe, que podem verificar a qualidade do código e apontar problemas antes da integração. Esse fluxo é o padrão de trabalho colaborativo com Git e é o que teria evitado os conflitos descritos no enunciado.

Alternativa E — ❌ Incorreta

Substituir os arquivos conflitantes manualmente sem utilizar comandos de versionamento é uma prática arriscada e desaconselhada. O Git oferece ferramentas específicas para resolver conflitos de forma segura e controlada, como o comando de merge e as ferramentas de resolução de conflitos. Substituir arquivos manualmente pode introduzir erros, perder alterações de outros desenvolvedores e criar inconsistências no código. Além disso, essa prática não resolve a causa raiz do problema, que é a falta de isolamento do trabalho em branches. O correto é usar o versionamento para gerenciar as alterações e resolver conflitos de forma estruturada.

Gabarito: letra D