Questão de Engenharia de Software — Git — FCC 2026

Controle de Versão: Git vs SVN no cenário de sistema crítico

Gabarito: letra A. A alternativa A é a mais apropriada porque combina o Git distribuído — que oferece rastreabilidade, auditoria e suporte a branches leves e tags — com práticas de commit assinado (GPG) e um repositório remoto oficial como ponto central de controle, atendendo integralmente aos requisitos de rastreabilidade, auditoria, release estável e colaboração modular entre times. As demais alternativas ou subutilizam os recursos do Git (B, D, E) ou apresentam limitações do SVN que não atendem à necessidade de branching leve e colaboração distribuída (C).

O controle de versão é uma prática essencial da Gerência de Configuração de Software (GCS), que visa monitorar e registrar alterações em arquivos ao longo do tempo. Existem três modelos principais: local (armazena alterações em um único computador), centralizado (um servidor central armazena o repositório e os clientes interagem com ele) e distribuído (cada cliente mantém uma cópia completa do repositório e pode comunicar-se com outros clientes). O Git é o exemplo mais conhecido de sistema distribuído, enquanto o SVN (Apache Subversion) é o representante clássico do modelo centralizado.

A escolha entre Git e SVN depende diretamente das necessidades do projeto. O Git trata os dados como um conjunto de snapshots do sistema de arquivos, realiza a maioria das operações localmente (não depende de conexão com servidor), garante a integridade dos dados usando checksums (cada commit recebe um ID exclusivo de 40 caracteres, soma SHA-1) e não remove dados, apenas adiciona novas versões. Essas características tornam o Git ideal para cenários que exigem rastreabilidade completa, auditoria e colaboração entre múltiplos times, pois cada desenvolvedor tem uma cópia integral do histórico e pode trabalhar de forma independente, mesclando suas alterações posteriormente.

No cenário descrito — um sistema crítico para registrar infrações, gerenciar permissões e integrar APIs externas, com necessidade de rastreabilidade, auditoria, release estável, branching para novos módulos e colaboração entre diferentes times — o Git distribuído é a escolha natural. As branches leves do Git permitem que cada módulo (infrações, notificações, permissões) seja desenvolvido em paralelo sem interferência, as tags permitem marcar releases regulatórias (como "v1.0-regulação"), e o commit assinado (GPG) garante a autenticidade e integridade das alterações, essencial para auditoria. O repositório remoto oficial funciona como ponto central de integração, garantindo que o histórico seja preservado e que todos os times colaborem de forma coordenada.

A pegadinha central desta questão é a tentação de escolher o SVN por sua centralização, que parece mais "controlada" para um sistema crítico. No entanto, o SVN tem limitações significativas: branches são cópias completas (pesadas), o histórico é centralizado (depende do servidor) e a colaboração distribuída é limitada. O Git, mesmo sendo distribuído, pode ser usado com um fluxo centralizado (todos enviam para um repositório oficial), combinando o melhor dos dois mundos: a flexibilidade e rastreabilidade do modelo distribuído com o controle centralizado do repositório remoto. É exatamente essa combinação que a alternativa A descreve.

Guarde a distinção fundamental: Git = distribuído, branches leves, snapshots, operações locais; SVN = centralizado, branches pesadas, dependente do servidor. É nessa fronteira que as alternativas se dividem — as que propõem SVN ou que limitam o uso do Git (proibindo branches/merge) falham em atender aos requisitos de colaboração modular e rastreabilidade.

Alternativa A — ✅ Correta ⟵ GABARITO

A alternativa A descreve exatamente a abordagem mais apropriada: Git distribuído com branches leves para cada módulo (infrações, notificações, permissões), tags para releases regulatórias, commit assinado (GPG) para auditoria e controle centralizado via repositório remoto oficial. Essa combinação atende a todos os requisitos do enunciado: rastreabilidade (histórico completo e imutável), auditoria (commits assinados), release estável (tags), branching para novos módulos (branches leves) e colaboração entre times (modelo distribuído com ponto central de integração). O Git garante a integridade do histórico por meio de checksums SHA-1, e o repositório remoto oficial assegura que todos os times trabalhem sobre uma base comum, sem comprometer a integridade.

Alternativa B — ❌ Incorreta

A alternativa B propõe SVN com trunk único para todos os desenvolvedores. O erro está em afirmar que "todo commit represente uma nova versão regulatória consolidada" — isso é inviável e inadequado, pois mistura o conceito de commit (alteração incremental) com o de release (versão consolidada). Além disso, o SVN centralizado com trunk único não oferece o branching leve necessário para desenvolver módulos em paralelo (infrações, notificações, permissões) sem interferência entre times. A centralização do SVN até poderia simplificar o controle, mas sacrifica a colaboração modular e a rastreabilidade distribuída que o Git oferece, tornando a alternativa inadequada para o cenário.

Alternativa C — ❌ Incorreta

A alternativa C propõe SVN com branches para cada módulo, criando cópias para desenvolvimento paralelo e mesclando ao trunk central ao final de cada iteração. Embora o SVN suporte branches, elas são cópias completas do diretório, o que as torna pesadas e menos eficientes que as branches leves do Git. Além disso, o SVN é centralizado: o histórico depende do servidor, e a colaboração distribuída (cada time com sua cópia completa) não é possível. Para um sistema crítico com múltiplos times e necessidade de auditoria, o Git distribuído é superior, pois permite que cada time trabalhe de forma independente e mescle suas alterações com mais flexibilidade e rastreabilidade.

Alternativa D — ❌ Incorreta

A alternativa D propõe Git em modo distribuído, mas limitado a um fluxo centralizado, sem ramificações complexas. O erro está em "sem ramificações complexas" — o enunciado exige branching para novos módulos (infrações, notificações, permissões), e a alternativa D elimina essa possibilidade. Embora o fluxo centralizado (todos enviam para o repositório oficial) seja uma prática válida e até recomendada para controle rígido, a proibição de ramificações impede o desenvolvimento paralelo de módulos, que é um requisito explícito do cenário. A alternativa A já contempla o controle centralizado via repositório remoto, mas mantém as branches leves, que são essenciais para a colaboração modular.

Alternativa E — ❌ Incorreta

A alternativa E propõe proibir o uso de merge e branches, com todo desenvolvimento feito por commit direto na linha principal. Essa abordagem é totalmente inadequada para o cenário, pois elimina a capacidade de desenvolver módulos em paralelo (infrações, notificações, permissões) e aumenta drasticamente o risco de conflitos e divergências entre os times. A justificativa de "evitar divergências" é falha: sem branches e merge, os desenvolvedores seriam forçados a trabalhar sequencialmente, o que inviabiliza a colaboração entre diferentes times e compromete a rastreabilidade (cada commit direto na linha principal dificulta identificar a origem e o propósito das alterações). O Git foi projetado exatamente para suportar branches e merge de forma eficiente, e proibi-los é um contrassenso.

Gabarito: letra A