Práticas recomendadas para controle de versão

Esse é, de longe, o aprimoramento mais simples que você pode fazer no seu fluxo de trabalho, mas é o que causa mais dificuldades para alguns desenvolvedores. Ao trabalhar com outras ferramentas de gerenciamento de projetos, é provável que você já tenha dividido o trabalho em tarefas pequenas e gerenciáveis. Os compromissos devem ser tratados exatamente da mesma forma.

Um único commit deve estar relacionado apenas a uma tarefa ou ticket, a menos que uma única linha de código corrija magicamente vários bugs. Se estiver trabalhando em um recurso maior, divida-o em tarefas menores e faça confirmações para cada uma delas.

A maior vantagem de usar commits menores é que, se algo der errado, você poderá detectar e reverter alterações indesejáveis com muito mais facilidade.

As mensagens de confirmação descrevem o histórico do seu projeto. Afinal, é muito mais fácil encontrar a alteração que adicionou as tabelas de pontuação alta ao seu jogo se a mensagem de confirmação for "adicionei tabelas de pontuação alta ao menu" em vez de "aposto que você não consegue superar minha pontuação nessas novas tabelas!"

Ao trabalhar com um sistema de emissão de tíquetes de tarefas, como o Jira ou o GitLab, é ainda melhor incluir um número de tíquete em seu commit. Muitos sistemas podem ser configurados para trabalhar em conjunto com commits inteligentes, de modo que você possa realmente fazer referência a tickets e alterar o status deles a partir da sua mensagem de commit.

Por exemplo, um commit que diz "JRA-123 #close #comment task completed" definiria o tíquete do Jira JRA-123 como fechado, deixando o comentário "task completed" no tíquete.

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

O único momento em que "commit -a" (o comando do Git para "confirmar todas as alterações") ou qualquer um de seus equivalentes deve ser usado é no primeiro commit de um projeto. Normalmente, isso ocorre quando os únicos arquivos do projeto são README.md.

Uma confirmação deve incluir apenas arquivos relacionados à alteração que você está confirmando no repositório. Você deve ter um cuidado especial ao trabalhar com projetos Unity, pois algumas alterações podem fazer com que vários arquivos sejam marcados como alterados, como cenas, Prefabs ou Sprite Atlases, mesmo que você não tenha a intenção de fazer nenhuma alteração neles.

Se você acidentalmente fizer uma alteração em uma cena na qual outra pessoa está trabalhando, por exemplo, isso pode causar dor de cabeça para ela quando for fazer o commit das alterações e perceber que precisa mesclar as suas alterações primeiro.

Esse é um dos erros mais comuns que as pessoas que são novas no controle de versão cometem. É importante entender que você só deve confirmar suas próprias alterações no projeto. Para saber mais, confira esta postagem do blog sobre como acelerar seu fluxo de trabalho.

Sempre que fizer sentido, transfira as alterações mais recentes do repositório para sua cópia de trabalho. Não é uma boa ideia trabalhar de forma isolada, pois isso só aumenta a probabilidade de conflitos de mesclagem. Consulte 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 em vários locais.

As configurações de vários sites podem ser bastante exclusivas, com cada usuário trabalhando em um fluxo de trabalho centralizado ou distribuído.

Considere o exemplo a seguir:

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

Independentemente do VCS com o qual a sua equipe opte por trabalhar, certifique-se de que todos se sintam à vontade para usá-lo e compreendam as ferramentas à sua disposição.

Se estiver trabalhando com o Git, nem todos precisam usar o mesmo cliente GUI. Porém, torne 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 necessário para enviar apenas os arquivos de que precisam.

Se estiver trabalhando com o Plastic SCM, incentive os artistas da sua equipe a se acostumarem com o Gluon, uma interface gráfica amigável para simplificar o fluxo de trabalho. O Gluon permite que você decida os arquivos nos quais deseja trabalhar, eliminando a necessidade de fazer download e gerenciar todo o projeto. Ele também permite que você bloqueie arquivos, o que impede que outras pessoas trabalhem neles. Quando terminar, envie os arquivos de volta ao 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, a ramificação de recursos é altamente benéfica para o seu fluxo de trabalho. Muitas vezes, as equipes trabalham a partir do mesmo ramo de um repositório, provavelmente chamado de trunk, master ou main.

Quando você faz isso, todo o seu projeto se move ao longo da mesma linha do tempo. No entanto, pode ser útil dividir o trabalho em várias ramificações para colaborar de forma mais eficaz como uma equipe.

No Git, um fluxo de trabalho específico chamado Git Flow concentra-se no uso de diferentes ramificações para recursos, correções de bugs e lançamentos.

Portanto, se um desenvolvedor começar a trabalhar em um novo recurso dentro de uma ramificação isolada, ele será mesclado de volta à ramificação 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 apresenta ramificações de tarefas. Para esse padrão, você cria uma nova ramificação para cada tarefa que rastreia. No Git Flow, usamos branches de recursos para desenvolver recursos completos, às vezes grandes. As ramificações de tarefas no Plastic SCM devem ter vida curta. Se uma tarefa exigir mais do que alguns commits para ser implementada, é provável que ela 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 fluxo. Em seguida, você pode usar a visualização Stream Graph para criar novos fluxos. Todos os fluxos (exceto o fluxo principal) precisarão ter um fluxo principal, para que as alterações possam ser copiadas de volta para o fluxo anterior.

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

Depois de concluir o trabalho em um branch de recurso, é uma boa prática usar pull requests para colocar suas alterações de volta no fluxo principal do repositório. As solicitações pull são criadas pelos desenvolvedores do recurso ou da tarefa. Normalmente, é responsabilidade de um desenvolvedor sênior ou do DevOps revisar as alterações antes de aceitá-las na linha principal.

Tanto o Plastic SCM quanto o Perforce têm ferramentas automatizadas para ajudar a gerenciar a fusão de ramificações de volta à linha principal. O Plastic SCM faz isso com a ajuda do Mergebot, que mescla automaticamente as ramificações de um repositório depois que elas são revisadas e passam pela validação. O Perforce tem uma plataforma adicional, o Helix Swarm, usada para gerenciar revisões de código que também podem ser configuradas com testes automatizados.

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

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

Dessa forma, quando você começar a integrar outras ferramentas, como Jira, GitLab, ferramentas de compilação ou testes automatizados, o trabalho que você já fez ao estruturar o projeto e o fluxo de trabalho será útil.