Executando verificação de segurança...
2
danilocarsan
4 min de leitura ·

Este é um guia de versionamento/ nomenclatura git que uso e tenho melhorado, o que eu poderia melhorar ? Aberto a sugestão e discussão

📝 Guia de versionamento

Este documento determina padrões de nomenclatura de branchs e commits, assim como
o fluxo de trabalho e separação de responsábilidade dos branchs

Versionamento semantico

Ver Semantic Versioning

Nomenclatura de branch

Branch main

É uma branch que contem a versão atual do sofware em produção, está branch pode estar vinculada
a uma pipeline para cada push uma nova versão é implentada em produção

Branch dev

É uma area de staging onde concentra o maior fluxo de trabalho e colaboração entre pessoas
e equipes, as alterações aqui possívelmente são as que estarão na proxíma versão de lançamento.

Branch homologacao

É uma branch que serve como link para o deploy no ambiente de homologação nesta branch não se deve
fazer alterações diretamente.Quando uma branch de release está pronta para lançamento é feita uma
pull request para está branch ou um merge para que a release sejá testada no ambiente de homologação
havendo problemas os mesmos devem ser tratados na branch de release.

Branch release

É uma branch de lançamento de versão que contem as novas funcionalidades desenvolvidas
que entrarão em produção, elas podem ter o seguinte formato: release/v1.5.0

Branch hotfix

É uma branch para correção de bugs de nível urgente que não podem esperar para serem
lançados na proxima versão, está consiste em uma copia dabranch main,
elas podem ter o seguinte formato: hotfix/v1.5.1-correção-do-bug-xpto, depois de corrigido
o bug é feito o merge com a branch main e dev para que os repositórios fiquem atualizados

Branch bugfix

É uma branch de correção de bug, ela pode ter o seguinte formato bugfix/correção-do-bug-xpto,
está considte em uma copia da branch dev, depois de corrigido é feito uma merge com a branch dev,
por se tratar de um bug com de baixa urgencia essa correção será disponibilizada na proxima release

Branch feature

É uma branch que identificação o desenvolvimento de uma funcionalidade, como por exemplo *feature/feature-xpto,
está é uma copia a branch dev, pode haver várias branchs com está de uma vez uma para cada funciionalizade,
depois são terminadas é feito o merge com a branch dev.

Nomenclatura de commit

Os commit devem ser coesos e se referir a uma única coisa, deve-se presar em cada commit haver alterações
de um único tema, se um commit possui o seguinte formato: "corrigindo bug x e adicionando campo xpt" possívelmente
este commit não está coeso ou está se referindo a multiplas responsábilidade o e indica isso, neste
caso está obvio que deve-se separar em dois commits. A separação se dá para melhor controle no histórico
de alterações, melhor visualização em um code review e uma possível reversão das alterações.

Segue abaixo as possíveis formatos e labels que os commits podem possuir

feat: para adição de novas funcionalidades ao código;

feat: criando UserService

fix: para correção de um bug ou falha no código;

fix: correção de erro ao criar um usuário sem uma foto de perfil

style: para alterações relacionadas a aspectos visuais ou de formatação do código;

style: alterando o a cor de fundo do menu do painel de usuário

refactor: para alterações que visam melhorar a qualidade interna do código, sem alterar sua funcionalidade;

refactor: refatorando o UserSrvice, melhor separação de responsábilidade entre metodos

chore: para outras tarefas relacionadas ao projeto que não se enquadram nas categorias anteriores;

chore: configurando regras do prettier e eslint

build: para alterações relacionadas ao processo de compilação ou construção do projeto;
- feat: para adições de novas funcionalidades ao processo de compilação ou construção;
- fix: para correção de falhas relacionadas ao processo de compilação ou construção;
- refactor: para melhorias no processo de compilação ou construção do projeto;

build(feat): criando arquivo com as configurações de deploy

docs: para alterações na documentação do projeto;
- feat: para adições de novos conteúdos na documentação;
- fix: para correção de erros ou inconsistências na documentação;
- refactor: para melhorias na organização ou estruturação da documentação;

docs(refactor): mudando a forma de nomenclatura dos commit

test: para alterações relacionadas aos testes automatizados;
- feat: para adições de novos testes;
- fix: para correção de falhas ou erros em testes existentes;
- refactor: para melhorias nos testes ou na estrutura de testes existentes.

test(feat): criando teste para o UserService
Carregando publicação patrocinada...
1
1
1
kht

Falando de forma geral, o Git é flexível o suficiente pra vc adaptar da forma que achar melhor. Eu sugiro vc usar tudo que descreveu acima por um tempo e ver como se sai. Certamente vai perceber vantagens e desvantagens, coisas que dá pra manter e outras que dá pra melhorar, e de tempos em tempos faça alguns ajustes. É assim - ou pelo menos deveria ser - com qualquer metodologia.

As "boas práticas" que vc vê por aí são apenas recomendações, no máximo um ponto de partida. Eu acredito que nada disso é uma "lei escrita na pedra" que deva ser seguida à risca em 100% dos casos. Tudo pode - e deve - ser adaptado para cada caso específico.

E tudo depende do contexto. Eu, por exemplo, trabalho com vários fluxos diferentes, dependendo do tipo de projeto:

  • tenho um projeto pessoal no qual sou o único contribuidor. Então não tem nem branches, faço tudo no main. Exceto num ou outro caso em que quero fazer algum teste muito fora da caixa, aí eu crio um branch, mas no fluxo normal não preciso
  • em projetos do trabalho, depende. Tem projetos que só uma equipe mexe, aí usamos um branch por feature, e branches hotfix para correções emergenciais (é tipo um Git Flow, mas um pouco mais simplificado)
  • mas já trabalhei em projetos maiores, com várias equipes mexendo em coisas diferentes ao mesmo tempo. E aí o fluxo é mais complexo, inclusive com uma equipe que centraliza os PR's

Enfim, se o fluxo que vc definiu te atende bem, não tem problema nenhum. Lendo por cima, me parece ok, mas só depois de usar por um tempo é que vc vai poder concluir se ele é adequado ou não para as suas necessidades.

1
danilocarsan
Autor
Autor

Muito obrigado pela resposta, onde trabalho é só eu e mais uma pessoa, então é mais simples, entretando gostaria muito de trabalhar com equipes maiores para ter mais experiencia. Quando comecei a estudar este tema eu mesmo simulava os cenários com duas contas distintitas kkkkkkkkk, fazia pr de uma aceitava com outra, fazia merge, resolvia conflito, era trabalho mas serviu para aprender. tenho está ciência de que não tem porque complicar se o cenário é simples é frustante as vezes ter que aprender sozinho e não tem onde colocar em prática no mundo real.

1
kht

De fato, se são só duas pessoas, não tem porque complicar. Comece pelo fluxo mais simples que funcione pra vcs, e aí com o tempo vão fazendo ajustes conforme a necessidade.

Vcs até podem se basear em Git Flow e similares pra servir de inspiração, mas não siga 100% à risca se não fizer sentido. Nem todo mundo precisa de tudo que tem ali.

1
blopes

Bom, pelo que eu entendi você realizou uma padronização de nomes de branches e de commits com base no Git Flow e no Conventional Commits. É isso?

Eu achei a padronização interessante, apesar de que na documentação original do Conventional Commits a palavra entre parênteses normalmente aparece relacionada ao módulo da aplicação que foi alterado (na minha opinião, nada impede que o uso seja igual ao que você fez, descrevendo o tipo de mudança).

Sobre o Git Flow, já fui um grande defensor, mas estou cada vez mais propenso a utilizar menos branches, como por exemplo no GitHub Flow e no GitLab Flow.

Acredito que a utilização de menos branches permite que sejam identificados erros mais rapidamente, devido às constantes integrações.

Mas de qualquer modo, sei que muitas equipes trabalham com o Git Flow, e sem dúvida o seu trabalho de tentar padronizar é muito interessante.

2
danilocarsan
Autor
Autor

Obrigado pelo e tempo e resposta !

Meus commits não eram padronizados e muito menos minhas branch uns poucos meses átraz e agora estou em aprofundando no git em geral, tenho estuda Gitflow, CI, CD, OPEN API e outras coisas, onde trabalho só é eu e mais um e estamos migrando para aws quero melhorar está parte que vi que estava decadente e também passar está visão para meu colega aos poucos vamos evoluindo.

1
blopes

Eu te entendo! Você está no caminho certo. No começo, é difícil incorporar tanta coisa na rotina da gente, mas depois você vai vendo o valor de cada coisa, e percebe que valeu a pena.

Parabéns pela vontade de melhorar, e parabéns por escolher ferramentas e estratégias boas.