Mudanças entre as edições de "GitFlow"
Linha 152: | Linha 152: | ||
[[Arquivo:gitflow_13.png|700px|thumb|nenhum]] | [[Arquivo:gitflow_13.png|700px|thumb|nenhum]] | ||
+ | |||
+ | '''Passo 10 – Criando um Hotfix''' | ||
+ | |||
+ | '''Comando:''' ''git flow hotfix start [nome_da_hotfix] | ||
+ | '' | ||
+ | É comum surgirem bugs no sistema de produção e muitos deles não podem esperar o processo de Feature, Release, teste<br> | ||
+ | e publicação. Pra isso o Fluxo de Hotfix foi criado. Ele é um Fluxo que segue a parte e depende somente da Master. | ||
+ | |||
+ | O comando mostrado cria um novo hotfix e faz o checkout para o mesmo criado. | ||
+ | |||
+ | [[Arquivo:gitflow_14.png|700px|thumb|nenhum]] |
Edição das 20h55min de 15 de junho de 2021
Fluxo de trabalho Gitflow
O Git Flow é uma maneira dinâmica e ativa de organização de branches dentro do Git. Com base nessa metodologia,
o Git Flow criou um ferramental para auxiliar esta administração. Ele agrupa um conjunto de comandos dentro de um único comando
o intuito de auxiliar no gerenciamento e na manutenção do repositório.
Os ramos (branches)
Master
A branch Master é a cópia fiel do sistema em produção, um espelho de todo o sistema que está operando em produção.
Em tese, se algo acontece com o sistema de produção, a master deve estar preparada para subir para produção e continuar
operando normalmente como antes. Só deve existir uma branch Master no projeto, apenas um Fluxo (Flow) de evolução.
Develop
A branch Develop é a base de trabalho e desenvolvimento do projeto. A Develop sempre está sincronizada com a Master, sempre.
Todas as novas funcionalidades (Features) e toda a evolução do projeto é feita com base na branch Develop. Assim como a Master,
só deve existir apenas uma branch Develop, apenas um Fluxo (Flow) de evolução.
Features
A branch Features é o conjunto de branches que compõe toda a evolução do projeto. Com base na Develop, toda nova funcionalidade a
ser implementada no sistema é feita pelo Fluxo (Flow) Features. Neste caso, podem existir N branches para este Fluxo (Flow).
Em um mesmo Fluxo Features várias branches de novas funcionalidades podem coexistir simultaneamente. Todas serão “mergeadas” uma a uma para a Develop.
Release
E a branch que controla a versão do sistema. Quando há uma quantidade X de merges das Features com a Develop, um novo Release pode ser criado,
criando uma nova versão para o sistema. Cada arquiteto ou responsável pelo projeto decide quando criar uma nova Release com base no que já foi produzido.
Geralmente é nesta branch que acontecem todos os tipos de testes. Quando um Release é aprovado, ele é “mergeado” com a Master e com a Develop,
para manter a base de desenvolvimento atualizada. Só deve existir apenas uma branch Release, apenas um Fluxo de evolução (Flow).
Hotfixes
Esta branch é utilizada para gerar correções que ocorrem em produção. Geralmente um erro no sistema de produção não pode esperar todo o
fluxo de Develop, Feature, Release pra depois voltar para a Master. Erros no sistema de produção requerem imediatismo e é pra isso que a Hotfies existe.
Quando um erro é encontrado em produção, uma Hotfix é criada com base na Master, corrigida e “mergeada” de volta para a Master e juntamente para a Develop.
É muito importante a Develop receber esta atualização, pois se isto não for feito, o problema outrora corrigido pode voltar depois de uma nova Release.
Não é aconselhável existirem várias branches de Hotfixes, mas muitas equipes optam por terem quando o sistema tem uma incidência muito grande de erros
acontecendo em produção.
Iniciando o Git Flow
O Git Flow segue uma sequência de fluxos de branches e com base nesse fluxo todo o ciclo de vida do projeto é mantido atualizado e versionado.
Passo 1 – Clonando o repositório
Comando: git clone git@us-south.git.cloud.ibm.com:sheila.prado/redome-workup.git
O processo de clonar o repositório é o mesmo do Git nativo como mostrado a seguir:
Passo 2 – Iniciando o Git Flow no projeto
Comando: git flow init -d
No momento da instalação o Git Flow mostrará os passos de configuração das branches de base.
Um padrão já vem configurado e é aconselhável deixar a configuração padrão.
Após a finalização do processo é possível ver que um simples comando já configura o ambiente e
ainda cria a branch de desenvolvimento develop.
Passo 3 – Enviando para o Git as branches criadas
Comando: git push origin master && git push origin develop
Depois de criado as branches, é necessário enviá-las para o repositório remoto.
Depois disto, a evolução do projeto poderá ser iniciada.
Passo 4 – Iniciando uma nova Feature
Comando: git flow feature start [nome_da_feature]
Este comando é mais um exemplo de várias ações dentro de um único comando. Após executar o comando de
criação de Feature, o Git Flow cria a branch no Fluxo Feature e em seguida faz o checkout para a Feature criada.
Passo 5 – Criar um novo arquivo e enviá-lo para o repositório remoto
Comando: git push origin feature/[nome_da_feature]
Após a criação da nova Feature, os arquivos já podem ser criados e a evolução ocorre normalmente, os commits
locais podem ser feitos e, ao terminar, é necessário enviar toda a implementação feita para o repositório remoto
juntamente com a branch Feature criada no repositório local.
A imagem a seguir mostra que a branch Feature foi criada no repositório remoto.
Passo 6 – Finalizando a Feature criada
Comando: git flow feature finish [nome_da_feature]
Apenas um único comando é necessário para fazer o merge da Feature com a Develop, excluir a Feature criada
e fazer o checkout para a branch Develop.
Passo 7 – Criando um Release
Comando: git flow release start [versao_da_release]
Após um conjunto de Features ter sido criado e “mergeados” com a Develop, um novo Release pode ser criado.
Não há uma regra para quando um Release é criado, esta decisão cabe da equipe e dos responsáveis pelo projeto.
Ao executar o comando de criação de Release, o Git Flow cria a Release e faz o checkout para a nova branch criada.
Passo 8 – Publicando a Release
Comando: git flow release publish [versao_da_release]
Depois de todas as validações e testes necessários no Release criado, é possível publicar sua versão.
O comando de publicar um Release envia todo o conteúdo para o repositório remoto.
Em seguida, é necessário colocar uma mensagem para a publicação da Release. <Esc> wq!
Depois da mensagem, a tela de configuração de Tag é exibida. <Esc> wq!
Depois de tudo configurado, o Git Flow faz o merge para as branches Master e Develop, deleta a Release
criada e faz o checkout para a Develop já atualizada.
Passo 9 – Publicando a Master e a Develop
Comando: git push origin develop && git push origin master
Agora, com o Release publicado e “mergeado” com a Master e a Develop, é necessário enviar para o
repositório remoto as alterações feitas na Master e na Develop.
Passo 10 – Criando um Hotfix
Comando: git flow hotfix start [nome_da_hotfix]
É comum surgirem bugs no sistema de produção e muitos deles não podem esperar o processo de Feature, Release, teste
e publicação. Pra isso o Fluxo de Hotfix foi criado. Ele é um Fluxo que segue a parte e depende somente da Master.
O comando mostrado cria um novo hotfix e faz o checkout para o mesmo criado.