Escolher uma estratégia de fluxo de código
É importante escolher uma estratégia de fluxo de código adequada à maneira como sua equipe trabalha. Você tem várias estratégias a levar em consideração. No final do módulo, você pode explorar as opções. A equipe da Web da Tailspin decide desenvolver uma estratégia de fluxo de código baseada no Git e no GitHub.
Quando Clara configurou o Azure Boards, ela e a equipe identificaram algumas tarefas iniciais a serem realizadas. Uma tarefa era criar um fluxo de trabalho baseado em Git.
Vamos ver como a equipe está buscando uma maneira melhor de colaborar. Atualmente, eles estão usando um sistema de controle de versão centralizado, mas o plano é passar a usar o Git, um sistema distribuído.
Clara está trabalhando atentamente nos recursos atribuídos a ela quando Paulo chega.
Paulo: Olá, Clara. Na reunião de liderança dessa manhã, foi apontado que nossa equipe e a equipe de desenvolvimento de jogos estão usando sistemas de controle de versão diferentes. Para simplificar a forma como compartilhamos os recursos entre as equipes, nos pediram para mudar para um sistema de controle de versão distribuído capaz de lidar melhor com a colaboração.
Clara: É bom saber. Não sei se você se lembra, mas colocamos essa questão em discussão. Atualmente, estamos usando um sistema de controle de versão centralizado. Ele funciona muito bem para nós agora, mas concordo que um sistema de controle de versão distribuído é a melhor opção quando começarmos a compartilhar com outras equipes e a nossa equipe ficar maior. Também é uma tarefa de nosso painel aumentar a visibilidade para que todos os stakeholders saibam o que cada um está fazendo. Acho que um sistema de controle do código-fonte distribuído, como o Git, também ajudaria.
Paulo: Estou querendo experimentar o Git há algum tempo. Mas parece que nunca tenho tempo. Ele é difícil de aprender ou configurar? Se parecer razoável, talvez nós pudéssemos trabalhar nele agora. Estou cansado de sempre adiar as coisas. E seria bom poder ver o que cada um está fazendo e ter acesso a todo o repositório. E então, o que precisamos fazer?
Clara: Vou explicar, e você poderá decidir se parece algo que deveríamos implementar imediatamente.
Clara e Paulo vão para o quadro branco para conversar sobre o controle de versão.
O que são o Git e o controle de versão distribuído?
Clara: O desenho à esquerda representa o controle de versão centralizado, como o que estamos usando agora. Temos uma versão central da base de código 
no TFVC (Controle de Versão do Team Foundation) que todos usam. Cada um de nós trabalha nos arquivos que precisamos alterar e, depois, os mesclamos novamente no repositório principal quando terminamos de trabalhar neles.
Paulo: Sim, e isso está funcionando para nós. Quer dizer, exceto quando fui bloqueado daquela vez em que uma alteração interruptiva foi mesclada no repositório central.
Clara: Certo! Você foi bloqueado 
. Poderíamos usar uma estratégia de ramificação com o TFVC para resolver o problema de bloqueio, mas, em nossa configuração atual, a mesclagem poderia ser um pouco mais complicada. E quando ocorreu a alteração interruptiva 
, ninguém conseguiu trabalhar até resolvermos a questão. Esse problema está sempre prestes a acontecer, porque todos nós usamos a mesma cópia do código.
À direita, temos um desenho do 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 uma cópia 
própria na qual pode trabalhar. Isso nos libera para experimentar diversas abordagens sem afetar o repositório central.
O controle de versão distribuído também garante que apenas o código funcional 
seja mesclado no repositório central. Podemos até mesmo configurá-lo de modo que só seja possível mesclar o código revisado.
O que é legal no Azure DevOps é que ele funciona bem com sistemas de controle de versão centralizados e distribuídos.
Paulo: O que acontece quando mais de uma pessoa altera o mesmo arquivo?
Clara: Muitas vezes, o Git pode mesclar várias alterações automaticamente. Evidentemente, sempre queremos garantir que a combinação das alterações resulte em um código funcional. Quando não pode mesclar as alterações automaticamente, o Git marca os conflitos diretamente nos arquivos para que uma pessoa possa escolher quais alterações devem ser aceitas.
Paulo: No momento, nosso código está armazenado em nosso próprio servidor. Se passarmos para o controle de versão distribuída, onde o código será armazenado?
Clara: Que bom que você perguntou. É aí que entra a hospedagem.
Onde posso hospedar meu repositório?
Clara: Temos algumas opções quando estamos decidindo onde hospedar os repositórios. Por exemplo, podemos hospedá-los em um servidor local, no GitHub ou no Bitbucket. O GitHub e o Bitbucket são soluções de hospedagem baseadas na Web. Podemos acessá-los em qualquer lugar.
Paulo: Você já usou algum deles?
Clara: Já usei o GitHub. Ele tem recursos importantes para desenvolvedores, como acesso fácil a logs de alterações e recursos de controle de versão usando a linha de comando ou o portal online.
Paulo: E como o Git funciona?
Como eu trabalho com o Git?
Clara: Como eu disse antes, com sistemas distribuídos, os desenvolvedores ficam livres para acessar qualquer arquivo de que precisem sem afetar o trabalho de outros desenvolvedores, porque eles têm a própria cópia do repositório. Um clone é sua cópia local de um repositório.
Quando trabalhamos em um recurso ou em uma correção de bug, geralmente queremos experimentar diferentes abordagens até chegar à melhor solução. No entanto, experimentar códigos em sua cópia da base de código principal não é uma boa ideia, porque você não quer manter as primeiras tentativas.
Para oferecer uma opção melhor, o Git tem um recurso chamado ramificação, que permite manter quantas cópias você quiser e mesclar apenas a que quiser manter. Isso mantém a estabilidade do branch principal.
Paulo: Até agora, entendi os conceitos. Como eu faço check-in do meu código?
Como minhas alterações locais são enviadas para a base de código principal?
Clara: No Git, o branch padrão (ou tronco) normalmente é chamado de main.
Quando você achar que seu código está pronto para ser mesclado ao branch main no repositório central compartilhado por todos os desenvolvedores, crie o que é chamado de solicitação de pull. Quando cria uma solicitação de pull, você está dizendo aos outros desenvolvedores que tem código pronto para revisão e que deseja que ele seja mesclado com o branch main. Quando a solicitação de pull for aprovada e mesclada, ela passará a ser parte da base de código central.
Como é um fluxo de trabalho de ramificação?
Etapa 1: quando você começa a trabalhar em um novo recurso ou correção de bug, a primeira coisa que convém fazer é garantir que esteja começando pela base de código estável mais recente. Para fazer isso, você pode sincronizar sua cópia local do branch main com a cópia do servidor. Isso envia por pull para a cópia local todas as outras alterações de desenvolvedor que foram enviadas por push para o branch main no servidor desde a última sincronização.
Etapa 2: para garantir que esteja trabalhando com segurança em sua cópia do código, crie um branch apenas para esse recurso ou correção de bug. Como você pode imaginar, ter muitos branches para tudo o que está fazendo pode ser difícil de lembrar, portanto, é fundamental ter uma boa convenção de nomenclatura.
Antes de fazer alterações em um arquivo, faça check-out de um novo branch para saber que está trabalhando nos arquivos desse branch, e não de outro. Você pode alternar entre branches a qualquer momento fazendo check-out desse branch.
Etapa 3: Agora, você tem segurança para fazer as alterações que quiser, pois elas serão feitas apenas em seu branch. Conforme trabalha, você pode confirmar suas alterações no branch para garantir que não perca nenhum trabalho e poder reverter alterações que tiver feito em versões anteriores. Antes que possa confirmar as alterações, você precisa preparar seus arquivos para que o Git sabe quais deles você está pronto para confirmar.
Etapa 4: a etapa seguinte é efetuar push (ou fazer upload) do branch local para o repositório remoto (como o GitHub), de modo que outras pessoas possam ver no que você está trabalhando. Não se preocupe, isso ainda não mesclará suas alterações. Você pode efetuar push de seu trabalho sempre que desejar. Na verdade, essa é uma boa maneira de fazer backup de seu trabalho ou de permitir que você trabalhe de vários computadores.
Etapa 5: esta etapa é comum, mas não é obrigatória. Quando estiver convencido de que seu código está funcionando como desejado, você poderá efetuar pull do branch main remoto ou mesclá-lo novamente no branch main atual. Ocorreram alterações nele que seu branch main ainda não tem. Depois que você sincronizar o branch main remoto com o seu, mescle o branch main local ao branch de trabalho e teste o build novamente.
Esse processo ajuda a garantir que seu recurso funcione com o código mais recente. Ele também ajuda a garantir que seu trabalho será integrado perfeitamente quando você enviar sua solicitação de pull.
Etapa 6: agora, seu código local precisa ser confirmado e enviado por push para o repositório hospedado. Isso é o mesmo que ocorre nas etapas 3 e 4.
Etapa 7: finalmente, você está pronto para propor suas alterações para o branch main remoto. Para fazer isso, você inicia uma solicitação de pull. Quando configurada no Azure Pipelines ou em outro sistema de CI/CD, essa etapa dispara o processo de build, e você pode ver suas alterações se movimentarem pelo pipeline. Quando o build for bem-sucedido e outras pessoas aprovarem sua solicitação de pull, seu código poderá ser mesclado no branch main remoto. (Ainda fica a critério de um ser humano decidir se deseja mesclar as alterações.)
Paulo: Tudo isso parece complicado e difícil de aprender.
Clara: O Git pode parecer assustador por ser bastante avançado, mas depois que você entende o fluxo, ele começa a parecer natural.
Você usará apenas alguns comandos por dia. Segue um resumo:
| Categoria | Para executar essa tarefa | Use este comando |
|---|---|---|
| Gerenciamento de repositório | Crie um repositório Git | git init |
| Baixar um repositório remoto | git clone |
|
| Branch | Criar um branch | git checkout |
| Preparar e confirmar alterações | Ver quais arquivos foram alterados | git status |
| Preparar arquivos para confirmação | git add |
|
| Confirmar arquivos em seu branch | git commit |
|
| Sincronização remota | Baixar um branch de um repositório remoto | git pull |
| Fazer upload de um branch em um repositório remoto | git push |
Paulo: Parece um ótimo ponto de partida. Eu certamente consigo fazer isso. Posso aprender comandos mais avançados conforme precisar deles.