Fala galera,
Continuando uma ideia que iniciei em um post que postei há um tempão, sobre sistemas de controle de versão, hoje vou falar sobre aspectos básicos do Git. Boa leitura!
Uma breve história do Git, e como ele funciona
O Git, segundo site oficial, nasceu de uma maneira um pouco controversa. Para entendermos como isto aconteceu, vamos voltar um pouco antes do nascimento do Git.
O Linux foi desenvolvido sem usar um controlador de versões. As alterações eram distribuidas em forma de patches e arquivos. Apartir de 2002 o projeto passou a utilizar um controlador de versões proprietário chamado BitKeeper.
Porém, a relação entre a comunidade do Linux e os proprietários do BitKeeper foi se deteriorando até acabar. As ferramentas da empresa que a princípio eram free, passaram a ser cobradas. Este fato deixou muita gente brava, inclusive nosso ilustre amigo Linus Torvalds. Isto na verdade foi uma coisa boa, pois este desentendimento fez o pessoal do Linux pensar em uma ferramenta própria baseada no que eles tinham aprendido durante o tempo do BitKeeper.
Para alcançar o objetivo, traçaram algumas metas:
- Velocidade
- Design Simples
- Forte suporte a desenvolvimento não linear (milhares de branches trabalhando em paralelo)
- Amplamente distribuído
- Ter a capacidade de trabalhar com projetos do porte do Linux Kernel (afinal, foram eles que desenvolveram!)
Então, em 2005 nasceu o Git.
Apesar de ter várias semelhanças com o CVS e Subversion (entre outros), o Git é conceitualmente diferente. Explicando de uma maneira bem fácil de entender: o CVS trata a informação como uma série de arquivos que mudaram com o tempo. É assim que ele guarda as informações. O Git funciona um pouco diferente: em vez de guardar o arquivo propriamente dito, o Git tira uma “snapshot” de como o arquivo se parecia no momento. Esta informação é guardada. Em um caso onde algum arquivo não tenha sido alterado da versão A para B, ele não vai ser mantido duas vezes. Um link é criado de uma versão para outra. Seguindo na contramão dos controladores de versão, o Git não aproveitou o conceito dos seus antecessores criando o seu próprio.
Outro aspecto interessante do Git, é que em termos de velocidade ele também sai na frente. Uma vez que a maioria das operações são locais, não temos latência de rede. Um desenvolvedor pode dar commits de dentro de um avião por exemplo, e assim que conseguir uma conexão com a internet, pode fazer upload de suas alterações (isto sim é vantagem! hehehe).
Sobre segurança de informação posso destacar que o Git faz um controle baseado em checksum (SHA-1 hash) nas interações usuário x servidor, então é praticamente impossível alterar algo no servidor “despercebidamente”.
Vale falar também que a maioria das operações que o Git faz somente adiciona dados. Então, uma vez que a informação está no servidor, fica difícil perder algo – literalmente falando.
Mais um ponto que deve ser destacado: os três estados que um projeto pode assumir: commited, modified e staged.
- Quando você faz um commit no Git, significa que salvou seus arquivos no seu servidor local.
- Quando você faz um modify, significa que você fez alterações, mas estas ainda não estão salvas localmente.
- Quando um arquivo esta “staged” significa que você fez alterações (ou seja, esta com um arquivo modified) e estas estão prontas para serem comitadas na próxima iteração com o servidor.
Tendo explicado estes três estados, podemos entender mais facilmente as três seções de um projeto Git: o diretório Git (Git Directory), o diretório de trabalho (Working Directory) e o Staging Area.
- O Git Directory é o diretório mais importante. Nele ficam guardados os metadados e demais objetos relacionados ao seu projeto. Quando você clona um diretório de um computador para outro, este Git Directory é copiado.
- O Working Directory é um checkout de uma versão de um projeto. Os arquivos são extraídos do database do Git Directory e colocados em disco para que o usuário possa modificar.
- O Staging Area é um arquivo, normalmente dentro do seu Git Directory, que guarda informações que farão parte do seu próximo commit.
E agora, para fechar o artigo, vamos ver como ficaria o workflow de um projeto:
- Modificar arquivos no Working Directory
- “Stage” os arquivos, preparando o próximo commit
- Commit, onde os arquivos são resgatados da Staging Area e salvos no Git Directory.
Isto é o básico sobre a teoria do Git, um exemplo de Sistema de Controle de Versões Distribuído. Para usá-lo, existem duas saídas: ou usar o Git com linhas de comando, onde todo o set de comandos está disponível, ou então baixar um programa do tipo GUI, onde existe uma interface gráfica que implementa estes comandos.
No próximo post, vou mostrar um exemplo prático no mais famoso dos Gits, o Git Hub.
Fonte: https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git
Sanoj's devLab 