Git e GitHub
Tags: git, github, beginners
Published: 2023-02-24 23:03:15

- [O que é Git](#o-que-é-git)
- [Onde o GitHub entra nessa história](#onde-o-github-entra-nessa-história)
- [Como isso se encaixa no dia a dia de uma pessoa desenvolvedora](#como-isso-se-encaixa-no-dia-a-dia-de-uma-pessoa-desenvolvedora)
  * [Concluir as configurações necessárias](#concluir-as-configurações-necessárias)
  * [Iniciar o projeto com o Git](#iniciar-o-projeto-com-o-git)
  * [Atuar no projeto](#atuar-no-projeto)
  * [Salvar minhas alterações](#salvar-minhas-alterações)
  * [Juntar o código novo com o código principal](#juntar-o-código-novo-com-o-código-principal)
  * [Atualizar o projeto local](#atualizar-o-projeto-local)
- [Resumindo](#resumindo)

## O que é Git

Segundo nossa querida [Wikipedia](https://pt.wikipedia.org/wiki/Git), o Git é um sistema de controle de versões distribuído. 

*E o que isso significa?*

Deixa eu tentar explicar com um exemplo:

Suponha que estamos trabalhando em uma plataforma muito grande, onde funcionalidades são atualizadas e criadas constantemente. Em determinado momento alguém fala para apagarmos uma funcionalidade que era difícil de manter e não estava sendo usada. Fazemos isso, simplificamos bastante coisa no nosso código e seguimos criando e atualizando outras coisas. Meses se passam e um belo dia alguém fala que vai precisar daquela funcionalidade que apagamos. E agora?

Se nosso projeto estiver usando o Git, podemos voltar na *ramificação* que tinha aquela funcionalidade (aquele “controle de versão” da definição da Wikipedia) e pensar em estratégias para integrar esse código apagado novamente. Não seria necessário criar tudo do zero.

Com o Git, cada pessoa que tiver *clonado* o repositório terá uma cópia local do histórico completo da versão do projeto. Alterações podem ser feitas na sua máquina e enviadas para o repositório principal depois, assim várias pessoas podem atuar no projeto ao mesmo tempo (inclusive no mesmo arquivo) sem que uma alteração afete os outros.

## Onde o GitHub entra nessa história

O GitHub é uma **plataforma** que usa Git. É como se alguém tivesse baixado o Git em um servidor, feito uma tela maneira, colocado algumas funcionalidades a mais e disponibilizado em nuvem pra gente usar. Assim como o GitHub, existem várias outras plataformas que usam o Git por trás dos panos, como o [GitLab](https://about.gitlab.com/) e [Bitbucket](https://bitbucket.org/).

## Como isso se encaixa no dia a dia de uma pessoa desenvolvedora

Falando sobre o *meu* dia a dia enquanto desenvolvedora, muita coisa gira ao redor do Git / GitHub.

### Concluir as configurações necessárias

Após instalado, precisamos configurar o Git. Sua configuração inicial precisa incluir o nome e email da autoria de mudanças enviadas por determinada máquina.

> `git config` - as configurações do Git precisam ser feitas apenas uma vez se usarmos a opção `--global` ou por diretório se usarmos a opção `--local`. [Existe uma lista enorme de coisas que podemos configurar](https://git-scm.com/docs/git-config/pt_BR), mas as principais são o nome (`git config --global user.name "Seu Nome"`) e email (`git config --global user.email "seu@email.com"`)

### Iniciar o projeto com o Git

Logo que começo a atuar em um projeto, uma das primeiras coisas a fazer é clonar o repositório e ler as instruções (normalmente encontradas no arquivo `README.md` na raiz do projeto).

> `git clone url_do_projeto` - clonar um projeto significa fazer uma cópia do repositório na minha máquina, para que eu possa acessá-lo e atuar nele localmente. Normalmente é uma ação feita apenas uma vez por projeto.

[O GitHub tem uma documentação boa sobre como clonar projetos](https://docs.github.com/pt/repositories/creating-and-managing-repositories/cloning-a-repository). A minha opção preferida é clonar via SSH já que não preciso ficar validando minha identidade repetidamente. [O GitHub também tem uma documentação detalhando como isso funciona.](https://docs.github.com/pt/authentication/connecting-to-github-with-ssh/about-ssh)

Caso seja um projeto 100% novo, posso criar a base dele na minha máquina para então iniciar o Git localmente e enviar para o repositório no GitHub.

> `git init` - iniciar um repositório também costuma ser uma ação feita apenas uma vez. Esse comando vai criar uma pasta chamada `.git` na raiz do projeto contendo todos os metadados do repositório e habilitar o uso dos demais comandos do git para aquele projeto.

Para criar o repositório no GitHub, basta seguir [a documentação deles](https://docs.github.com/pt/repositories/creating-and-managing-repositories/creating-a-new-repository) que não tem muita surpresa.

### Atuar no projeto

Uma vez que tenho o código disponível na minha máquina, posso começar a atuar em alterações. Para isso crio uma nova ramificação (ou *branch*) a partir da ramificação principal, normalmente chamada de `main`.

Um **branch** é um **snapshot** do código em determinado momento, uma "cópia" isolada do código tal qual está. Dessa forma podemos testar coisas, mudar comportamentos, etc, sem que nossas ações afetem as demais versões do projeto.

> `git checkout -b minha-tarefa` - o comando `git checkout`, quando usado dessa forma, é responsável por mudar de branch; a opção `-b` criará um novo branch com o nome informado a seguir (nesse exemplo, `minha-tarefa`).
> Vale comentar aqui que o `-b` veio como uma forma de chamar o comando `git branch` (que lista, cria, renomeia e exclui branches) junto ao `git checkout`.

### Salvar minhas alterações

Gosto de separar meu desenvolvimento em fases. Então assim que termino partes do que estou fazendo posso "nomear" aquele pacote de alterações e criar um histórico de coisas que executei.

> `git add [nome dos arquivos]` - primeiro é necessário falar quais arquivos vou incluir em determinado "pacote" de alteração, seja colocando o nome dos mesmos separados por espaço (ex.: `hello.html hello.css`), seja usando um `.` para incluir tudo de determinado diretório, ou `--all` para adicionar todos os arquivos alterados em todos os diretórios.

> `git commit -m "uma mensagem"` - depois de ter todos os arquivos selecionados, preciso adicionar uma mensagem que explica a alteração que foi feita.

Usando esses comandos, se alguma alteração que fiz der errado, posso consultar o histórico do meu branch e voltar para determinado ponto do desenvolvimento, se necessário for.

Bem, até então tudo o que foi desenvolvido está apenas na minha máquina e preciso enviar isso para o GitHub (ou qualquer outra plataforma que estiver usando). Normalmente costumo enviar as alterações que fiz ao final do dia (vai que minha máquina pega fogo, nunca se sabe...) ou quando o desenvolvimento está concluído.

> `git push origin minha-tarefa` - aqueles commits que fiz anteriormente serão "empurrados" do branch `minha-tarefa` da máquina local para o ambiente remoto (o repositório "origem" no GitHub), em um branch que também será chamado de `minha-tarefa`.

Dá pra usar o comando `git push` de algumas formas diferentes. Achei um [artigo da Trybe](https://blog.betrybe.com/git/git-push/) muito maneiro que entra em mais detalhes, caso queira.

### Juntar o código novo com o código principal

Uma vez que terminei tudo o que tinha para fazer naquela tarefa posso abrir um Pull Request (ou PR). Em resumo, o PR vai disponibilizar o código que eu criei para ser revisado por outras pessoas que trabalham comigo (e por mim mesma também) e, caso esteja tudo certo, juntá-lo ao código principal (ação chamada _merge_).

![Print da tela do GitHub no processo de abertura de Pull Request](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v6232hn3838l4i9m9l2y.png)

> Na imagem estamos abrindo um Pull Request no GitHub. Queremos juntar nosso código no código principal, então configuramos a base como `main` (o branch principal) e comparamos com o branch que atuamos, `minha-tarefa`. Para que as outras pessoas saibam o que aquele PR trata, colocamos um título resumindo a tarefa que estamos entregando e uma descrição explicando o objetivo daquele código, dando exemplos de como testar, adicionando detalhes importantes sobre as regras que aquele código deve seguir, etc.

[O GitHub tem uma documentação bem detalhada sobre como funciona esse processo](https://docs.github.com/pt/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests). Existem várias customizações que podem ser feitas, é bem legal.

### Atualizar o projeto local

Uma vez que terminei minhas alterações, preciso voltar para o branch principal e buscar a versão mais atual dele, para, só então, começar a trabalhar em uma nova tarefa.

> `git checkout main` - usado para voltar ao branch principal. Aqui não é necessário usar a opção `-b` pois a ramificação `main` já existe.
> `git pull origin main` - "puxa" para a máquina local todas as alterações que estiverem no branch `main` da origem, o repositório no GitHub.

## Resumindo

É difícil colocar todos os comandos do Git em um único post, mas esses são os principais do meu dia a dia. Vou deixar um resumo para download pra facilitar o acesso:

* [Baixar como PDF](https://drive.google.com/file/d/1_e2prG6ZG0k7e8rkGNfmbApnV8AmEvRc/view)
* [Baixar como imagem](https://drive.google.com/file/d/1893Dw_ohUJMfc4dA7ncSjY1RakV-4CDU/view)

Se aparecer qualquer dúvida pode colocar aqui nos comentários que tento responder assim que possível.

Até a próxima!