O Que um Merge Quebrado Me Ensinou Sobre Trabalhar em um Time de Desenvolvimento Real

Como parte da minha formação em Ciência da Computação na FECAP, eu e minha equipe construímos o MonkeyUp, um jogo de corrida 3D feito em Unity com C#. Embora todo mundo no time contribuísse em diferentes partes do projeto, eu fiquei majoritariamente responsável pela parte funcional do jogo, lógica de gameplay, mecânicas, performance. Foi a primeira vez que tive essa responsabilidade principal sobre o núcleo funcional de um projeto do qual outras pessoas dependiam, e isso me ensinou mais sobre colaboração do que qualquer trabalho individual já tinha ensinado.

Um dos primeiros problemas foi lag. Tínhamos objetos demais na cena, e o jogo começou a travar conforme a fase ia ficando mais cheia. Resolver isso não era sobre criar novas funcionalidades, era sobre voltar ao que já existia e deixar mais enxuto: reduzir a quantidade de objetos, repensar o que realmente precisava estar na cena versus o que era só excesso visual. Foi uma boa lição cedo de que “funcionar” e “funcionar bem” não são a mesma coisa.

A lição de verdade veio do Git. Eu estava trabalhando numa branch que ficou bem mais avançada que o resto do projeto, e acabei adiando o merge. Enquanto isso, meus colegas continuavam construindo em cima da branch principal, adicionando shaders e recursos visuais. Quando finalmente chegou a hora de mergear, o conflito foi grande o suficiente pra quebrar o projeto inteiro. Desembaraçar aquilo significou entender não só o que tinha mudado, mas por que dois conjuntos de mudanças não conseguiam coexistir, e que adiar demais o merge é um risco em si.

Além disso, em um outro momento, uma colega commitou e subiu uma estrutura de pastas quebrada, o que gerou mais problemas em cascata pelo projeto. Entre os dois episódios, aprendi na prática por que disciplina com Git, commits pequenos, merges frequentes, convenções claras de pastas, não é burocracia. É o que impede um projeto em equipe de desmoronar sob o próprio peso.

O MonkeyUp já foi entregue e está no GitHub, mas o verdadeiro aprendizado não foi o jogo finalizado, foi aprender a trabalhar com o controle de versão em vez de brigar com ele depois do estrago feito.

É um tipo de aprendizado diferente de construir algo sozinho. Escrever código que funciona é uma habilidade. Garantir que seu código não quebre o trabalho de outra pessoa é outra completamente diferente, e foi aqui que eu realmente comecei a aprender isso.