🥧 Git Pie: Aprenda sobre VCS · DevPunkDaSilva

Table of Contents

Nota do Autor
Introdução
- Versionamento de Código
Git
Cheat Sheet (Tabela de preguiçoso)
Links
Nota final

Nota do Autor

Olá pessoas, nesse texto irei falar sobre VCS (Sistema de Versionamento de Código, sigla em inglês) ou melhor, como o tema é mais conhecido - falarei sobre Git.

Introdução

Antes de falar sobre o Git precisamos entender o que seriam alguns conceitos básicos como Versionamento de Código.

Versionamento de Código

Versionamento é um conceito muito simples e usado no dia a dia de forma que nem percebemos. Por exemplo:
Estamos em um projeto onde temos dois desenvolvedores:

Stifler

Jim

Esses dois desenvolvedores estão fazendo o "Milfs Go" uma espécie revolucionaria e inovadora, além do tempo sendo um app para acharem a "milfs".

Aqui está uma milf para aqueles não habituados com o termo:

Assim eles começaram a projetar o aplicativo e vão para a parte prática, Stifler decidiu ficar o backend e Jim com o frontend, então depois que um deles termina sua feature (algo novo no sistema) ele zipa e envia para o outro e assim por diante. Não só isso, eles usam o Drive para guardar as versões do software. Além disso possuem uma pasta para as versões corretas e as de teste, tudo em "zip".

Pronto, agora você sabe o que é versionamento de código, é exatamente isto que os dois estão fazendo. Versionar é manipular versões tanto criá-las como acessa-las.

Controle de Versão

Versionamento é o ato de manipular versões, agora o Controle de Versão é um sistema que vai registrar as mudanças tanto num arquivo como em um projeto gigante ao longo do tempo.

Importância

Talvez agora você levante uma questão de o porque aprender "este trem" - como diria um amigo mineiro. Logo, a resposta é simples: esse tipo de ferramenta é essencial para o desenvolvimento já que nos entrega um poder de não somente trabalhar em conjunto de forma assíncrona e sem medo de acabar perdendo o que já foi feito.

Tipos

Com tudo que foi falado em mente agora precisamos entender que existem diferentes tipos de versionamentos, em que eles variam de acordo com a sua arquitetura.

Sistemas Locais

Esse tipo de sistema é mantido em uma maquina. Por exemplo, Jim vai fazer o versionamento da sua parte do frontend, onde ele possui um arquivo de checkout que vai servir para conferir/adicionar as versões e um banco de dados (poderia ser um outro arquivo) contento as versões que ele salvou.

Diagrama de um sistema local

Sistemas Centralizados

Estes sistemas nascem com a problemática que o Sistema Local trás que é justamente um não compartilhamento simultâneo, já que como no nosso exemplo esses dois teriam problemas de versões já que estarão em computadores diferentes

Mas se usarem um CVCSs (sigla em inglês para Sistemas Centralizados de Controle de Versão), com isso eles terão um repositório compartilhado em que todas as versões estarão e teremos os clientes que são os dois desenvolvedores.

Com isso, temos um grande ponto fraco que é justamente o fato de dependermos de um único servidor, caso o servidor caía, todas as versões iram cair.

Diagrama de um sistema compartilhado

Sistemas Distribuídos

Com isso os DVCS (Sistemas de Controle de Versão Distribuídos) se tornam um protagonista, já que os clientes não somente clonam os estados atuais, mas também fazem uma cópia completa de todo o repositório localmente.

Assim temos:

Os servidores, que vão guardar as versões e serviram como pilares para centralizar as versões
Os clientes que se tornam servidores também, já que eles podem pegar tudo do servidor principal

Diagrama de um sistema distribuído

Git

Senta que lavem história

Para começar a historia do Git é até bem curta e direta. A comunidade do Linux usava um VCS distribuído chamado BitKeeper só que ele é proprietário

Sim, um sistema open source usando um proprietário. Claramente isso era algo que causava um estranhamento na comunidade .

Que por sua vez chegou ao ápice quando o BitKeeper se tornou pago, logo a comunidade do Linux ficou alerta já que eles teriam que fazer o versionamento do núcleo do Linux em outro sistema.

Assim então a comunidade começou a criar seu próprio VCS que fosse:

Simples
Veloz
Não linear, ou seja, que aceite vários ramos (branches) de modificação
Capaz de lidar com grandes projetos, afinal, Linux é gigante

E assim nasceu o Git, exatamente em 2005 e até hoje está em evolução sendo um dos VCS mais utilizados em todo o mundo de desenvolvimento de gambiarras (softwares).

Ou seja, tudo nasceu de uma revolta popular

O básico

Vamos agora entender como o Git funciona internamente. Que por sinal trabalha de forma diferente de outros VCS.

Em um outro VCS ele terá os arquivos e quando houver alteração eles criam uma lista somente das alterações:

Agora com o Git ele faz diferente, já que vai tirando snapshots que são como fotos quando ocorre uma mudança e caso tenha algum arquivo que não foi alterado será guardado uma referencia para ele, assim pode ser recuperado.

Esta forma que o Git trabalha com os dados é chamada de stream of snapshots

Integridade

No Git todas as operações passam primeiro por uma checksum (soma de verificações) antes mesmo das alterações serem armazenadas, sendo referenciado por esse mesmo checksum. E para o checksum o Git usa o hash SHA-1.

Logo:

É impossível que algum arquivo seja alterado sem que o Git saiba

O SHA-1 é uma sequencia composta de 40 caracteres hexadecimais tal sequencia é calculada pela estrutura de pastas

Este hash estará em todo lugar do Git e ele não guarda o nome do arquivo e sim esse hash.

Estados

Agora vamos para uma das partes cruciais no Git, os estados (states) é como o Git está olhando para os arquivos, ou seja, como os seus arquivos vão estar.
Podendo estar em três estados:

Commited
Modified
Staged

Commited

Commited (comitado) é quando os seus dados estão já armazenados (de forma segura) no teu banco de dados local.

Modified

O modified (modificado) significa que teu arquivo foi modificado, mas ainda não foi para o estado commited, ou seja, não foi salvo no banco de dados.

Staged

O staged (preparado) é o estado intermediário entre o modificado e o comitado, sendo ele quando você adiciona os arquivos para serem comitados.

Assim temos dois níveis principais:

Diretório de trabalho
Área de preparo
Diretório .git que vai ser o repositório ou banco de dados local

Diretórios quando se trabalha com Git

O diretório de trabalho é só uma cópia de uma versão do projeto.
A área de trabalho é um arquivo dentro do diretório .git que vai armazenar as informações do seu próximo commit (o que será guardado)
O diretório .git é onde vão ficar os metadados e o banco de dados dos objetos do seu projeto (os snapshots)

Fluxo básico

Diretorio
de            Area
Trabalho      de Preparo     Repositorio .git 

|--|           |--|          |--| 
|--| --------> |--| -------> |--|
 modified         staged      commited

Agora vai 1.0

Instalação

Caso for Windows:
- https://git-scm.com/downloads/win
Caso for distros Fedora:

sudo yum install git-all

Caso for distros Debian:

 sudo apt-get install git-all

Configuração

Você não é o Douglas, eu sou Douglas:

Agora vamos definir a sua identidade já que é preciso disso porque as informações de usuário e e-mail para carimbar essas credenciais nos commits.

Faça assim:

git config --global user.name "Power Guido"
git config --global user.email [email protected]

O --global significa que o escopo dessas identificações serão usadas em todos os projetos

Pedir um help:

git help <verb>
git <verb> --help
man git-<verb>

Agora vai 2.0 versão final

Iniciar o repositório

Devemos o comando abaixo para iniciar o repositório para que o Git consiga ver os arquivos.

Nisso primeiro acessamos a pasta que é a raiz do repositório, no caso do Jim é o MilfsGo, então seria:

md MilfsGo # Cria a pasta
cd MilfsGo # acessa a pasta

Em seguida já inicia o repositório Git

git init

Assim ele vai criar um subdiretório com algumas informações básicas e um esqueleto do seu projeto.

Mas ainda o Git não estará monitorando seu projeto ainda.

Fazendo alterações

Agora vamos fazer alterações básicas como adicionar um README para o projeto.

README são arquivos geralmente em markdown (.md) para registrar a documentação do repositório com informações importantes como:

Nome

Descrição

Como usar

Etc

Vamos agora primeiro verificar o status do nosso repositório, antes de criar o README:

Vai exibir o status do repositorio como arquivos modificados ou no estado de preparo

git status

Resultado da execução do comando

Com isso vamos agora criar o arquivo README:

REDME.md

Fazendo a mesma verificação de statust teremos:

Assim temos o README.md na lista "Untracked files" que é quando ele não foi comitado ainda.

Para isso usaremos um outro comando para adiconar ele ao estado "staged":

git add .

Note que o comando add não retorna nada, mas ele adicionou todos os arquivos ao estado staged

O asterisco serve para indicar que vai ser adicionado todos os arquivos que estão modificado, mas você pode colocar o caminho do arquivo ou o nome, como:

git add README.md

Com isso podemos usar o status para ver o que temos:

Temos o README no estado de stage, ou seja, preparado para ser comitado.
Assim podemos finalizar o estado e comitar:

git commit -m "Adicionando o README"

Tome que:

o argumento -m significa que você vai passar uma mensagem
o que estiver dentro das aspas é a mensagem

Como você pode ver, Jim conseguiu fazer o commit.

commit é salvar a alteração no banco de dados (repositório do git)

Agora vamos verificar o log, usando o comando abaixo:

git log

Assim veremos o histórico de commits do repositório:

Quando aparecer está tela, apenas a parte q para sair dela

Log é o registro de algo, neste caso é o log dos commits

Relembrando o fluxo do que aconteceu:

Branches

Agora vamos ver sobre branches são essenciais para o desenvolvimento quando usamos o Git, uma branch é uma ramificação do repositório, ou seja, é uma copia do independente.

E usamos elas para conseguirmos colaboração em conjunto, para testarmos alguma funcionalidade que precise estar isolada ainda de estar em uso na aplicação e etc;

Ela é independente pois o que fazemos nela não influencia em uma outra.

Todo repositório começa com uma branch principal

Normalmente é chamada de main ou mater

Com isso, Stifler quer ver as branchs que tem no projeto:

# Exibira uma lista de todas as branches do repositorio
# E também vai destacar em qual branch você está
git branch -a

Para sair dessa tela basta apertar q

A branch com asterisco é a atual

Agora vamos criar uma branch:

git branch nova-branch

Agora veremos as branches criadas:

Logo vamos trocar para essa nova branch:

git checkout -m nova-branch

O checkout consegue fazer algumas coisas e uma delas quando passamos o argumento -m é para criar uma nova branch baseada na que estamos

Fizemos a troca da branch com sucesso

Para fazer uma troca de branches podemos usar o comando abaixo também:

git switch nova-branch

Agora vamos adicionar um arquivo neste repositorio:

Continua....

O artigo continua no dev.to por causa do limite de caracteres do Tabnews, mas confere lá que está massa:
Link: https://dev.to/punkdasilva/git-pie-aprenda-sobre-vcs-713