Software Version Control & GIT
Seguindo com as publicações explorando o tema NetDevOps, nesta irei explicar o que é um software version control (SVC) e aprofundar um pouco mais em GIT. Se você ainda não leu o artigo de introdução ao tema, recomendo que leia aqui para melhor aproveitamento.
O termo version control é utilizado para descrever o processo em que se salva um arquivo, ou um conjunto de arquivos, para que seja possível identificar quando e quais alterações foram feitas neles. Um SVC normalmente é um banco de dados que salva tanto a versão atual quanto um histórico de versões de um código, o que possibilita com que vários programadores atuem ao mesmo tempo em um determinado projeto. A imagem a seguir exemplifica como funciona o workflow de um sistema de controle de versão.
Fonte: https://resources.pcb.cadence.com/blog/what-is-a-version-control-system
Em um time com diversos programadores, a utilização de um SVC possibilita que todos trabalhem de forma paralela, pois o version control irá proteger o código, uma vez que toda mudança será verificada em um processo chamado commit antes de mudar de hierarquia. Conforme exemplificado acima, o processo de hierarquia do código segue da esquerda para a direita conforme as alterações são "commitadas". A versão Alpha terá em seu código a feature A, mas não terá a feature B e correções que só foram disponibilizadas na última release.
Um aspecto importante de um sistema de controle de versão é a capacidade de realizar a ramificação (branch) e fusão (merge) de códigos construídos de forma independente. Isso é algo muito importante quando você está escrevendo parte de um código que pode conflitar com outras partes escritas por outro programador. Ao criar uma branch você, de fato, cria uma ramificação de trabalho que possui seu próprio histórico e não impacta o código principal. A figura 1.0 a seguir exemplifica esse fluxo:
Figura 1.0
GIT
Em 2005, Linus Torvalds (ninguém menos que o pai do Linux) se viu em uma situação incômoda quando a empresa dona do sistema BitKeeper decidiu parar de permitir a utilização gratuita de seu sistema no kernel Linux. Diante disso, e sem nenhuma outra opção open-source, Linus criou o GIT, projetado para ser rápido e escalável. Em 2006, sua criação foi passada para Junio Hamano e, desde então, se tornou o sistema de gerenciamento de código-fonte mais utilizado no mundo.
Embora seja uma associação muito comum, vale ressaltar que GitHub e Git não são a mesma coisa. O GitHub é uma plataforma online que permite que programadores compartilhem seus códigos de forma privada e/ou pública. Apesar de o GitHub utilizar o Git como sistema de controle de versão por trás de sua interface gráfica, ele não tem nenhuma ligação com o projeto open-source do Git.
Entender como o Git funciona é fundamental para conseguir utilizar de maneira efetiva o que ele proporciona de melhor. Conforme dito anteriormente, Git tem a escalabilidade em sua essência e essa característica é alcançada através da utilização de três estruturas, sendo elas:
- Local Workspace: Este é o local onde você armazena tudo o que você pode precisar como por exemplo arquivos de códigos, binários, documentação e até mesmo imagens.
- Staging área: Esta é uma área intermediaria de armazenamento para itens que ainda precisam ser sincronizados como por exemplo novos arquivos ou arquivos que sofreram alterações.
- Head, or local repository: Este é o local onde todos os arquivos já “commitados” serão armazenados.
Outro conceito importante do Git é o lifecycle, cada arquivo que for adicionado no diretório de trabalho tem um status atribuído que determinará como o Git irá tratar aquele arquivo. Esses status podem ser:
- Untracked: Quando um arquivo é criado em um diretório gerenciado pelo Git, ele recebe o status de untracked. Em outras palavras, mesmo que o arquivo exista no diretório, ele é invisível para o Git e nenhum controle de versão é performado. Para que se inicie o controle de versão, é necessário que isso seja dito de maneira explicita ao Git através do comando git add. Após isso o status do arquivo passará para tracked.
- Unmodified: Um arquivo com status tracked no repositório gerenciado pelo Git tem suas mudanças observadas. O status unmodified significa que o Git está observando o arquivo, mas nenhuma mudança foi executada.
- Modified: Assim que qualquer mudança é feita no arquivo, o Git irá alterar o seus status para modified. Status modified significa que alterações estão sendo feitas no arquivo e ainda não foram finalizadas. Quando as alterações são finalizadas é necessário dizer ao Git que o arquivo está pronto para ser enviado para o index ou staging área aplicando o comando git add novamente.
- Staged: Uma vez que o arquivo alterado é adicionado ao index, o Git precisa ser capaz de empacotar essas mudanças e atualizar o repositório local. Esse processo é chamado de staging e é executado através do comando git commit. Após esse processo o arquivo é enviado novamente para o status de tracked até que alguma mudança seja feita no arquivo, que após isso, iniciará todo o processo novamente.
Um programador pode consultar, a qualquer momento, o status de um arquivo em seu repositório do comando git status. A figura 2.0 a seguir exemplifica o processo de status lifecycle de um arquivo:
figura 2.0
Outra vantagem ao utilizar Git é a possibilidade de trabalhar com repositórios remotos realizando um clone deles para o seu próprio diretório. Dessa forma, sempre que realizar alterações nos códigos ou arquivos, você poderá enviar os arquivos para o index onde eles ficarão em status staging aguardando até que finalize suas mudanças. Após isso, o próximo passo será realizar o commit no seu repositório local e empacotar todas as mudanças para que seja realizado o push ao servidor remoto. Veja a seguir na figura 3.0 um exemplo desse workflow:
figura 3.0
À primeira vista todo esse processo pode parecer um pouco complicado e até nos faz pensar se é realmente necessário adicionar mais essa complexidade no processo de criação de códigos. Afinal, é possível criar um software sem utilizar um sistema de controle de versão? Não há dúvidas que sim, mas por que faria isso?
A ideia desse artigo foi apresentar o Git para aquele que, assim como eu, estão começando a se aventurar nesse mundo. Como de costume, fique de olho no canal Loopback0 pois em breve teremos um vídeo mostrando a utilizando do Git na prática. Garanto que depois que se acostumar com essa ferramenta nunca mais irá deixar de usar!
Ah, e lembre-se sempre:
Para todos que leram até aqui, deixo duas perguntas sobre o tema como forma de estudo e caso tenham dúvidas ou considerações, sintam-se à vontade para postar nos comentários.
1. Which of the following is true of software version control?
- It is a naming convention for software releases.
- It is also known as source code management.
- It is the same thing as BitKeeper.
- None os the above are true.
2. What are the three main structures tracked by Git?
- Index, head, and local repo.
- Local workspace, index, and local repository.
- Remote repository, head, and local index.
- None of the above
Se esse artigo te ajudou de alguma forma, peço que compartilhe e deixe seu kudos!
Comunidade Cisco
Aprender. Compartilhar. Crescer.
