Git

Menu

• GitFlow
• Opções de Ferramentas
• Comandos Básicos
• Merge Requests
• Critério de Aceite de Merge Requests
• Tutoriais

GitFlow

As atualizações da Developer serão feitos através de Pull Requests

Opções de Ferramentas

GitKraken

• Download do GitKraken.
  essa ferramenta facilita o uso do git através de uma interface intuitiva

GitBash (Windows)

• Download do GitBash.

Comandos Básicos

• clonar um repositório:
  git clone ADICIONAR URL
• verificar o status do repositório:
  git status
• CRIAR uma nova branch:
  git checkout -b <branch desejada>
• ALTERNAR para uma branch:
  git checkout <branch desejada>
• add arquivos alterados e dar um commit na branch:
  git commit -a -m 'adicionei um novo rodapé [issue 53]'
• primeira vez a enviar os dados para o repositório.
  git push origin <branch desejada>
• reenviar os dados para o repositório.
  git push
• baixar os dados do repositório.
  git pull
• fazer um merge em duas branch's.
  git merge <nome da branch>

Padrão para Criação de Branches

As branches criadas para desenvolvimento das funcionalidades pelas squads devem seguir o padrão e de acordo com seu objetivo:

Tags para os tipos de alterações:

• feat - Nova funcionalidade
• fix - Correção de defeito
• docs - Alteração de documentação
• style - Alterações visuais que não possuem alteração em codigo fonte
• refactor - Reescrever um código para corrigir um bug ou adicionar uma nova funcionalidade
• perf - Melhorar performance do sistema

feat/NUM_TASK

Exemplo: feat/44

Padrão para as mensagens de commit

Os commits deverão ter um padrão em suas mensagens para facilitar o entendimento da equipe no que foi desenvolvido:

"Descrição breve do commit - Autores (caso realizado em equipe)"

Exemplo: "Compare button done - Duda, Martin e Pedro"

OBS: Caso as atividades do commit tenham sido realizadas individualmente não é necessário informar os autores, porque a única pessoa envolvida será quem está subindo o commit.

Merge Requests

Depois de uma task ter sido desenvolvida e estiver pronta de acordo com os critérios de aceitação, é necessário que a mesma seja enviada para a branch de desenvolvimento. Para isso é necessário abrir um Merge Request pela platafora GitLab:

Criando o Merge Request

A criação pode ser realizada na seção Merge Requests do repositório em que a branch foi criada. Clicando no botão New Merge Request siga os seguintes passos:

1. Selecionar a branch de origem (sua branch de desenvolvimento);
2. Selecionar a branch de destino (branch develop);
3. Selecione Compare branches and continue
4. Em Title, escreva um título que descreva a funcionalidade adicionada ou bug corrigido;
5. Em Description, escreva uma descrição com uma breve justificativa nos arquivos que foram alterados;
6. Na seção Assignee, selecione Assign to me para que fique registrado quem foi o responsável pelo desenvolvimento daquela tarefa (a pessoa selecionada será chamada caso o revisor tenha dúvidas sobre a tarefa);
7. Em Milestone selecione a Sprint em que a tarefa foi realizada;
8. Em Labelsselecione qual é o tipo de tarefa que foi realiada;
9. Por último, revise se os arquivos que estão sendo enviados estão corretos e clique em Submit Merge Request.

Padrão para abertura de Merge Request

Os merge requests também devem seguir um padrão de criação:

O Title deve ser escrito UserStory - Título do Card no Trello e na Description deve ser informado o link para o card, além de uma descrição da tarefa e se possível uma imagem/gif para visualização do que foi desenvolvido. Exemplo:

Title: US04 - Criar componente de botão para navegar para a tela de comparação
Description: https://trello.com/c/d67o9cLk/26-us09-criar-menu

Critério de Aceite de Merge Requests (MR)

• Branch testada
• Branch atualizada com a DEV
• Arquitetura Respeitada
• Código Limpo
• Boas práticas atendidas

Tutoriais

• basico-1.
• basico-2.
• GitFlow.

Código

Boas práticas no desenvolvimento

O que são códigos de status HTTP ?

Sempre que você clicar em um link ou digitar uma URL e pressionar Enter, seu navegador envia um pedido ao servidor web para o site que você está tentando acessar. O servidor recebe e processa a solicitação, e depois envia de volta os recursos relevantes juntamente com um cabeçalho HTTP.

Sobre as classes de código de status HTTP

Os códigos de status HTTP são divididos em 5 “classes", que são:

• 100s: Códigos informativos indicando que a solicitação iniciada pelo navegador continua.
• 200s: Códigos de sucesso retornados quando o pedido do navegador foi recebido, compreendido e processado pelo servidor.
• 300s: Códigos de redirecionamento retornados quando um novo recurso foi substituído pelo recurso solicitado.
• 400s: Códigos de erro do cliente indicando que houve um problema com o pedido.
• 500s: Os códigos de erro do servidor indicam que a solicitação foi aceita, mas que um erro no servidor impediu o cumprimento da solicitação.

Os mais utilizados

• 200: "OK". Este é o código que é entregue quando uma página web ou um recurso age exatamente da maneira que é esperado.
• 201: “Created”. O servidor cumpriu o pedido do navegador e, como resultado, criou um novo recurso.
• 204: “No content”. Este código significa que o servidor processou a solicitação com sucesso, mas não vai devolver nenhum conteúdo.
• 400: "Bad Request". O servidor não pode retornar uma resposta devido a um erro no lado do cliente. Veja o nosso guia para resolver este erro.
• 401: “Not authorized”. Isto é devolvido pelo servidor quando o recurso alvo não possui credenciais de autenticação válidas.
• 403: “Forbidden”. Este código é devolvido quando um usuário tenta acessar algo que não tem permissão para visualizar. Por exemplo, tentar chegar ao conteúdo protegido por senha sem entrar no sistema pode produzir um erro 403.
• 404: “Not Found”. Esta é a mensagem de erro mais comum de todas elas. Este código significa que o recurso solicitado não existe, e o servidor não sabe se ele alguma vez existiu.
• 405: “Method Not Allowed“. Isto é gerado quando o servidor de hospedagem (servidor de origem) suporta o método recebido, mas o recurso de destino não suporta.
• 500: “Interal Server Error”. Este é um código genérico que significa simplesmente “erro interno do servidor”. Algo correu mal no servidor e o recurso solicitado não foi entregue.
• 502: “Bad Gateway”. Este código de erro tipicamente significa que um servidor recebeu uma resposta inválida de outro, tal como quando um servidor proxy está em uso. Outras vezes uma consulta ou pedido demorará muito tempo, e por isso é cancelado ou morto pelo servidor e a conexão com a base de dados quebra.

Referência: link

Métodos API - Backend

Nas requisições, especificamos o que chamamos de método HTTP ou verbo. Na versão 1.1 do protocolo HTTP(que é a que todos usamos atualmente) temos 9 verbos diferentes. Os mais utilizados são:

GET: Essa é a requisição mais comum de todas. Através dessa requisição nós pedimos a representação de um recurso: que pode ser um arquivo html, xml, json, etc.

POST: O método POST é utilizado quando queremos criar um recurso. Quando usamos POST, os dados vão no corpo da requisição e não na URI.

PUT: Requisita que um recurso seja "guardado" na URI fornecida. Se o recurso já existir, ele deve ser atualizado. Se não existir, pode ser criado.

DELETE: Exclui o recurso especificado.

PATCH: Serve para atualizar partes de um recurso, e não o recurso todo.

Referência: link

Análise dos principios SOLID

O que é SOLID? SOLID é um acrônimo criado por Michael Feathers, após observar que cinco princípios da orientação a objetos e design de código — Criados por Robert C. Martin (a.k.a. Uncle Bob) e abordados no artigo The Principles of OOD — poderiam se encaixar nesta palavra. S.O.L.I.D: Os 5 princípios da P.O.O.(Programação Orientada a Objetos)

• S — Single Responsiblity Principle (Princípio da responsabilidade única) -
• O — Open-Closed Principle (Princípio Aberto-Fechado)
• L — Liskov Substitution Principle (Princípio da substituição de Liskov)
• I — Interface Segregation Principle (Princípio da Segregação da Interface)
• D — Dependency Inversion Principle (Princípio da inversão da dependência)

SRP — Single Responsibility Principle: Princípio da Responsabilidade Única — Uma classe deve ter um, e somente um, motivo para mudar.

OCP — Open-Closed Principle: Princípio Aberto-Fechado — Objetos ou entidades devem estar abertos para extensão, mas fechados para modificação, ou seja, quando novos comportamentos e recursos precisam ser adicionados no software, devemos estender e não alterar o código fonte original.

LSP — Liskov Substitution Principle: Princípio da substituição de Liskov — Uma classe derivada deve ser substituível por sua classe base.

ISP — Interface Segregation Principle: Princípio da Segregação da Interface — Uma classe não deve ser forçada a implementar interfaces e métodos que não irão utilizar.

DIP — Dependency Inversion Principle: Princípio da Inversão de Dependência — Dependa de abstrações e não de implementações.

Referência: link