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.
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: Olá 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 há algum 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 explicar, e então você pode decidir se soa como 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 é um 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á funcionando 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 do controlo de versões 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 arquivo?
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: No momento, nosso código é armazenado em nosso próprio servidor. Se passarmos a usar o controle de versão distribuído, onde o código será armazenado?
Mara: Ainda bem que você perguntou. É 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: Você já usou 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 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 mainde .
Quando você sente que seu código está pronto para ser mesclado main na ramificação no repositório central que é compartilhado por todos os desenvolvedores, você cria o que é chamado de pull request. 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?
Passo 1: Quando você começa a trabalhar em um novo recurso ou correção de bug, a primeira coisa que você quer fazer é garantir que você está começando com a base de código estável mais recente. Para tal, pode sincronizar a sua cópia local do ramo main com a cópia do servidor. Isso puxa para sua cópia local todas as outras alterações de desenvolvedor que foram enviadas para a main ramificação no servidor desde a última sincronização.
Etapa 2: Para garantir que você está trabalhando apenas em sua cópia do código, crie uma nova ramificação apenas para esse recurso ou correção de bug. Como você pode imaginar, ter muitos ramos para todas as coisas que você está fazendo pode ficar difícil de lembrar, então usar uma boa convenção de nomenclatura é fundamental.
Antes de fazer alterações em um arquivo, você faz check-out de uma nova ramificação para saber que está trabalhando nos arquivos dessa ramificação e não de uma ramificação diferente. Pode alternar entre ramos em qualquer altura ao dar saída desse ramo.
Passo 3: Agora você está seguro para fazer as alterações que quiser, porque essas alterações estão apenas no seu ramo. À medida que trabalha, pode confirmar as alterações na sua ramificação para garantir que não perde trabalho e para fornecer uma forma de reverter quaisquer alterações que tenha feito em versões anteriores. Para poder consolidar as alterações, tem de testar os ficheiros, para que o Git saiba qual é o ficheiro que está pronto para a consolidação.
Etapa 4: A próxima etapa é enviar ou carregar sua filial local até o repositório remoto (como o GitHub) para que outras pessoas possam ver no que você está trabalhando. Não se preocupe, esta operação ainda não intercala as alterações. Pode enviar o seu trabalho sempre que quiser. Na verdade, essa é uma boa maneira de fazer backup do seu trabalho ou permitir-se trabalhar a partir de vários computadores.
Passo 5: Este passo é comum, mas não obrigatório. Quando estiver satisfeito que seu código está funcionando como você deseja, você pode puxar, ou mesclar, a ramificação remota main de volta para sua ramificação local main . Aí têm ocorrido alterações que o seu ramo main local ainda não possui. Depois de sincronizar a ramificação remota main com a sua, mescle a ramificação local na ramificação de main trabalho e teste a compilação novamente.
Este processo ajuda a garantir que a funcionalidade funciona com o código mais recente. Também ajuda a garantir que o seu trabalho será integrado suavemente ao submeter o pedido Pull.
Etapa 6: Seu código local agora precisa ser confirmado e enviado para o repositório hospedado. Este passo é igual aos passos 3 e 4.
Passo 7: Você está finalmente pronto para propor suas alterações para a filial remota main . Para tal, deve iniciar um pedido Pull. Quando configurada no Azure Pipelines ou em outro sistema de CI/CD, esta etapa aciona o processo de compilação e você pode observar suas alterações se moverem pelo pipeline. Depois que a compilação for bem-sucedida e outras pessoas aprovarem sua solicitação pull, seu código poderá ser mesclado na ramificação remota main . (Ainda cabe a um ser humano mesclar as mudanças.)
Andy: Tudo isso parece complicado e difícil de aprender.
Mara: O Git pode parecer intimidante porque é muito poderoso, mas depois que você pega o jeito do fluxo, ele começa a parecer natural.
Você usará apenas alguns comandos diariamente. Aqui está um resumo:
| Categoria | Para realizar esta tarefa | Utilizar este comando |
|---|---|---|
| Gestão do repositório | Criar um repositório Git | git init |
| Transferir um repositório remoto | git clone |
|
| Filial | Criar um ramo | git checkout |
| Testar e consolidar alterações | Ver que ficheiros foram alterados | git status |
| Testar os ficheiros a consolidar | git add |
|
| Consolidar os ficheiros no ramo | git commit |
|
| Sincronização remota | Transferir um ramo a partir de um repositório remoto | git pull |
| Carregar um ramo para um repositório remoto | git push |
Andy: Isso soa como um ótimo ponto de partida. Sou definitivamente capaz de lidar com eles. Posso aprender comandos mais avançados à medida que precisar.