Uma introdução ao controle de versão e Git

Familiarizado com o Google Docs? Bem, se você estiver, é seguro assumir que você está ciente da pequena guia 'Histórico de versões', que permite que os escritores e as pessoas envolvidas verifiquem e acompanhem todas as alterações feitas no documento. em qualquer dado momento. Uma ferramenta útil, não é?

Agora imagine que em vez de uma folha cheia de parágrafos, há arquivos cheios de centenas de linhas de códigos. E ao contrário de um único documento, existem vários arquivos diferentes, constantemente atualizados.

Em um cenário como este, onde existem milhares de linhas de códigos em jogo e o resultado final, ou seja, o aplicativo Mobile é o que o futuro de uma empresa depende, torna-se ainda mais importante ter um software que mantenha uma guia de todas as alterações feitas nos arquivos de código.

É aqui que um Software de Controle de Versão entra em cena.

Por que o controle de versão é importante no desenvolvimento de software

Como o nome sugere, um software de controle de versão permite que os desenvolvedores de aplicativos móveis acompanhem as diferentes versões do ciclo de desenvolvimento de software e façam alterações nelas. Essa capacidade de rastrear todas as alterações que ocorrem no código e, em seguida, a opção de desfazer as alterações é o que torna o Controle de Versão uma parte importante do processo de uma empresa de desenvolvimento de aplicativos móveis que envolve vários desenvolvedores.

Agora quando se trata de Controle de Versão, existem vários softwares disponíveis no mercado atualmente. Vejamos alguns deles –

Software disponível para controle de versão

Embora em sua pesquisa do GitLab, o líder de software distribuído tenha constatado que 98% dos usuários fazem uso das ferramentas de código aberto Git e mais de 92% dos desenvolvedores usam o Git como linguagem de controle de versão no processo de desenvolvimento de aplicativos, há um número de razões pelas quais os desenvolvedores podem olhar para a alternativa do Git. Alguns desses motivos podem variar de – estrutura de preços do GitHub e o fato de o Github ser lançado em iOS e Android, uma aversão ao Octocat ou um nível de conforto simples com linguagem de controle de versão que não é Git.

Seja qual for o seu motivo, aqui estão as alternativas do Git para controle de versão –

Agora, mesmo quando há várias alternativas disponíveis para o Controle de Versão e na Appinventiv, temos uma experiência em primeira mão ao trabalhar em muitas delas, devido aos diversos requisitos dos clientes, somos de fato parciais em relação ao Git. Deixa-me dizer-te porquê.

Por que Appinventiv usa Git para controle de versão

1. Por sua velocidade relâmpago

De todos os softwares de controle de versão do mercado, a velocidade com que os elementos Git log e Commit funcionam é incomparável com qualquer outro. E quando sua equipe de desenvolvedores está trabalhando em uma plataforma, torna-se absolutamente necessário que o software seja rápido.

2. Para a capacidade de trabalhar offline

Quando você trabalha em um software que depende da Internet, pode ser arriscado quando você está em movimento e perde a conexão com o repositório central. Mas, este não é o caso do Git. Com o Git, você pode fazer quase todas as tarefas em sua máquina local – confirmar, navegar no histórico do projeto, criar ramificação ou mesclar.

3. Para Desfazer Alívio

O Git vem com um comando 'desfazer' que permite corrigir e reverter todo o commit. Na verdade, ele ainda oferece a opção de restaurar o commit 'excluído' através de sua opção Reflog.

4. Para o Backup

Quando a equipe trabalha no Git, cada clone que a equipe tem em sua máquina vem com um backup utilizável. Além disso, quase todas as ações do Git apenas adicionam os dados e não os excluem.

5. Para fazer commits úteis

Quando a nossa equipe de desenvolvedores comete um conjunto de mudanças não relacionadas – pegando alguns recursos de A, fazendo alguma correção de bug em outro – pode ser muito difícil para os outros membros da equipe entender o que aconteceu e pode ser difícil para eles reverter Os recursos de A se estiver causando problemas.

O Git resolve essa bagunça criando um commit granular. Através de seu conceito de 'área de teste', pode-se descobrir facilmente quais mudanças seriam incluídas no próximo commit, mesmo quando você está olhando para linhas únicas.

Então essas foram as cinco principais razões pelas quais usamos o Git aqui na Appinventiv. Agora que vimos o porquê, é hora de olhar para o Como. Como incorporamos o Git em nosso processo de controle de versão.

Vamos a isso agora.

Processo de controle de versão ao usar o Git

Criação de repositório

O objetivo do Git é gerenciar um conjunto de arquivos, também conhecido como Project. Para isso, o Git salva todas as informações na estrutura de dados conhecida como Repositório. Um repositório consiste nos códigos-fonte do aplicativo, nos recursos e nos conjuntos de dados. Basicamente, tem tudo o que define o projeto do aplicativo.

Agora, existem duas maneiras de obter um repositório no Git. Você pode usar um diretório local e convertê-lo em um repositório Git usando a linha de comando ou copiar um repositório Git já carregado no seu.

Quando você cria um repositório, geralmente tem duas opções – Público e Privado. O repositório público é aquele que pode ser visualizado por outros desenvolvedores usando o Git e o Privado, por outro lado, é aquele que só pode ser visualizado por algumas pessoas.

Ramificação

Ao lado de Criação de Repositório está Ramificação. Em uma empresa como a Appinventiv, onde a qualquer momento mais de 15 a 20 desenvolvedores estão trabalhando em um projeto, não é incomum que os desenvolvedores compartilhem o mesmo código-fonte e trabalhem nele. O que acontece é que, como alguns desenvolvedores estão ocupados corrigindo problemas, outros podem estar implementando alguns recursos.

Em uma situação como essa, precisamos de um sistema que facilite o manuseio de diferentes versões de código na mesma base de código.

É aqui que o Gitflow entra em cena. Gitflow é um framework usado para ramificação sistemática e eficiente.

Antes de continuarmos com o funcionamento do processo de ramificação no Gitflow, deixe-me explicar o conceito com um exemplo.

Suponha que haja 5 desenvolvedores em sua equipe e eles estejam trabalhando no desenvolvimento de um aplicativo semelhante ao Instagram. Agora, os recursos individuais do aplicativo, como suponha que Feed e Notificações, são indicados como Módulo 1, Módulo 2 e assim por diante. Agora esses diferentes módulos são branches de desenvolvimento, que depois de trabalhados são mesclados com o branch pai ou Master.

No momento em que um desenvolvedor adiciona uma ramificação, ele cria uma linha de desenvolvimento independente, que isola seu trabalho do trabalho dos membros de sua equipe. As diferentes ramificações são então mescladas na ramificação pai.

A ramificação é o método que permite aos membros da equipe identificar quais todas as mudanças devem esperar e é o que facilita o retrocesso.

Em nossos projetos, geralmente mantemos essas filiais –

• Filial Principal
• Ramo de Desenvolvimento
• Ramo de recurso
• Liberar Filial
• Hot Fixes e correções de bugs

Comprometer-se

As alterações que um desenvolvedor faz no arquivo individual são conhecidas como Commit. As alterações ou confirmação são adicionadas no repositório local e não no servidor. Em seguida, nossos desenvolvedores seguem o hábito de escrever uma mensagem de commit, onde a descrição do commit (alterações feitas no arquivo) é postada, para que outros desenvolvedores também conheçam os detalhes das alterações feitas no arquivo.

Empurre

Quando você confirma no repositório Git local, o que acontece a seguir é que as alterações são enviadas para o servidor, conhecido como Push .

É bastante fácil enviar o histórico de commits para o servidor quando você é o único trabalhando em um arquivo, mas caso haja outros desenvolvedores envolvidos no processo também, você terá que puxar as alterações antes de poder enviar seu conjunto de comprometa-se com o Git.

A seguir, veremos o que é feito na etapa Pull Change.

Solicitação de recebimento

Quando mais de um desenvolvedor está trabalhando no mesmo arquivo, o que acontece é que alguns commits podem ser enviados ao servidor pelo outro desenvolvedor antes de serem enviados. E quando isso acontece, o conflito acontece (mais sobre isso depois).

Para evitar carregar a mesma base de código duas vezes no servidor, os desenvolvedores primeiro extraem as alterações do repositório e garantem que os códigos sejam diferentes. Agora, geralmente, quando dois ou mais desenvolvedores trabalham no mesmo arquivo e enviam seu commit no servidor, surge a opção de 'Merge'.

Vamos falar sobre Mesclar a seguir.

Mesclar

Mesclar é a etapa em que os desenvolvedores unem todas as ramificações primeiro umas com as outras e depois com a ramificação mestre ou pai.

Toda vez que um delivery insere um comando Push, ele recebe uma opção Merge, que então pergunta a eles o branch com o qual eles gostariam de mesclar o commit.

Agora, no estágio Merge, a ocorrência de Conflict é muito comum. O conflito geralmente ocorre quando as duas ramificações que você planeja mesclar são alteradas na mesma parte do mesmo arquivo. O que acontece aqui é que o Git não consegue descobrir qual versão deve ser usada.

Quando esse problema de conflito ocorre, o Git oferece duas resoluções – Automática e Manual.

Como o nome diz, um é onde o Git descobre o problema e, neste último, os desenvolvedores precisam fazer isso manualmente. Na Appinventiv, nos concentramos na solução manual de conflitos, pois elimina até mesmo as chances mínimas de ocorrência de bugs.

Enquanto estamos usando o Git para fazer o controle de versão do nosso processo de desenvolvimento de aplicativos, o que acontece simultaneamente é o Issue Tracking.

Como somos um grande seguidor do Agile e confiamos no Agile para nosso processo de desenvolvimento de aplicativos móveis , entendemos a importância de lidar com vários processos de desenvolvimento ao mesmo tempo. E com o recurso de rastreamento de problemas, fica muito mais fácil para os testadores acompanharem em tempo real o código escrito e enviado no servidor Git.

Fazemos uso do quadro ZenHub para monitorar o fluxo de trabalho em cada repositório. O quadro nos permite acompanhar a prioridade da alteração sugerida e também ajudar os desenvolvedores a atualizar seus comentários no quadro em tempo real.