Git e GitHub: boas práticas de versionamento colaborativo
Gabarito: letra C. A abordagem recomendada para desenvolvimento colaborativo é criar uma branch para cada funcionalidade ou correção, realizar os commits e integrar à branch principal após revisão de código — o chamado feature branch workflow, que isola o trabalho em andamento e protege a branch principal de código não revisado. As demais alternativas violam boas práticas de controle de versão, seja por permissões excessivas, mensagens de commit pobres, trabalho direto na branch principal ou uso incorreto do Git Flow.
O Git é um sistema de controle de versão distribuído que trata os dados como um conjunto de imagens (snapshots) de um sistema de arquivos. Cada commit recebe um ID exclusivo de 40 caracteres (soma SHA-1), e o Git não remove dados, apenas adiciona novas versões. O projeto é organizado em três áreas principais: o diretório de trabalho (onde os arquivos são criados e editados), a área de preparo (staging area, que registra as alterações antes de serem salvas) e o repositório (que armazena permanentemente o histórico).
A prática central do desenvolvimento colaborativo moderno é o branching workflow: cada funcionalidade ou correção é desenvolvida em uma branch separada, isolando o trabalho em andamento. Isso permite que vários desenvolvedores trabalhem em paralelo sem conflitos constantes, e que o código seja revisado antes de integrar à branch principal. O fluxo típico é: criar a branch com git checkout -b nova-feature, fazer os commits das alterações, e integrar à branch principal com git merge (ou git rebase) após a revisão de código. Essa abordagem é recomendada tanto no GitHub quanto no GitLab, e é a base de modelos como o Git Flow e o GitHub Flow.
A revisão de código (code review) é um componente essencial desse fluxo: antes de integrar as mudanças à branch principal, outro membro da equipe analisa o código, identifica problemas e sugere melhorias. Isso aumenta a qualidade do software, dissemina conhecimento entre a equipe e reduz a probabilidade de introduzir falhas. No GitHub, isso é feito por meio de pull requests; no GitLab, por merge requests.
A pegadinha desta questão está em distinguir as práticas corretas das incorretas: a banca mistura comandos válidos do Git com usos inadequados. A alternativa C descreve exatamente o fluxo recomendado, enquanto as demais contêm erros conceituais ou de boas práticas. Guarde o critério: boas práticas de versionamento = branches isoladas + commits descritivos + revisão de código + integração controlada.
Alternativa A — ❌ Incorreta
Conceder permissões administrativas a todos os colaboradores é uma prática de segurança inadequada. O papel "Admin" no GitHub dá controle total sobre o repositório, incluindo configurações, exclusão de branches e gerenciamento de membros. Isso viola o princípio do menor privilégio: cada usuário deve ter apenas as permissões necessárias para sua função. A prática recomendada é conceder permissões de escrita (Write) para a maioria dos desenvolvedores e reservar o papel Admin para um grupo restrito de mantenedores.
Alternativa B — ❌ Incorreta
A mensagem de commit "Alteração rápida" é um exemplo de mensagem pobre e não descritiva. Boas práticas de versionamento exigem mensagens de commit claras e detalhadas, que expliquem o que foi alterado e por que, facilitando a compreensão do histórico e a rastreabilidade de mudanças. A alternativa inverte o conceito: mensagens objetivas não significam vagas, mas sim concisas e informativas.
Alternativa C — ✅ Correta ⟵ GABARITO
Esta alternativa descreve exatamente o feature branch workflow: criar uma branch para cada funcionalidade ou correção com git checkout -b nova-feature, realizar os commits necessários e integrar à branch principal com git merge após revisão de código. Esse fluxo isola o trabalho, permite desenvolvimento paralelo, facilita a revisão e protege a branch principal de código não testado ou não aprovado.
Alternativa D — ❌ Incorreta
Incentivar que todos trabalhem em uma única branch (master ou develop) é uma prática que gera conflitos constantes, dificulta o isolamento de funcionalidades e impede a revisão de código antes da integração. Além disso, nomear a branch com o nome do desenvolvedor é uma má prática: o nome da branch deve descrever a funcionalidade ou correção (ex.: feature/login, fix/bug-123), não o autor, pois o trabalho é colaborativo e o histórico de commits já registra a autoria.
Alternativa E — ❌ Incorreta
O comando git flow init deve ser executado uma vez por repositório, não "uma única vez para todos os membros da equipe" — cada desenvolvedor precisa inicializar o Git Flow em seu clone local. Além disso, o comando git flow feature publish MYFEATURE publica a branch da funcionalidade no repositório remoto, mas não "obtém uma funcionalidade publicada por outro membro"; para isso, o comando correto seria git flow feature pull ou git pull. A alternativa mistura conceitos e comandos de forma incorreta.
Gabarito: letra C — a única que descreve corretamente a abordagem recomendada para desenvolvimento colaborativo com Git e GitHub.