O modelo de gerenciamento de controle de versão da Incorp foi baseado OneFlow, uma simplificação do GitFlow.
A premissa básica é ter uma branch principal eterna por projeto (develop).
A manutenção de um único ramo de longa duração simplifica consideravelmente o esquema de controle de versão e as operações diárias que os desenvolvedores têm que realizar .
Ele também torna o histórico do projeto mais limpo e mais legível, e, portanto, mais útil.
Enquanto o modelo defende ter um ramo de longa duração, isso não significa que não existem outros ramos envolvidos. Pelo contrário, o modelo de ramificação incentiva o uso de uma variedade de ramos de suporte (veja abaixo os detalhes). O que é importante, porém, é que eles são destinados a ser de curta duração, e seu principal objetivo é facilitar a partilha de código e agir como um backup. O histórico é sempre baseado em um ramo de vida infinito.
Para encontrar a versão de produção mais recente, foi criado uma branch (main) de longa duração cujo único objetivo é apontar para o último commit liberado para produção.
O número da versão segue o padrão Versionamento Semântico.
O modelo contempla as seguintes branches:
Ramo principal e de longa duração do projeto, onde serão realizados a maior parte do trabalho do dia a dia.
Ramo de longa duração criado com único objetivo de apontar para o último commit liberado para produção.
Os ramos de stories (também chamados às vezes ramos tópicos) são onde o trabalho de desenvolvimento do dia-a-dia acontece - daí, eles são de longe o mais comum de todos os ramos de suporte. Eles são usados para desenvolver novos recursos e correções de bugs para a próxima versão. Eles são nomeados da seguinte forma story/[id-item].
Os ramos de stories, após finalizar o trabalho, devem ser mesclados com develop e apagados.
Os ramos de release são criados para preparar o software para ser liberado. Obviamente, o que exatamente isso significa varia em uma base do projeto-por-projeto. Isso pode ser tão simples quanto incrementar o número da versão na configuração ou envolver coisas como congelamento de código, produzir Candidatos para Liberação e ter um processo de Garantia de Qualidade Completo. O importante é tudo o que acontece em um ramo separado, para que o desenvolvimento do dia a dia possa continuar como de costume no develop.
A convenção de nomenclatura para estes é release/
Os ramos de hotfix são muito semelhantes aos ramos de lançamento - eles resultam em uma nova versão do projeto sendo lançado. Onde eles diferem são suas intenções - enquanto os ramos de lançamento significam um marco de produção planejado, os ramos de hotfix são na maioria das vezes uma exceção indesejada, mas necessária, da cadência de release usual, geralmente por causa de algum defeito crítico encontrado na última versão que precisa ser corrigido logo que possível.
Eles são nomeados hotfix/numero da versão. Ex. hotfix/v1.2.6
Observe que no Versionamento Semântico as versões regulares incrementam o número maior ou menor, enquanto os hotfixes incrementam o número do patch.
Os ramos de spike servem para documentar as pesquisas realizadas pela equipe para diminuir a incerteza de uma implementação, melhorando assim a estimativa do item de trabalho. Esses ramos não são excluidos, ficando para futuras consultas.
Eles são nomeados spike/numero do item. Ex. spike/nex-123
Uma caracteristica desse ramo é que nele deve existir um arquivo readme que mostra como implementar o spike, bem como um modelo da implementação.
Iniciando um ramo story.
$ git checkout -b story/[id-item]
Finalizando um ramo story.
$ git checkout develop
$ git pull
$ git merge story/[id-item]
$ git push
$ git push origin :story/[id-item]
$ git branch -d story/[id-item]
Iniciando um ramo release
$ git checkout -b release/v2.3.0 9efc5d [from develop]
Finalizando um ramo release.
$ git checkout release/v2.3.0
$ git tag v2.3.0
$ git checkout develop
$ git merge release/v2.3.0
$ git push --tags origin develop
$ git branch -d release/v2.3.0
E aqui está a etapa extra - fast-forwarding do main para a tag de lançamento mais recente.
$ git checkout main
$ git merge --ff-only v2.3.0
Iniciando um ramo hotfix
$ git checkout -b hotfix/v2.3.1 main
Finalizando um ramo hotfix.
$ git checkout hotfix/v2.3.1
$ git tag 2.3.1
$ git checkout develop
$ git merge hotfix/v2.3.1
$ git push --tags origin develop
$ git branch -d hotfix/v2.3.1
E aqui está a etapa extra - fast-forwarding do main para a tag de lançamento mais recente.
$ git checkout main
$ git merge --ff-only v2.3.1
Iniciando um ramo de spike
$ git checkout -b spike/nex-123