# Aula 13 - Git e Github

## O que é Git?

O que é Git e Github?

Na aula sobre a internet, falamos sobre como eram os computadores no ínício da computação.


Eles ocupavam salas inteiras, a programação era feita utilizando cartões perfurados, apenas uma pessoa por vez para programar. A concorrência não era tão grande porque você utilizar um computador era caro, então, você precisava ter dinheiro ou ser influente. Bill Gates, por exemplo, vinha já de uma família rica, além disso, sua mãe participava de uma associação de pais que facilitou o acesso a ele a computadores. Se não fosse o bastante, ele descobriu um erro (um bug) que o permitia ficar incontáveis horas programando sem ser cobrado. Ele acumulou tantas horas programando que quando o verão terminou ele sabia bastante sobre programação.


Nessa época, não existia muito o contexto de você armazenar um programa de computador dentro de outro computador. Já quando os computadores modernos e pessoais chegaram ao mercado, a programação caseira (`homemade`) ganhou espaço. Com o avanço de internet, times passaram a existir em diversos pontos do mundo simultaneamente. E além disso, programas cada vez mais complexos requeriam não só formar de salvá-los mas também com a possibilidade de resgatar arquivos ou desfazer alterações de maneira inteligente.

Ao longo dos anos criaram-se várias soluções para o que chamamos de `versionamento de código`, uma maneira inteligente se salvar uma base de código. A mais famosa delas foi criada para resolver o problema de versionamento do maior dos sistemas operacionais do mundo, o Linux.

Hoje, o Linux está em todos os lugares, em televisões, em celulares, em computadores, em carros, em aviões, em usinas, na índústria, na Terra, no Espaço, em todos os lugares você tem Linux e isso é de fato, incrível. Mas um sistema operacional desse tamanho não estaria nesse nível se apoiar em fundações inteligentes.

Seu criador, Linus Torvald, estava pensando em formas de como salvar arquivos do projeto do `Kernel do Linux` (seu núcleo). Dizem que as alterações ao kernel do Linux eram passadas por patches ou arquivos pelo período de 1991 até 2001. Na versão 1.0 do Linux, em 1994, existiam 176 mil linhas de códigos e isso cresceu exponencialmente ao longo dos anos. Não apenas uma pessoa trabalhava no código, muitas vezes bugs (erros) eram inseridos no código fonte e era necessário resolver de uma forma rápida e com custo baixo. Mas como você faz isso em um grande grupo de texto com 176 mil linhas?

Uma nova funcionalidade pode ter até 13 mil linhas de código. Isso pode ser em novas linhas ou alterações em linhas de código bem antigas. E se isso quebrar alguma parte do Linux, como isso pode ser resolvido? É por isso que foi-se criado uma forma inteligente de você voltar no tempo. É, meio que uma máquina do tempo. A gente meio que sabe como funciona, você já deve ter usado o atalho `ctrl + Z` para desfazer algo que você achou que não deveria existir. E um pouquinho menos de vocês, conhecem o `ctrl + shift + Z` que desfaz algo desfeito. Você volta no tempo! Outro exemplo disso, é o histórico de alterações no Google Docs.

Linus Torvald, então, pensou em uma forma de salvar esses dados de uma forma daria para `voltar ao tempo`. Bastaria ele dizer qual o perído, ele conseguiria dizer quais alterações existiram no código. Em 2005, Linus lançou o `Git`, um software de `versionamento distribuido` (um software para voltar no tempo, salvar aquivos e de poderia ser usado de maneira colaborativa).

No final, não bastava apenas salvar. Precisamos sempre voltar no tempo, talvez refazer todo o trabalho já feito, e apagar a história e reescrevê-la.

Essa forma de voltar no tempo foi tão inteligente qu ele não permite a gente andar sob as linhas temporais, mas saber exatamente o que aconteceu, quando aconteceu, quem foi o autor daquele acontecimento.

Em resumo, Git é um software que vai permitir salvarmos nosso código e quando precisarmos, poderemos voltar no tempo para corrigir problemas ou erros.

Referência:

2020, The Linux kernel has around 27.8 million lines of code in its Git repository;
2019, 26.1 million of lines of code;
2015, June 2015, contains over 19.5 million lines of code contributed by almost 14,000 programmers;
1994, In March 1994, Linux 1.0.0 was released with 176,250 lines of code.

## O que é Github?

O `Github` é um portal que permite que projetos de programação sejam salvos assim como permite a relação entre pessoas ao redor do mundo com interesses em comum em programação criem projetos. Os projetos de código-aberto são uma das formas de atração, já que você consegue softwares muito bons e de maneira gratuita com suporte direto com seus desenvolvedores, possibilitando a leitura do código, o compartilhamento e novas funcionalidades a partir dessas relações.

Existem certos sites que passam a ser a página de frente para certas profissões.

Para designers em geral, temos o Behance, para ilustradores temos o Artstation, por muito tempo foi o DeviantArt. Gamasutra e r/gamedev para Desenvolvimento de Jogos. Parece que algumas profissões possuem certas comunidades como algo intrínseco a sua própria profissão. Isso não é diferente para desenvolvedores em geral. Existe hoje uma portal que conseguiu unir vários aspectos bem atraentes para nós, pessoas desenvolvedoras.

Não foi ao acaso. Em qualquer comunidade, gostamos de mostrar, dar e receber feedbacks, aprender e ensinar.

Apesar de não o primeiro portal para compartilhamento de código, Github revolucionou a forma de como o código-aberto funciona no mundo. Revolucionou como nos apresentamos como pessoas desenvolvedoras e como nos relacionamos com outras pessoas desenvolvedoras.

## Git vs Github

Agora conseguimos ver as diferenças entre Git e Github.

| | Git | Github |
| -------- | -------- | -------- |
| O que é? | Software distribuído em formato de ferramenta que permite versionar arquivos e voltar no tempo quando necessário para refazer códigos ou corrigir erros. | Software em formato de página web que permite colaboração e compartilhamento de projetos que utilizam Git como versionamento. |
| Código aberto ou fechado | Código aberto | Código fechado |
| Sobre a tecnologia | Git é uma das tecnologias de versionamento. Existem outras também como o Mercurial | Github é uma das plataformas que permitem o uso de Git e compartilhamento de código. Gitlab e BitBucket são outros.

E de uma maneira mais prática: Github utiliza Git por baixo dos panos para fazer compartilhamento do códigos. Github é uma interface amigável para que as pessoas consigam ver de maneira mais visual informações sobre projetos, códigos e pessoas. Enquanto git é a forma de como os códigos são salvos e usados pela comunidade ao redor deles.

## Criando um novo repositório;

Bom, como falamos, guardamos nossos registros, nossos códigos em repositórios, o que são nada mais do que equivalentes a um google drive mas utilizando um software bem diferente.

A maneira mais simples de criar nosso repositório é acessando [`Github`](https://www.github.com).

Certifique-se que você esteja logado e logo depois disso basta seguir os seguintes passos:

1. No canto direito superior, você deve encontrar os seguintes ícones, clique no `+` (sinal de soma).


2. Agora, selecione a primeira opção, `Create a repository` (Criar um repositório);


3. Agora, adicione as informações necessárias.


- `Repository name` refere-se ao nome do seu repositório;
- `Public` ou `Private` refere-se ao a permissão de pessoas poderem ter acesso ao seu código ou não. Público (`public`) significa que qualquer pessoa terá acesso, enquanto Private (`private`) o contrário, apenas pessoas que você definir podem ter acesso.
- Depois disso, basta apertar no botão `Create repostory`;
- Prontinho, você criou seu primeiro de muitas repositórios!

Se deu tudo certo, você deve estar nessa tela:


Agora, clique em `HTTPS` na sessão de `Quick setup` e copie o código que começa com `https://`, vamos usar mais a frente esse link.

### Clone de um repositório;

Agora que criamos um novo repositório, precisamos adicionar informações nele, certo? O primeiro passo é fazer com que as informações que estão no `Github` também estejam no seu computador.

Para isso, podemos `clonar um repositório`, que é nada mais do que fazer exatamente isso, fazer com que os códigos estejam dentro do seu computador também.

Podemos agora criar uma pasta (diretório) nosso computador e chamar ela de `cubos-academy`. E depois abrir essa pasta com o VSCode com a opção `Open wiht VSCode`.

Uma vez aberto, vamos abrir nosso `terminal`, um programa que podemos digitar códigos e ele vai executar ações. Para abrir o terminal do VSCode, basta na clicar na aba superior chamada Terminal e depois selecionar a opção `New Terminal` ou `Novo Terminal`.

Uma vez que você fez isso, deve abrir uma janela no seu VSCode desta forma:


Agora sim, podemos clonar um repositório com o comando `git clone` assim:

    git clone https://github.com/eowfenth/example.git

**Lembrando que você precisa ter o código do seu repositório, se você copiar o meu, você receberá um erro.**

Após digitar esse comando, você deve receber a seguinte mensagem:


Agora temos já uma nova pasta com o mesmo nome do nosso repositório. **Agora, feche seu VSCode e na sua pasta de repositórios da cubos-academy, clique com o botão direito e escolha a opção `Open with VSCode` ou `Abra com VSCode`.**

### Criando um novo arquivo com o VSCode

Agora com seu VSCode aberto na pasta do repositório, podemos adicionar um novo arquivo utilizando o VSCode. Para isso, basta clicar no ícone de novo arquivo como sinalizado na imagem abaixo. Dê o nome de `comidas_do_brasil.md`.


Clique no arquivo do lado esquerdo e escreva: `Feijoada`. Salve o arquivo e crie outro arquivo agora, `comidas_da_italia.md`. Escreve `Pizza` e salve o arquivo.

Logo depois, abra o `Terminal` do VSCode, como explicamos antes, e então,
digite `git status` e dê enter.

Devemos receber algo parecido como isso na resposta:


Essa mensagem quer quiser que existem dois arquivos que não estão sendo monitoradados (`tracked`).

**Observação:** Seu terminal vai dizer em qual pasta você está, se você não estiver na pasta do seu repositório, você vai receber um erro quando tentar dar `git status`.

### Escolhendo nossos arquivos para um novo commit;

Vamos agora decidir quais arquivos queremos que nosso registro (commit) tenha.

Para isso, já usamos o `git status` para ver quais os arquivos disponíveis, temos dois `comidas_do_brasil.md` e (`comidas_da_italia.md`). Vamos adicionar (`comidas_do_brasil.md`) primeiro. Na sessão de ícones laterais do VSCode, existe a opção do Git conforme a imagem abaixo:


Para isso, basta você na listagem dos arquivos, selecionar o arquivo (antes sinalizado com um `U`) clicando no ícone de `+` (sinal de soma).


Este arquivo agora estará listado em outro grupo`Staged Changes`. Nâo se preocupe sobre os nomes, ao longo do tempo vamos aprendendo. Agora que seu arquivo está nesse novo grupo, você **deve** digitar uma mensagem descrevendo o que esse registro significa ou fez dentro do seu código.


Vamos dizer que nosso código foi apenas uma documentação (uma forma de descrever como as coisa funcionam), da seguinte forma

    documentação: adicionada uma nova comida para as comidas brasileiras 


Depois disso, podemos apertar no botão de `check` (parece um um V-zinho), conforme a imagem abaixo.


Isso significa que criamos um novo registro (commit).

Isso significa que já podemos ver nosso código lá no Github? Não, ainda não.

Porque um `commit` é apenas a criação de um registro. Quando o criamos, apenas o criamos na sua máquina, no que chamamos de `local`.

Para colocar nossas alterações no `Github`, ou seja, no `remoto`, podemos clicar agora no `ícone cíclico` ou `de núvem` no canto inferior esquerdo da tela conforme a imagem abaixo. Ele vai pedir sua email e senha do cadastro do `Github` para isso possivelmente.


Pronto! Você pode ir lá no Github olhar seu novo código atualizado!

Uma vez que você fez isso, agora podemos repetir com as comidas da itália, que tal?

## Entendendo o que são boas mensagens de commit;

Agora que aprendemos o que é um `commit` e aprendemos que toda vez que queremos salvar alguma nova informação no nosso repositório, precisamos utilizar uma sequência de `add`, `commit` e então `push`.

Este processo de você fazer um novo commit e dar push, o que normalmente chamamos de `commitar`, de maneira geral, é bastante direto e até fácil de entender. No entanto, existem três verdades para mim e espero que de alguma forma elas signifiquem para você também:

1. Conseguir fazer com que as coisas funcionem;
2. Fazer com que as outras pessoas (e você mesmo) entenda porque ela funciona;
3. Ler código é muito mais difícil do que escrever código.

Sim, e eu concordo, fazer com que as coisas funcionem é mais importante. No entanto, raramente trabalhamos sozinhos e raramente olhamos apenas uma vez para o mesmo código. Por isso, não basta apenas fazer com que as coisas as funcionem, e pode até parecer conflitante, mas como pessoas desenvolvedoras precisamos:

- Fazer com que nosso código seja lido por humanos;
- Fazer com que o computador entenda o que estamos falando (o mínimo para que ele funcione adequadamente);

Mas talvez a gente não consiga fazer com que nosso código seja fácil de ser lido por humanos, mas sabe algo que sempre podemos fazer?

Utilizar da funcionalidade de histórico do Git **para não precisarmos lermos códigos** para entender o que está acontecendo em uma certa ocasião assim como entender todo o processo de evolução sem que a gente toque em um código. Por isso, a sua mensagem de commit deve `exatamente dizer o que aconteceu naquele commit (registro) da maneira mais sucinta possível`.

E como é uma maneira simples de criar uma mensagem de commit? Provavelmente por meio de um padrão, e este padrão são os `commits semânticos`

## Um padrão de mensagens para commit

Independente por onde você faça seus commits, utilizando seu VSCode ou mesmo utilizando uma ferramenta como uma linha de comando, você vai precisar adicionar mensagens descritivas ao seu commit e utilizando um padrão pode fazer com que você, seu time, e todo mundo que possa trabalhar no seu projeto entenda melhor o que ele significa.

Ao longo das próximas semanas, vamos aprender muito mais sobre `git` e por ora, vamos aprender o que é de ver o que é ter mensagens descritivas

Mas agora imagine que daqui a 2 meses você teve que voltar nesse código, e acredite, você não vai lembrar porque diabos você escreveu aquilo. E pior, você talvez não tenha tempo de estudar o porquê você fez aquilo.

Então, uma maneira prática de você entender como podemos utilizar um padrão é a seguinte: toda vez que você for criar um novo commit, defina uma categoria do que aquele registro significa:

- **funcionalidade:** uma nova funcionalidade sendo adicionada;
- **correção:** uma correção de um código;
- **documentação:** você está explicando como algo funciona;

Agora que você imaginou na sua categoria, adicione ela no início da sua mensagem de commit.

Então aqui estaria um exemplo para caso estivéssemos adicionando uma nova funcionalidade, utilizariamos um template (um modelo):

E se caso quiséssemos descrever uma correção? Aqui está:


E agora se fosse apenas uma registro de documentar (explicar) o comportamento de uma parte do nosso código?


Agora, vamos supor que temos uma lista de alterações feitas em um período. Não só isso, vamos ver lado a lado, a mesma lista sem commit semântico com commit semântico.

| Sem padrão | Commit Semântico |
| -------- | -------- |
| primeiro commit, adição da culinária brasileira | funcionalidade: primeiro commit, adição da culinária brasileira |
| adição da culinária espanhola | funcionalidade: adição da culinária espanhola |
| remoção de Pizza | correção: remoção de Pizza |
| adição da culinária argentina | funcionalidade: adição da culinária argentina |
| adição de choripan | funcionalidade: adição de choripan |
| remoção de Moqueca | correção: remoção de Moqueca |
| adição de Gazpacho | funcionalidade: adição de Gazpacho |
| adição de Churros | correção: adição de Churros |
| receita de Churros | correção: receita de Churros |
| associado Churros ao Brasil e Espanha | correção: associado Churros ao Brasil e Espanha |

Não sabemos se Churros foi adicionado pela primeira vez em `adição de churros` ou não. Utilizando um padrão, eu consigo dizer que foi uma correção e não uma funcionalidade, assim como os casos seguintes.

Eu consigo saber exatamente o que aconteceu em um dado período `sem sequer pensar sobre` e é exatamente o que precisamos, só nos importar e pensar no que realmente importa. Nesse exemplo, eu consigo saber que `associado Churros ao Brasil e Espanha` não se trata de uma nova funcionalidade, mas de uma correção. Agora assuma a dificuldade de projetos complexos e enormes como o próprio Linux, 37 milhões de linhas de código, o quanto pudermos evitar de ler código para sermos produtivos, melhor.

Então, destaquem-se ainda mais como pessoas desenvolvedoras e utilize desse modelo para descrever seus commits.