Date: Thu, 28 Mar 2024 17:16:36 +0000 (UTC) Message-ID: <2132987795.17.1711646196617@ip-172-25-76-134.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_16_75318987.1711646196612" ------=_Part_16_75318987.1711646196612 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
O Gitflow foi idealizado por Vin= cent Driessen em 2010 e trata-se de um padr=C3=A3o de gerenciament= o de fluxo de trabalho que tem como base o Git. Seu modelo de ramifica= =C3=A7=C3=B5es possui uma estrutura bem definida, com fun=C3=A7=C3=B5es pr= =C3=B3prias e regras de intera=C3=A7=C3=A3o. Na pr=C3=A1tica, esse rigor ga= rante organiza=C3=A7=C3=A3o e controle para o gerenciamento de grandes proj= etos.
Figura 1 - Linha do tempo em um pr= ojeto com o padr=C3=A3o Gitflow
Para gerenciar o fluxo de trabalho com o Gitflow n=C3=A3o =C3=A9 necess= =C3=A1rio novas tecnologias, conceitos ou comandos, apenas os recursos j=C3= =A1 dispon=C3=ADveis no Git, como branch (ramo), mer= ge, checkout, tags etc.
O Gitflow possui 5 tipos de ramos, dois deles s=C3=A3o considerados prin= cipais (master e develop) e os demais secund=C3=A1rios ou= tempor=C3=A1rios (release, feature e hotfix/bugfix). Veremos a seguir a defini=C3=A7=C3=A3o de cada um deles.
O ramo master =C3=A9 respons=C3=A1vel por manter o hist=C3=B3ri= co de todas as vers=C3=B5es de lan=C3=A7amento (produ=C3=A7=C3=A3o) do proj= eto, enquanto o developer, que =C3=A9 derivado do master = assim que o reposit=C3=B3rio =C3=A9 criado, possui o hist=C3=B3rico complet= o do produto. Eles seguir=C3=A3o em paralelo, de forma cont=C3=ADnua e nunc= a ser=C3=A3o mesclados diretamente durante toda a vida do projeto, assim, o= develop sempre utilizar=C3=A1 um ramo secund=C3=A1rio (r= elease) para atualizar o master.
O ramo develop reflete o estado mais atual das funcio= nalidades que est=C3=A3o prontas (desenvolvidas) e foram eleg=C3=ADveis par= a ir para a pr=C3=B3xima release, j=C3=A1 o master possui= o conte=C3=BAdo um pouco mais defasado, por=C3=A9m mais seguro para o usu= =C3=A1rio do sistema.
Figura 1.1 - Destaque para os ramo= s principais: master e develop
Para cada nova funcionalidade a ser criada no sistema ser=C3=A1 gerado u= m ramo feature pr=C3=B3prio a partir da =C3=BAltima vers=C3= =A3o do develop, o ramo mais est=C3=A1vel em desenvolvimento. O te= mpo de vida do novo ramo poder=C3=A1 variar de acordo com o = tamanho da nova funcionalidade, por=C3=A9m, ap=C3=B3s finalizado ser=C3=A1 = mesclado com o develop e exclu=C3=ADdo em seguida.
Caso seu projeto possua um gerenciador de tarefas, como Jira ou Redmine,=
=C3=A9 uma boa pr=C3=A1tica criar os ramos do tipo feature=
em> com o nome dos tickets, ex.: feature/<n=C3=BAmero do tick=
et>
, facilitando a identifica=C3=A7=C3=A3o e objetivo do ramo.
Figura 1.2 - Os branches feature s= =C3=B3 interagem com o develop
Assim que o ramo develop estiver pronto para um lan=C3=A7a= mento, seja por ac=C3=BAmulo de novos recursos ou data pr=C3=A9-definida, u= m ramo release deve ser gerado a partir do develop, = dando in=C3=ADcio a um novo ciclo de lan=C3=A7amento. Por serem considerada= s vers=C3=B5es "fixas", os ramos de lan=C3=A7amento s=C3=A3o isolados em um= ambiente de testes e novos recursos n=C3=A3o devem ser adicionados a eles,= apenas corre=C3=A7=C3=B5es de bug, gera=C3=A7=C3=A3o de docu= menta=C3=A7=C3=A3o e outras tarefas relacionadas ao lan=C3=A7amento.
Na etapa final de lan=C3=A7amento, o ramo release ser= =C3=A1 mesclado tanto com o master, dando origem a uma nova vers= =C3=A3o de produ=C3=A7=C3=A3o, quanto com o develop, j=C3=A1 que c= orre=C3=A7=C3=B5es de bugs e pequenos ajustes foram realizado= s durante o release. Ao final dos dois merges, o ramo&nbs= p;release =C3=A9 exclu=C3=ADdo.
Figura 1.3 - Fluxo do lan=C3=A7ame= nto de vers=C3=A3o
Normalmente os nomes dados aos ramos do tipo release =
seguem um padr=C3=A3o release/<vers=C3=A3o>
, com ve=
rs=C3=B5es incrementais, ex.: 1.0 (major version), 1.0.1 =
(minor version). O Gitflow tamb=C3=A9m adota a pr=C3=A1tica de ut=
ilizar tags para marcar os releases ap=C3=B3s irem ao&nbs=
p;master, ent=C3=A3o, ap=C3=B3s fazer o merge de um =
release para o master, uma Tag com o n=C3=
=BAmero da vers=C3=A3o pode ser criada para marcar o ponto (commit=
) do deploy.
Os ramos de manuten=C3=A7=C3=A3o (bugfix e hotfix= ) s=C3=A3o utilizados para corrigir bugs ou problemas cr=C3=ADtico= s que n=C3=A3o podem esperar o pr=C3=B3ximo ciclo de lan=C3=A7amento.
Figura 1.4 - Fluxo do hotfix
A nomenclatura usada para o hotfix e bugfix seguem o s=
eguinte padr=C3=A3o: hotfix/<vers=C3=A3o>
e bugfix=
/<vers=C3=A3o>
, onde <vers=C3=A3o> =C3=A9 o valor da nov=
a tag aplicado em master ou release ap=C3=B3s me=
sclar o ramo.
O Cronapp possui algumas funcional= idades que facilitam o trabalho com o Gitflow, veremos aqui como utilizar.<= /span>
Caso tenha d=C3=BAvidas sobre Git,= recomendamos olhar primeiro a nossa documenta=C3=A7=C3=A3o Versionamento usando Git.= p>
Ap=C3=B3s criar e exportar seu pro= jeto para algum reposit=C3=B3rio remoto, ser=C3=A1 poss=C3=ADvel acessar as= op=C3=A7=C3=B5es do menu Equipe no menu do sistema. Assim= , acesse Equipe > Git flow > Iniciar Git flow.
Ap=C3=B3s essa a=C3=A7=C3=A3o, o C= ronapp criar=C3=A1 um ramo develop a partir do master e dispo= nibilizar=C3=A1 as op=C3=A7=C3=B5es para criar os seguintes ramos: feature, release e hotfix.
Ao solicitar um novo ramo=
a partir do submenu Git flow (Figura 2.1), uma janela de =
configura=C3=A7=C3=A3o do novo ramo ser=C3=A1 aberto.
= p>
Sempre que o ramo ativo tiver sido=
criado a partir do Gitflow, o submenu Equipe s=C3=B3 exib=
ir=C3=A1 a op=C3=A7=C3=A3o Finalizar hotfix/
Ao final, =C3=A9 perguntado se des= eja excluir o ramo (Figura 2.3).
Nesta p=C3=A1gina
Conte=C3=BAdo complementar=
* As= figuras dos fluxos est=C3=A3o sob licen=C3=A7a Creative Commons Atribui= =C3=A7=C3=A3o 2.5 da Austr=C3=A1lia, foram obtidas da Atlassian e mo= dificadas.