Este artigo é para poder explicar o que é e como funciona gitflow de um ponto de vista diferente. Para quem caiu aqui de paraquedas precisa da uma lida sobre git, segundo Tableless "Git é um sistema de controle de versão de arquivos. Através deles podemos desenvolver projetos na qual diversas pessoas podem contribuir simultaneamente no mesmo, editando e criando novos arquivos e permitindo que os mesmos possam existir sem o risco de suas alterações serem sobrescritas.". Visite o site para poder obter mais informações sobre git. Voltando ao assunto deste artigo para sabemos o que é gitflow temos que sabermos o que é VS(versionamento semântico).
Segundo Tecnospeed "O Versionamento Semântico nada mais é do que um conjunto de regras e particularidades que mostram como os números das versões do aplicativo foram desenvolvidos. Em outras palavras, a quantidade de mudanças pelas quais o app passou e quais alterações foram compatíveis ou incompatíveis com a versão anterior."
Normalmente o versionamento semântico é composto por major, minor e patch ou 0.0.0, nele podemos descrever em qual estagio está a nossa aplicação.
Começando do Patch, o valor numérico dele muda quando houve correções de bugs, algum erro que foi encontrado, um botão sem ação, esses tipos de bugs. Já o Minor ele muda o seu valor numérico quando há novas funcionalidades, no caso, um botão novo, um fragment novo criado, algo nesse estilo. E por último temos o Major, ele é o que menos muda, para chegar e mudar o seu valor é porque houve mudanças grandes que quebrou o código fonte, praticamente mudou tanto que já não tem mais compatibilidade com as outras versões anteriores da aplicação.
Segundo Atlassian "Gitflow Workflow é um design de fluxo de trabalho Git que foi publicado e popularizado pela primeira vez por Vincent Driessen no nvie. O Gitflow Workflow define um modelo de ramificação rigoroso projetado com base no lançamento do projeto."
Como dito acima o gitflow nada mais é que um fluxo de trabalho, logo você obtendo esse conhecimento o fluxo do seu trabalho vai começar a ter resultados excelentes, de que forma? Vamos passo a passo.
O fluxo de trabalho ele se baseia em 5 branchs, que são:
- Master
- Hotfix
- Release
- Develop
- Feature
O Master(Não podemos esquecer de dizer que a pouco tempo eles substituíram o termo como “master” (mestre) por termos neutros como “main” (principal)) é onde você armazena a sua aplicação funcional, no caso, é nela que você obtém uma nova funcionalidade que já foi testada, é nela que vai está a aplicação sem nenhum erro entre outras características que ela possui também, como tags com várias versões do produto, é considerada a branch do produto que o cliente conhece.
A Feature é a área que você implementa uma funcionalidade, é daqui que vem todo o desenvolvimento da aplicação, cada historia da início de uma feature, é claro que isso irá variar de empresa para empresa, se você não sabe o que quero dizer com história, da uma lida na metodologia agile Scrum.
A Develop é onde você junta pedaço por pedaço da aplicação implementada, no caso, cada feature que vai terminando, é passada para a develop para ela juntar e organizar de forma simples e prática.
A Release é a área de teste, onde você verifica se está tudo ok e funcionando para poder passar para a master, se não tiver funcionando ou com algum bug, ela volta para a develop.
A Hotfix è quando acontece casos inesperados, como assim inesperados? É quando a aplicação que passou pelos testes e foi para a master teve problema, como você não pode ficar sem a aplicação funcionando, você utiliza a hotfix para fazer essa correção de bug sem precisar passar por todas as burocracias, no caso, passar pela feature, develop, release para depois ela ir para master, já fazendo isso direto.
Hora de um exemplo prático.
Imagine que você tem uma equipe e terão que desenvolver um site, a primeira coisa a se fazer é criar um repositório para poder versionar todo o código desenvolvido. Depois de vocês terem feito isso, agora tera que criar as histórias do usuário vou da alguns exemplos:
Eu, enquanto empresário, desejo a partir dos serviços que a empresa fornece, o site mostre de forma clara, objetiva e intuitiva todos esses serviços.
Eu, enquanto visitante, quero ter acesso a um catálogo de todos os serviços disponíveis oferecidos.
Eu, enquanto empresário desejo uma pagina que mostre quem somos como empresa.
Eu, como visitante, quero poder entrar em contato com a empresa sem precisar realizar cadastro.
Eu, enquanto empresário, quero que o site divulgue minhas redes sociais.
Até nesse ponto, você já deu para entender como funcionaria a criação das histórias do usuário. Com as histórias criadas é a hora de começar a desenvolver, na sua equipe vocês optaram por cada história ser uma feature, se tornando uma branch, esse seria o exemplo dos nomes das feature branchs:
Feature-show-service
Feature-show-catalog
Feature-show-about-company
Feature-show-contact
Feature-show-midias
Sempre que terminar uma feature vocês terão que solicitar um PR(Pull Request) para poder subir os dados na branch develop, a branch develop ela será responsavel por pegar cada feature e juntar, como se as feature fosse o quebra-cabeça e a develop vai montar as peças, finalizando a branch develop ela solicitará um PR para a branch release onde alguns programadores irão testar e verificar se esta de acordo com o que foi pedido, concordando que está tudo ok com o que foi mandando para release, está na hora de subir para a master ou main, com isso o cliente poderá visualizar até onde o trabalho foi desenvolvido
Bom, explicado passo a passo como funciona e o que é o gitflow, este foi o diário de bordo #01 vamos nos despedindo por aqui. Amanhã voltamos com, mas um diário de bordo.
Top comments (0)