# Guia de Git

## **Pull Request**
Uma **Pull Request** é uma mensagem enviada para colaboradores e mantenedores do repositório para revisar o seu código antes que você o envie (dê push) ou o mescle com o código do projeto (dê merge).

Isso é uma prática muito boa, afinal só se aplica mudanças apenas quando o código tenha sido testado e verificado.

O PR (Pull Request) ou MR (Merge Request) age como uma parte isolada onde a revisão do código ocorre, ou seja, nada que seja alterado no PR afeta o projeto.

As mudanças só vão ser levadas (por merge) para o software se tudo estiver de acordo.

## Como fazer uma Pull Request
Antes de fazer uma Pull Request, você precisa ter uma branch que contenha as mudanças que você quer implementar, nesse exemplo usaremos a branch *cadastrousuario* e queremos dar merge dela na branch *main*.
<!---->
para
<!---->

No **GitLab** você pode fazer uma Pull Request na aba **Merge Requests** do seu projeto e então clicar em **New Merge Request**
<!--[](https://hackmd.io/_uploads/HkxOGrrBn.png)
-->

Então você será levado para essa tela, que tem como objetivo comparar as branches da fonte com o alvo.
<!---->

Vale lembrar que se você criar uma Merge Request diretamente de uma branch, ela não te levará para esta tela, mas sim presumir que você quer dar merge pra main e pular esta etapa.

E então a seguinte tela aparecerá. Nela precisamos colocar uma descrição do que será feito ao mesclarmos a otherbranch na main, um título também é necessário.
<!---->
<!---->

Na Ecomp, se coloca o **título** como a seguir:

*"merge **branch fonte** into **branch alvo**"*

E então o **ambiente da PR** é criado
<!---->

Nesse caso foi criado um arquivo e por isso já estamos prontos para dar merge, senão teria que haver mudanças na branch para a merge request ser funcional.
Assim que esse PR for concluído e verificado, poderemos dar merge.

**OBS: Como você pode ver na imagem, está selecionado que após o merge a branch fonte será deletada, você pode configurar para que isso não aconteça caso prefira.**

Os ambientes das Merge Requests podem ser encontrados na aba <!--Merge Requests--> Pull Requests
<!---->

## Caracteristicas de uma Pull Request
Você deve ter visto que existem muitas coisas diferentes para uma Merge Request. Algumas delas sendo o Assignee, os Reviewers, Labels, Milestone, entre outras. Cada um desses contribui para o funcionamento da Pull Request.

**Assignee**:
O Assignee ou Cessionário, é o responsável por **manter** a Merge Request e tenta a deixar num estado aceitavel de merge, normalmente é quem a cria. Ela pode revisar ou analizar a requisição mas não é responsável por isso.
Pode ter mais de um por merge request.

**Reviewers**:
Os Reviewers são as pessoas que **revisam** a requisição, comentando as mudanças.
Geralmente sempre tem mais de um.

**Comentários**:
As Pull Requests podem ter comentários com problemas a serem consertados ou mudanças como nesse exemplo:

Podemos criar uma issue para criar uma conversa sobre o problema, como uma thread

<!--
Assim que as alterações forem feitas, a thread pode ser resolvida

Quando uma thread é resolvida, ela não aceita mais respostas.-->

Você também pode ver a Pipeline e os Commits que foram feitos na Pull Request, ou seja, é bem transparente.

## Como aceitar/aprovar uma Pull Request
Para aceitar uma Pull Request no Github existe a seguinte maneira <!--GitLab existem duas maneiras:-->

<!--### **Por Aprovação (Approval):**
É um sistema do GitLab que permite contribuidores de aprovar uma Pull Request baseado nas regras de aprovação do projeto.
Para isso ocorrer, o contribuidor precisa ser elegivel para poder votar aprovação.

O botão de aprovação aparece em uma merge request logo no começo conforme mostra a imagem:

Você também pode desaprovar caso necessário

A Merge Request será aprovada depois de um número requerido de aprovações conforme configurado.

Vale notar que essa tecnologia não está disponível no GitLab Free.

Para mais informações visitar [aqui](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/index.html).-->

<!-- github merges
-->

### **Aceitar Merge**
A outra maneira é simplesmente o **autor**, **desenvolvedores** ou outras **pessoas com permissões mais altas** verificarem se está tudo bem com a requisição e **aceitar** clicando em *Merge*:
<!---->

Após isso, o merge terá ocorrido

<!--Após isso, o merge terá ocorrido
-->

Vale lembrar, que a opção de deletar o branch fonte (o que vai ser levado para a main) estava ativa, então essa branch foi removida do projeto após o merge.

<!--Caso alguma coisa tenha dado errado você também pode **reverter** as mudanças da merge request
Para fazer isso, basta clicar em revert na requisição onde o merge já foi feito

O Resultado

### **O que se deve fazer ao aceitar uma Merge Request**
* Não deletar o branch fonte, ele deve permanecer para que possamos o reutilizar caso precise ou algo esteja dando errado, ou seja, manter assim quando for aceitar o merge
-->

## **Mensagens dos Commits**
Quando você for fazer um commit você deve se preocupar se a sua equipe entenderá o que você fez e por isso precisamos saber seguir um padrão nas mensagens dos commits.

As mensagens dos Commits devem sempre ser **claras** e **breves** (menos de 150 caracteres), mostrando o tipo/tag de commit realizado e o que foi feito.

A mensagem geralmente é feita da seguinte forma:

“*#id* **[tag]** o que foi feito”

Aonde *#id* é o número de identificação da issue e **[tag]** indica o tipo do commit.
É necessário especificar o id no commit para ser mais fácil de se guiar na develop no futuro.

A descrição do que foi feito deve ser clara e condizente com o que foi realmente feito.
Não se deve criar intrigas e precisa ser direto ou objetivo com as alterações.

**Exemplo:**
No projeto temos uma **dashboard** de sistemas, é necessário implementar um dialog com a criação de uma parte do projeto chamada de "Chamado", realizado pelo .post.
Assim que **finalizado**, essa parte pode ser commitada com a seguinte mensagem na branch em questão.

## Tags dos Commits
As tags que você pode usar para indicar o que foi feito no commit são as seguintes:
* **[add]** ou **(add)**
A mensagem com essa tag indica que algo foi adicionado

* **[del]** ou **(del)**
Algo foi removido/deletado

* **[fix]** ou **(fix)**
Commits com essa Tag indicam que algo foi consertado/arrumado

* **[mod]** ou **(mod)**
Tag indicando que ocorreu alguma modificação em algum arquivo já presente no projeto

* **[merge]** ou **(merge)**
Tag indicando que foi feito um merge com outra branch, raramente usado.

Essas tags sempre precisam ocupar poucos caracteres, pois precisamos do restante pro commit, por isso são abreviadas em até 3 caracteres.

Como pode se notar, existem dois jeitos de escrever a tag, com colchetes ou com parênteses, embora ambos sejam aceitos, é melhor usar o método com colchetes pois o uso de parênteses pode fazer com que certos comandos não funcionem de uma maneira muito intuitiva.

Como mostrado a seguir ao tentar mudar para uma branch com parênteses no nome:

Maneiras de consertar:
O mais recomendável é usar as aspas.