Imagine um desenvolvedor trabalhando em um projeto com outros colegas, utilizando o Git para controlar as versões do código-fonte. Ele precisa fazer uma alteração significativa em um módulo do sistema, mas não quer afetar o trabalho dos seus colegas enquanto desenvolve essa nova funcionalidade. Qual a sequência de comandos Git que ele deve executar para criar uma ramificação (branch) para desenvolver a nova funcionalidade, fazer as alterações e, posteriormente, integrar as alterações na ramificação principal (main)?
- A)git checkout main, git pull origin main, git branch nova-funcionalidade, git checkout nova-funcionalidade, git add ., git commit -m "Mensagem", git push origin nova-funcionalidade, git checkout main, git merge nova-funcionalidade
Certa, porque segue o fluxo completo de criação da branch, desenvolvimento, commit e integração final na main.
- B)git branch nova-funcionalidade, git checkout nova-funcionalidade, git add ., git commit -m "Mensagem", git checkout main, git merge nova-funcionalidade
Errada, porque cria e usa a branch, mas não mostra a preparação inicial da main nem o envio da branch ao repositório remoto, ainda que o fluxo básico local esteja quase completo.
- C)git init, git add ., git commit -m "Mensagem", git branch nova-funcionalidade, git checkout nova-funcionalidade, git push origin nova-funcionalidade
Errada, porque começa com git init, que serve para iniciar um repositório novo, e não para trabalhar em um projeto já existente com branch de funcionalidade.
- D)git status, git add ., git commit -m "Mensagem", git checkout main, git merge nova-funcionalidade, git push origin main
Errada, porque faz merge antes de indicar a criação e o uso correto da branch de desenvolvimento, além de misturar etapas sem a organização esperada.
- E)git checkout main, git branch nova-funcionalidade, git checkout nova-funcionalidade, git add ., git commit -m "Mensagem", git push origin main
Errada, porque até cria e usa a branch, mas termina com push na main sem mostrar a integração correta das alterações e sem o fluxo completo de merge.
Gabarito: A
Em Git, a ideia de branch é simples: você cria uma linha paralela de trabalho para mexer em uma funcionalidade sem bagunçar o restante do projeto. Assim, seu colega continua desenvolvendo no fluxo principal enquanto você testa, altera e comita sua parte em paz. Depois, quando tudo estiver pronto, você volta para a main e faz o merge para integrar as mudanças. A sequência correta precisa refletir exatamente esse caminho: entrar na main, criar a branch da nova funcionalidade, trocar para ela, fazer as alterações, salvar com commit e, por fim, voltar para a main e mesclar. Isso é o básico do fluxo de trabalho em Git usado em equipes e está totalmente alinhado com a lógica do versionamento distribuído. Por isso, o gabarito A está correto: ele começa com a atualização da main, cria a branch, muda para ela, realiza o add e o commit, envia a branch ao repositório remoto e depois retorna à main para executar o merge. É o roteiro clássico de desenvolvimento isolado e integração posterior. As outras alternativas erram por pular etapas, inverter a ordem, ou tentar fazer merge/push sem a preparação adequada. Em Git, a ordem importa, e muito - aqui, um comando fora do lugar já muda o filme inteiro.