Fluxo GIT descomplicado: Parte 1
Tags: git, tutorial, beginners, github
Published: 2022-08-16 06:50:00

### Esse tutorial é 100% prático.

Suponho que você já tenha o git instalado em seu ambiente de desenvolvimento. 

> Porque parte 1: Nessa parte vamos aprender tudo que precisamos saber para trabalhar com o git no nosso dia a dia. 

> Na parte 2: Vamos ver alguma peculiaridades a mais do git;

---

### Fluxo 1: Local

- Ok, vamos começar o nosso repositório com o 
```
git init
```

- Já trabalhamos na base do nosso projeto então vamos saber como as coisas estão
```
git status
```

- Ok! Vamos adicionar isso levando essas mudanças para o nosso repositório local:
```
git add .
```
Esse ponto representa tudo que foi listado, você pode passar apenas um repositório ou arquivo substituindo esse ponto pelo nome da pasta ou arquivo, mas eu não indico isso;

- Agora vamos commitar, dizer ao git para criar uma chave para essas adições que estamos fazendo os chamados blobs são um ponto de referência para aquelas alterações do momento
```
git commit -a -m "Status inicial da aplicação"
```

- Quer ver o que criamos? 
```
tree .git
```
vamos ver uma arvore com as chaves dos nossos commits. É interessante depois de pelo menos 2 commits para observar essas mudanças;

- Precisa chegar os commits realizados?
```
git log
```
---

### Fluxo 2: Levando para um servidor

- Se você tá levando para o github ou bitbucket as configurações são parecidas então: 
```
git branch -M main
git remote add origin https://github.com/seuusuario/seurepositório.git
```
Adicionei um repositório remoto e depois subi com as atualizações através desse comando: 
```
git push -u origin main
```
Em resumo suba uma cópia do branch origin para o main;

- Agora se você adicionar ou mudar algum arquivo, repita o FLUXO 1 e depois
```
git push
```

- Se alguém da sua equipe pegou o projeto em outra máquina e atualizou ele você vai usar o comando abaixo para baixar essas atualizações:

```
git pull
```
ou 
```
git pull --rabase
```
> Lembrando que o git pull nada mais é que um `git fetch origin` com um `git merge origin/master`. Se você usar o `git pull` sem o rebase fica mais fácil de usar o `git revert` depois. O rebase usamos muito quando vamos fazer o merge de um feature pois ele joga adição dessa nova feature para cima do histórico do git e deixa mais organizado (linear). 

- Contudo se tiver algum conflito de informações entre o novo código e o seu, exemplo: alterou uma linha ou mais das quais você já tenha trabalhado antes o git vai te alertar sobre isso, você pode fazer uma revisão do conteúdo, para ver se tá tudo ok. E se desejar sobrescrever as alterações use um 
```
git merge
```

---

### Fluxo 3: Trabalhando com funcionalidades

- Para criar uma nova funcionalidade na aplicação vamos criar um branch novo. Um novo caminho, então para criar um branch novo: 
```
git checkout -b exporta-csv
```
Seja descritivo, também podemos criar um branch para corrigir um bug ou fazer um hotfix (uma correção) podemos nomear desse modo também 
```
git checkout -b 'philipe/bug-caracteres'
```

- Para acessar esse novo caminho e começar a trabalhar dentro dele vamos acessa-lo: 
```
git switch exporta-csv
```

- Para ver uma lista de branchs locais: 
```
git branch
```
E você terá como saída:
```
* exporta-csv
  master
```

- Depois de trabalhar nessa nova funcionalidade e testar, vamos adicionar ela em nossa branch master. 
```
git switch master
``` 
Ou
```
git merge exporta-csv
```
> Nota: se abrir o vim editor depois disso, use `esq` e depos `:wq`, para fechar;

> Obs: Enquanto você trabalha no seu branch, outros desenvolvedores podem atualizar o branch main com o seu branch. Isso significa que seu branch não está mais atualizado em relação ao branch main e tem conteúdo em falta. Você pode fazer merge do branch main em seu branch executando checkout do seu branch e usando o mesmo comando git merge.

```
git checkout <branch name>
git merge main
```

- E agora atualizar em nosso servidor (lembrando que essas mudanças no código já deveriam ser atualizadas no servidor antes, trabalhando local e subindo para a nuvem). Repete o FLUXO 1 + 
```
git push --set-upstream origin philipe/bug-caracteres
```
Ou 
```
git push --set-upstream origin exporta-csv
```

> Obs: Se você criar um branch no seu repositório local, o repositório remoto ignorará a existência desse branch. Antes de poder fazer push do código do branch para o repositório remoto, você deve definir o repositório remoto como o branch upstream usando o comando git push. Simultaneamente, esse comando define o branch upstream e envia o conteúdo do branch para o repositório remoto.

```
git push --set-upstream origin <branch name>
```

- Temos mais um detalhe. Depois de fazer um merge em nossa nova feature (branch) é legar reescrever o histórico do git para que os nossos merges venham pra cima quando usarmos o git log, e fazemos isso assim: 
```
git rebase master
```

---

### Fluxo 4: Visualizando detalhes no nosso sistema git

- Para ver os caminho git criado em seu repositório:
```
cat .git/refs/heads/master
```
```
cat .git/refs/heads/exporta-csv
```

- Para ver em uma linha detalhes dos commits
```
git log --decorate --oneline --graph --all
```

---

### Fluxo 5: Indo e voltando

- Para editar o título do último commit realizado
```
git commit --amend
```
- Ok, agora para voltar ao estado de um determinado commit você vai usar o git log para pegar o hash de um commit para onde deseja voltar e depois é só usar o código:
```
git reset 25469779d814fcc740e1c29c3baf810e0f43ce25
```
> Obs: Se você tá trabalhando com muitas pessoas ou na master do seu repositório o ideal é usar o git revert passando o ponto de onde você deseja reverter.

- Para reverter:
```
git log --decorate --oneline --graph --all
```
Para analizar para onde você deseja reverte, copia o primeiro código da linha de onde você deseja reverter. Ex.: 2546977, não confunda com o hash *please.
```
git revert 2546977
```
Fazendo assim o histórico não é comprometido na master. Lembre-se a master é sagrada. Não podemos comprometer seu histórico. No github na sua pull request tem um botão de revert e ele ará abrir um novo pull request para executar esse revert. Falaremos mais sobre github no fluxo 6.

---

### Fluxo 6: Usando o github

- Pelo terminal você pode criar um repositório no github usando:
```
hub create meu-novo-projeto
```

- Use as issues do seu github para que as pessoas possam reportar problemas;
!['issues do github'](https://i.ibb.co/X2C4SQx/Captura-de-tela-2022-08-16-004200.png)

!['Abrindo issue do Github'](https://i.ibb.co/yntyFNs/Captura-de-tela-2022-08-16-004729.png)

- Organize, se preciso crie labels e personalize as já existentes, você encontra esse recurso nas opções laterais da issue;
!['Na lateral da issue tem as opções'](https://i.ibb.co/z2rnqLf/Captura-de-tela-2022-08-16-005412.png)

!['Criando/Personalizando uma label'](https://i.ibb.co/98nmPHd/Captura-de-tela-2022-08-16-005216.png)

> Dica: Crie também um lable para WIP (Working in progress) que serve pra sinalizar que você ainda está trabalhando no código. 

- Crie pull requests no código, vá até o arquivo que deseja fazer um pull request, ao invés de dar um commit direto, crie um pull request conforme as imagens abaixo, ele vai te dar um resumo e você pode lançar essa pull request;

!['Passo 1'](https://i.ibb.co/Mk2Dy26/Captura-de-tela-2022-08-16-010431.png) !['Passo 2'](https://i.ibb.co/qMH70dB/Captura-de-tela-2022-08-16-010809.png) !['Passo 3'](https://i.ibb.co/wMw3pRm/Captura-de-tela-2022-08-16-011140.png)

- Ao abrir a minha pull request, vemos que o boot da versel (host CI/CD) já atualizou o diretório e logo abaixo eu posso fazer um merge para atualizar o nosso diretório principal e por fim finalizar essa pull request se for o caso. Lembrando que o ideal na criação da nossa pull request é criar uma descrição do problema para que tudo fique bem documentado;

!['Parte 1'](https://i.ibb.co/tC0hxH4/59737d01-8e70-4198-b9ad-a20398fcd64c.jpg) !['Parte 2'](https://i.ibb.co/tLzgpY2/ec3844db-396e-4458-8746-95150cea055a.jpg)

> Dica: Adiciona no repositório .git um template para as issues e para os pull requests. Vou deixar esse link de referência: https://github.com/facebook/react/blob/main/.github/ISSUE_TEMPLATE/bug_report.md

- Use plugins para te ajudar com essa experiência dos pull requests e themas. Vou indicar esses dois: Octotree: https://chrome.google.com/webstore/detail/octotree-github-code-tree/bkhaagjahfmjljalopjnoealnfndnagc, e Octotree Theme: https://chrome.google.com/webstore/detail/octotree-theme/meagmbmaaljhgdcglcmflnnglpokldcj

Abri os dois aqui para uma melhor compreensão
!['Octotree e Octotree Theme juntos'](https://i.ibb.co/gWLZWLd/Captura-de-tela-2022-08-16-020539.png)

- Depois de fazer um merge da nossa fixure do nosso pull request com o nosso master temos a opção de reverter

!['Repare o nosso botão de reverter'](https://i.ibb.co/2jF2qcD/Captura-de-tela-2022-08-16-024453.png)

---

Espero que tenham gostado desse post, comentem e me sigam nas minhas redes sociais, quero muito com esse projeto passar conteúdo de qualidade e no Medium conteúdo mais focado para Stackholders com um formato mais simples.

> Confira a parte 2 em: https://dev.to/magominimalista/fluxo-git-descomplicado-parte-2-3dn1

Att,

#### Sobre o autor:
- Philipe Cairon (Mago Minimalista)
- Full Stack Web developer

Me encontre no Linktree: [!['Linktree'](https://img.shields.io/badge/linktree-39E09B?style=for-the-badge&logo=linktree&logoColor=white)](https://linktr.ee/magominimalista)