Escolha uma estratégia de fluxo de código

É importante escolher uma estratégia de fluxo de código que se adapte à maneira como sua equipe trabalha. Você tem várias estratégias a considerar. No final do módulo, você pode explorar opções. A equipe da web do Tailspin decide desenvolver uma estratégia de fluxo de código baseada no Git e no GitHub.

Quando a Teresa configurou os Quadros do Azure, ela e a equipa identificaram algumas tarefas iniciais a abordar. Uma tarefa era criar um fluxo de trabalho baseado em Git.

Captura de ecrã dos Painéis do Azure a mostrar as três tarefas iniciais.

Vamos ouvir a equipa enquanto tentam encontrar a melhor maneira de colaborar. Atualmente, eles estão usando um sistema centralizado de controle de versão, mas o plano é mudar para o Git, um sistema distribuído.

A Teresa está a trabalhar diligentemente nas funcionalidades que lhe foram atribuídas quando entra o Guilherme.

Andy: Oi Mara. Na reunião de liderança desta manhã, foi levantado que nossa equipe e a equipe de desenvolvimento de jogos estão usando diferentes sistemas de controle de versão. Para simplificar a forma como partilhamos recursos entre equipas, foi-nos pedido que mudássemos para um sistema de controlo de versão distribuído que pudesse lidar melhor com a colaboração.

Mara: É bom saber. Se você se lembra, nós colocamos em nosso quadro. Atualmente, estamos usando um sistema centralizado de controle de versão. Funciona muito bem para nós agora, mas concordo que um sistema de controle de versão distribuído é uma escolha melhor quando começamos a compartilhar entre as equipes e nossa equipe fica maior. Também é uma tarefa do nosso conselho aumentar a visibilidade para que todas as partes interessadas saibam o que todos estão fazendo. Eu acho que um sistema de controle de fonte distribuído como o Git também ajudaria.

Andy: Eu tenho querido experimentar o Git por um tempo. Parece que nunca tenho tempo. É difícil de aprender ou de configurar? Se lhe parecer razoável, poderíamos talvez trabalhar nele agora. Estou cansado de adiar sempre as coisas. E seria bom poder ver o que todos estão fazendo e ter acesso a todo o repositório. OK, em que é que ele consiste?

Mara: Deixe-me explicá-lo, e então você pode decidir se parece algo que queremos implementar imediatamente.

A Teresa e o Guilherme vão até ao quadro de comunicações para um debate sobre o controlo de versões.

O que é o Git e o controlo de versões distribuído?

Mara: O desenho à esquerda é o controle de versão centralizado, como o que estamos usando agora. Temos uma versão central da base de código no Controle de Versão do Team Foundation (TFVC) que todos usam. Cada um de nós trabalha nos arquivos que precisamos alterar e, em seguida, mesclá-los de volta ao repositório principal quando terminarmos com eles.

Andy: Sim, e isso está a funcionar para nós. Bem, exceto quando eu fui bloqueado naquele momento em que uma mudança de quebra foi mesclada no repositório central.

Mara: Certo! Você foi bloqueado . Poderíamos utilizar uma estratégia de ramificação com o TFVC para resolver o problema de bloqueio, mas na nossa configuração atual, a intercalação pode ficar um pouco mais complicado. E quando tivemos essa mudança de rutura, ninguém conseguiu fazer nenhum trabalho até que isso fosse resolvido. Esse problema está sempre à espreita, porque estamos todos usando a mesma cópia do código.

À direita está um desenho de controle de versão distribuído. Ainda temos um repositório central que é a versão estável da base de código, mas cada desenvolvedor tem sua própria cópia para trabalhar. Isto liberta-nos para experimentar e experimentar várias abordagens sem afetar o repositório central.

O controle de versão distribuído também garante que apenas o código de trabalho seja mesclado no repositório central. Podemos até configurá-lo para que o código não possa ser mesclado até que seja revisado.

O que é legal sobre o Azure DevOps é que ele funciona bem com sistemas de controle de versão centralizados e sistemas de controle de versão distribuídos.

Andy: O que acontece quando mais de uma pessoa altera o mesmo ficheiro?

Mara: Muitas vezes, o Git pode mesclar várias alterações automaticamente. É claro que queremos sempre garantir que a combinação de alterações resulte em código que funcione. Quando o Git não consegue intercalar automaticamente as alterações, há uma marcação dos conflitos diretamente nos ficheiros para que as alterações a serem aceites possam ser escolhidas por uma pessoa.

Andy: Neste momento, o nosso código é armazenado no nosso próprio servidor. Se passarmos a usar o controle de versão distribuído, onde o código será armazenado?

Mara: Fico feliz que você tenha perguntado. É aí que entra o alojamento.

Onde posso alojar o meu repositório?

Mara: Quando estamos decidindo onde hospedar nossos repositórios, temos algumas opções. Por exemplo, podemos hospedá-los em um servidor local, no Bitbucket ou no GitHub. Bitbucket e GitHub são soluções de hospedagem baseadas na web. Podemos aceder a essas soluções em qualquer lugar.

Andy: Já utilizou algum deles?

Mara: Eu usei o GitHub no passado. Ele tem recursos que são importantes para os desenvolvedores, como fácil acesso a logs de alteração e recursos de controle de versão a partir da linha de comando ou do portal online.

Andy: Então, como funciona o Git?

Como é que trabalho com o Git?

Mara: Como mencionei antes, com sistemas distribuídos, os desenvolvedores são livres para acessar qualquer arquivo que precisarem sem afetar o trabalho de outros desenvolvedores, porque eles têm sua própria cópia do repositório. Um clone é a sua cópia local de um repositório.

Quando trabalhamos numa funcionalidade ou numa correção de erro, normalmente, queremos experimentar diferentes abordagens até encontrar a melhor solução. No entanto, experimentar o código em sua cópia da base de código principal não é uma boa ideia, porque você pode não querer manter as primeiras tentativas.

Para lhe dar uma opção melhor, o Git tem um recurso chamado ramificação, onde você pode manter quantas cópias quiser e mesclar de volta apenas a que deseja manter. Esta opção mantém estável o ramo principal.

Andy: Eu entendo os conceitos até agora. Como é que dou entrada do meu código?

Como minhas alterações locais chegam à base de código principal?

Mara: No Git, a ramificação padrão, ou tronco, é normalmente chamada de main.

Quando sentires que o teu código está pronto para ser mesclado na ramificação do repositório central partilhado por todos os desenvolvedores, crias o que se chama de main. Ao criar uma solicitação pull, você está dizendo aos outros desenvolvedores que tem o código pronto para revisar e deseja que ele seja mesclado na main ramificação. Quando sua solicitação pull é aprovada e, em seguida, mesclada, ela se torna parte da base de código central.

Que aspeto tem um fluxo de trabalho de ramificação?

Andy: Tudo isto parece complicado e difícil de aprender.

Mara: O Git pode parecer intimidante porque é muito poderoso, mas depois de ganhares confiança com o fluxo, começa a parecer natural.

Você usará apenas alguns comandos diariamente. Aqui está um resumo:

Andy: Parece um ótimo ponto de partida. Sou definitivamente capaz de lidar com eles. Posso aprender comandos mais avançados à medida que precisar.