git - HemersonGH/sigesdp GitHub Wiki

Para controle de versão interno de código, utilizamos a ferramenta Git.

Para a correta utilização da ferramenta é necessário seguir algumas orientações.

Nomes de Branchs

• Para criar uma branch, o padrão deve ser algo que remeta a funcionalidade da história. Caso a história seja de um cadastro de pessoas, o nome da branch deverá ser 'cadastro_pessoa', tudo minúsculo separado por underline '_'.
• Em caso de mantis, o nome da branch deverá ser 'mantis_numero'.

Fluxo de utilização

Ao iniciar o desenvolvimento de uma história, a primeira atividade é criar a branch (seguindo o padrão acima) relacionada a mesma e envia-la ao servidor. Ao começar o desenvolvimento de uma atividade, deverá ser criado uma branch a partir da branch da história concatenado com algum identificador da atividade.

Ex:

História: Eu como usuário do sistema desejo cadastrar uma pessoa física. Branch da história: "cadastro_pessoa_fisica"

Atividade: Criar serviço de salvar no backend. Branch da atividade: "cadastro_pessoa_fisica_servico"

Ao término do desenvolvimento da atividade, ela deverá ser enviada a branch principal da história obrigatoriamente através de Merge Request, salvo raras exceções. Apenas após validação por um desenvolvedor da equipe que ela será mesclada com a branch da história. Nesse momento a história ficará disponível para teste.

Após os testes realizados na branch da história, a branch deverá ser mesclada com a master por algum desenvolvedor com perfil "master" no GitLab. Após a história estar disponível na master, a mesma deverá ser testada novamente.

Ao fim de um ciclo de desenvolvimento, as branchs já mescladas com a master deverão ser excluídas.

A branch principal master é protegida e desenvolvedores não podem dar "push".

Padrões de Commits

Procure sempre explicar o que foi feito em seu commit, evite commits vagos como "Correções", "Melhorias". Prefira algo do tipo:

Aplicado melhorias de performance ao cadastrar um usuário no sistema.

Em caso de mantis, colocar ao início do commit "Mantis 'numero_mantis' - Mensagem". Lembrar também de sempre criar uma branch do mantis.

Em caso de necessidade de commitar uma atividade incompleta, utilizar a palavra reservada do git [WIP], que indica Work In Progress. Segue exemplo:

[WIP] Criando funcionalidade de salvar pessoa física.

IMPORTANTE: Uma funcionalidade WIP não pode ser commitada diretamenta na master em hipótese alguma.

Política de utilização de TAGs

Para padronização de Tags, utilizamos o padrão SEMVER

Padrão de uma TAG -> v0.0.0 sendo:

• Primeiro dígito da esquerda para a direita é referente a versão do projeto (dígito mais significativo), deverá ser iniciado com 0 e só incrementar seu valor após a primeira release de produção ser gerada. Será incrementado novamente apenas caso haja uma re-estilização completa do código.

• Segundo dígito da esquerda para a direita é incrementado quando houver novas funcionalidades no sistema, engloba melhorias de mantis.

• Terceiro dígito da esquerda para a direita é incrementado quando houver apenas correções de bugs (mantis) na release.

Uma nova Tag deverá ser criada utilizando o parâmetro '-a' para criar uma anotação para a mesma, uma anotação deve conter as principais alterações em relação a Tag anterior.

git tag -a v0.0.0 -m "Mensagem da tag"

ou

git tag -a v0.0.0

e escrever a mensagem da tag em seu editor de texto no terminal.

1. O código deve estar simples e de fácil manutenção e preferencialmente reutilizável. Evitar código duplicado.

2. Nomear variáveis, métodos, propriedades e classes condizentes com a sua funcionalidade.

3. Evitar classes e métodos extensos.

4. Manter o código no padrão MVC, tentar deixar métodos e classes mais objetivos possível.

5. Métodos e funções devem receber o mínimo de parâmetros possível.

6. Seguir os Padrões de Código do projeto.

7. Declarar variáveis no menor escopo possível.

8. Não manter ou criar variáveis que você não pretende utilizar novamente (exceto quando prejudicar a legibilidade).

9. Evitar logs desnecessários e utilizar os logs corretamente conforme hierarquia (WARN, INFO, ERROR, etc).

10. Evitar classes e métodos públicos quando possível.

11. Preferir tipos de variáveis de interface ao da implementação (Uso de polimorfismo).

//Correto
List<String> nomes = new ArrayList<>();

//Errado
ArrayList<String> nomes = new ArrayList<>();

12. Utilizar tipagem correta das propriedades.

13. Verificar validade dos parâmetros no início do método.

14. Em cada exceção, utilizar uma mensagem do erro detalhada para o log e uma simplificada para o usuário.

15. Não deixar informações sensíveis nas exceções (que vão para o usuário) como paths.

16. Levar sempre em consideração a performance.

17. Utilizar bibliotecas e frameworks. Não reinventar a roda.

18. Não deixar constantes hardcoded no código lembrar de utilazar o Config.java para configurações e o messages para mensagens de usuário.