Práticas recomendadas para controle de versão

Esta é, de longe, a melhoria mais simples que você pode fazer em seu fluxo de trabalho, mas é a que alguns desenvolvedores mais têm dificuldade. Ao trabalhar com outras ferramentas de gerenciamento de projetos, é provável que você já tenha dividido o trabalho em pequenas tarefas gerenciáveis. Os commits devem ser tratados da mesma forma exata.

Um único commit deve se relacionar apenas a uma tarefa ou ticket, a menos que uma única linha de código conserte magicamente vários bugs. Se você estiver trabalhando em um recurso maior, divida-o em tarefas menores e faça commits para cada uma.

A maior vantagem de usar commits menores é que, se algo der errado, você pode detectar e reverter mudanças indesejadas muito mais facilmente.

As mensagens de commit descrevem a história do seu projeto. Depois de tudo, é muito mais fácil encontrar a mudança que adicionou tabelas de pontuação ao seu jogo se a mensagem de commit disser “adicionou tabelas de pontuação ao menu” em vez de “aposto que você não consegue superar minha pontuação nessas novas tabelas!”

Ao trabalhar com um sistema de tickets de tarefas como Jira ou GitLab, é ainda melhor incluir um número de ticket no seu commit. Muitos sistemas podem ser configurados para trabalhar juntos com commits inteligentes, para que você possa realmente referenciar tickets e mudar seu status a partir da sua mensagem de commit.

Por exemplo, um commit que diz “JRA-123 #fechar #comentário tarefa concluída” fecharia o ticket Jira JRA-123, deixando o comentário “tarefa concluída” no ticket.

Para mais informações sobre como configurar esse fluxo de trabalho, consulte a documentação no Jira ou o serviço Pivotal Tracker no GitLab.

A única vez que “commit -a” (o comando Git para “commit todas as mudanças”) ou qualquer um de seus equivalentes deve ser usado é no primeiro commit de um projeto. Normalmente, isso é quando os únicos arquivos no projeto são README.md.

Um commit deve incluir apenas arquivos que estão relacionados à mudança que você está fazendo no repositório. Você deve ter cuidado especial ao trabalhar com projetos Unity, porque algumas mudanças podem resultar em vários arquivos sendo marcados como alterados, como cenas, Prefabs ou Sprite Atlases, mesmo que você não tenha a intenção de fazer alterações neles.

Se você acidentalmente cometer uma mudança em uma cena que outra pessoa está trabalhando, por exemplo, isso pode causar dor de cabeça para ela quando for fazer o commit de suas mudanças e ver que precisa mesclar suas mudanças primeiro.

Este é um dos erros mais comuns que pessoas novas em controle de versão cometem. É importante entender que você deve apenas commitar suas próprias mudanças no projeto. Para saber mais, confira este post no blog sobre como acelerar seu fluxo de trabalho.

Sempre que fizer sentido, puxe as últimas mudanças do repositório para sua cópia de trabalho. Não é uma boa ideia trabalhar isoladamente, pois isso apenas aumenta a probabilidade de conflitos de mesclagem. Veja a tabela acima para ter uma ideia de um fluxo de trabalho diário típico para cada sistema.

Os fluxos de trabalho do Plastic SCM são um pouco diferentes porque você pode trabalhar em configurações centralizadas, distribuídas ou multisite.

As configurações multisite podem ser bastante únicas, com cada usuário trabalhando em um fluxo de trabalho centralizado ou distribuído.

Considere o seguinte exemplo:

• Duas equipes
• Cada equipe tem um servidor local
• Os membros da equipe fazem check-in localmente ou distribuído em cada site, mas se beneficiam da velocidade de um servidor local próximo
• Os servidores se comunicam entre si para permanecer totalmente ou parcialmente sincronizados

Independentemente do VCS que sua equipe escolher trabalhar, certifique-se de que todos estejam confortáveis em usá-lo e entendam as ferramentas à sua disposição.

Se você estiver trabalhando com Git, nem todos precisam usar o mesmo cliente GUI. Mas faça uma prioridade garantir que todos se sintam confortáveis com o fluxo de trabalho commit > pull > push. Em outras palavras, eles devem ter o conhecimento para fazer commit apenas dos arquivos que precisam.

Se você estiver trabalhando com Plastic SCM, incentive os artistas da sua equipe a se acostumarem com Gluon, uma GUI amigável para simplificar seu fluxo de trabalho. Gluon permite que você decida quais arquivos deseja trabalhar, eliminando a necessidade de baixar e gerenciar todo o projeto. Ele também permite que você bloqueie arquivos, o que impede que outros trabalhem neles. Uma vez que você tenha terminado, envie os arquivos de volta para o repositório e desbloqueie-os novamente conforme necessário.

Ao trabalhar em um projeto de longa duração com vários ciclos de lançamento, o branching de recursos é altamente benéfico para o seu fluxo de trabalho. Frequentemente, as equipes trabalham a partir do mesmo branch de um repositório, provavelmente chamado de trunk, master ou main.

Quando você faz isso, todo o seu projeto avança ao longo da mesma linha do tempo. No entanto, pode ser útil dividir o trabalho em vários branches para colaborar de forma mais eficaz como uma equipe.

No Git, um fluxo de trabalho específico chamado Git Flow foca em usar diferentes branches para recursos, correções de bugs e lançamentos.

Assim, se um desenvolvedor começar a trabalhar em um novo recurso dentro de um branch isolado, ele será mesclado de volta ao branch principal assim que terminar. Enquanto isso, outro colega de equipe pode fazer um hotfix na versão anterior, ou corrigir um bug, e lançar uma nova versão com segurança, sem incluir nenhum dos recursos ainda em desenvolvimento.

O Plastic SCM também possui branches de tarefa. Para esse padrão, você cria um novo branch para cada tarefa que você rastreia. Enquanto no Git Flow, usamos branches de recursos para desenvolver recursos completos, às vezes grandes. Branches de tarefa no Plastic SCM são destinados a serem de curta duração. Se uma tarefa levar mais do que um punhado de commits para implementar, é provável que possa ser dividida em tarefas menores.

O Perforce Helix Core usa um sistema chamado Streams para facilitar esse estilo de fluxo de trabalho. Ao criar um depósito para trabalhar, você precisa configurá-lo como um tipo de depósito de stream. Então, você pode usar a visualização do Gráfico de Fluxo para criar novos fluxos. Cada fluxo (exceto o fluxo principal) precisará ter um fluxo pai, para que as alterações possam ser copiadas de volta para cima.

Existem diferentes tipos de fluxos para diferentes propósitos. Quando você alterna entre fluxos em sua estação de trabalho local ou copia alterações de volta para cima, apenas os metadados dos arquivos alterados são mesclados, tornando a mudança de contexto mais rápida.

Uma vez que você tenha concluído o trabalho em um branch de recurso, é uma boa prática usar pull requests para trazer suas alterações de volta ao fluxo principal do repositório. Os pull requests são criados pelos desenvolvedores do recurso ou tarefa. Normalmente, é responsabilidade de um desenvolvedor sênior ou DevOps revisar as alterações antes de aceitá-las no fluxo principal.

Plastic SCM e Perforce têm ferramentas automatizadas para ajudar a gerenciar a mesclagem de branches de volta ao fluxo principal. Plastic SCM faz isso com a ajuda do Mergebot, que mescla automaticamente branches de um repositório uma vez que foram revisados e passaram na validação. Perforce tem uma plataforma adicional, Helix Swarm, usada para gerenciar revisões de código que também pode ser configurada com testes automatizados.

Mesmo que você esteja trabalhando em um projeto solo, os princípios de organização e controle de versão podem ser realmente úteis.

Ao trabalhar com uma equipe, é crucial priorizar uma comunicação clara. Como grupo, você precisa concordar com suas diretrizes: como deve estruturar seu projeto, qual sistema de controle de versão usar e como deve ser seu fluxo de trabalho nesse sistema.

Dessa forma, quando você começar a integrar outras ferramentas como Jira, GitLab, ferramentas de construção ou testes automatizados, o trabalho que você já fez estruturando seu projeto e fluxo de trabalho se destacará.