Este documento foi escrito com o objetivo de unificar as regras internas do GitFlow da empresa. Este método não está a introduzir o GitFlow puro, pois é uma mistura do GitFlow e do GitLab Flow, com as melhores práticas da empresa trabalhadas ao longo de muitos anos. Ajuda a manter um histórico limpo e legível do repositório e um melhor controlo sobre as alterações e projeto ciclos de vida.

Inicialização do repositório

Depois de inicializar o repositório, crie um desenvolver e mestre se ele não foi incluído por padrão. O ramo develop deve conter uma versão de desenvolvimento código que é um espelho do ramo master com novas funcionalidades incluídas. O master contém uma versão estável do código, representando o estado de produção. Ambos têm vida útil infinita e, em comparação com outros ramos no Git Flow, nunca serão removidos. Configure regras de proteção adequadas: exigir revisões de pull request antes de fazer o merge e exigir que as verificações de estado sejam aprovadas antes da fusão. Pode também considerar a hipótese de permitir apenas equipa membros para fundir as alterações com o master.

$ git init
$ git commit --allow-empty -m "Compromisso inicial"
$ git checkout -b develop master

NOTA: Por vezes, é importante para o projeto adicionar mais ramos infinitos, por exemplo, para representar os ambientes disponíveis. No entanto, se possível, mantenha a "regra dos dois".

Ramos de caraterísticas

Quando começar a trabalhar com uma determinada funcionalidade, certifique-se primeiro de que tem o seu desenvolver ramo sincronizado.

 $ git checkout develop && git pull --rebase

Em seguida, faça o checkout para o seu ramo de caraterísticas. Dê-lhe um nome de acordo com o esquema fornecido: caraterística-JIRA-TASK-ID ou também pode quebrar essa regra e dar-lhe um nome diferente. Neste caso, certifique-se de que não entra em conflito com os padrões reservados para o lançamento, hotfix, bugfix, desenvolvimento ou o ramo principal. Manter os IDs das tarefas do JIRA irá ajudá-lo a gerir os seus ramos de funcionalidades de forma mais eficaz.

$ git checkout -b feature-JIRA-TASK-ID develop

Este ramo deve existir enquanto o recurso em questão for desenvolvido e depois fundido com o ramo principal. Para fazer commit no seu ramo local, por favor siga este comando:

 $ git add .
 $ git commit -m "JIRA-TASK-ID: Descrição da tarefa"

É recomendado que adicione mais commits ao seu branch local, seguindo a regra "Commit early and often". No entanto, no final, eles devem ser esmagados num único commit que representa uma tarefa JIRA. Fazer commits com frequência ajuda-o a gerir o seu histórico de desenvolvimento. Quando a funcionalidade está pronta, é altura de abrir um Pull Request para desenvolver um branch. Primeiro, pode fazer push do seu branch local se este não tiver sido empurrado para muito longe:

 $ git push origin feature-JIRA-TASK-ID

Quando o ramo estiver pronto, abra o seu pedido de extração no GitHub, seguindo este artigo: https://help.github.com/en/articles/creating-a-pull-request

Antes de abrir um pull request, certifique-se do seguinte:

• a descrição correta foi dado - normalmente, seria ligar a sua tarefa JIRAmas também pode incluir algumas informações úteis relacionadas com o código atual
• CírculoCI as etapas foram concluídas com êxito
• seu foram atribuídos membros da equipa - é uma boa prática incluir todos os membros da sua equipa como cessionários
• a os revisores foram selecionados - o número de revisores depende da sua equipa
• o seu código está efetivamente pronto para revisão - dê uma última vista de olhos ao seu código, pense novamente se ainda há algo para refactorizar, teste-o localmente e garantir que está pronto para as etapas seguintes.
• existem não há conflitos de fusão e um ramo está atualizado com o desenvolvimento - se houver algum, resolvê-lo primeiro

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # use -i flag for squash
$ git push -f origin feature-JIRA-TASK-ID # Utilize isto com cuidado, pois a flag -f substitui o repositório remoto

• manter apenas os commits importantes - cada confirmação deve ser representada por uma tarefa JIRA, por exemplo, JIRA-TASK-ID: Configuração de novas funcionalidades; outros devem ser esmagado durante o rebaseamento o seu ramo com o ramo de desenvolvimento
• tem o ramo de destino adequado selecionado
• não se esquece de alterar o estado da sua tarefa JIRA

Fusão do ramo de recursos

É altura de fundir as suas alterações no ramo de desenvolvimento quando:

• o pull request foi aprovado por membros selecionados da equipa
• todos os testes foram concluídos com êxito
• não há conflitos de mesclagem e o histórico de commits parece bom

Isto pode ser feito pelo gestor de projeto ou pelo programador de funcionalidades. Para efetuar a fusão, siga estes passos:

 $ git checkout develop
 $ git merge feature-JIRA-TASK-ID
 $ git push origin develop
 $ git branch -d feature-JIRA-TASK-ID
 $ git push origin :feature-JIRA-TASK-ID

Agora, o estado da tarefa JIRA pode ser alterado.

Lançamentos

As ramificações de release devem ser criadas por uma pessoa responsável pela release atual. Normalmente, as releases são criadas periodicamente, por exemplo, de acordo com a correr ciclo de vida.

Controlo de versões semântico

Dar a um ramo de lançamento um nome apropriado e uma etiqueta correspondente não é uma tarefa fácil logo no início. É uma boa prática começar a usar o versionamento semântico (https://semver.org/) que permite um melhor controlo e torna a leitura do histórico do git mais fácil. A string da versão é construída de acordo com o esquema MAJOR.MINOR.PATCH:

• MAJOR - alteração que representa alterações incompatíveis da API
• MENOR - adicionar novas funcionalidades de forma compatível com as versões anteriores
• PATCH - adição de correcções de erros compatíveis com as versões anteriores

Também pode utilizar sufixos especiais, como os que representam ramos beta ou legacy, ou criar pré-lançamentos. Nesse caso, dê-lhe o nome correto, por exemplo, 1.1.0-beta.4, 1.1.0-beta.5 ou 1.1.0-alpha.

Fazer um lançamento

O ramo de lançamento deve ser um filho do ramo de desenvolvimento e pode conter apenas os commits relacionados com correcções de erros.

O nome do ramo deve ser baseado na versão de lançamento, com o prefixo release-: lançamento-MAJOR.MINOR.PATCH. O ramo de lançamento deve ser totalmente testado, tanto automática como manualmente no ambiente de teste. Se ocorrerem erros, esta é a última oportunidade para enviar as correcções adequadas e voltar a executar todo o processo, desde que não seja verificado positivamente e esteja pronto para processamento posterior. Então, o commit de lançamento deve ser enviado, com alterações da string da versão de lançamento atual em arquivos, como package.json. Ele também deve ter um impacto no arquivo CHANGELOG.md. Isso ajudará a rastrear todas as alterações antes de um lançamento adequado e preparar o conteúdo para o lançamento do GitHub quando o processo de mesclagem for concluído. A atualização do ficheiro único deve consistir em todas as alterações de lançamento agrupadas em três categorias: funcionalidades, correcções e manutenção.

No entanto, no primeiro passo, certifique-se de que tem os ramos develop e master actualizados.

 $ git checkout master && git pull --rebase
 $ git checkout develop && git pull --rebase
 $ git merge master
 $ git checkout -b release-M.M.P
 $ git add .
 $ git commit -m "Produto Nome da versão M.M.P"
 $ git push origin release-M.M.P

Neste ponto, pode-se decidir criar outro pull request para o master com o branch de lançamento. Pode ser uma boa ideia executar uma verificação adicional se todos os testes passarem bem na máquina remota.

 $ git checkout master
 $ git merge release-M.M.P
 $ git tag -a M.M.P # a mensagem de adição pode ser definida através do sinalizador -m
 $ git push origin M.M.P
 $ git push origin master
 $ git branch -d release-M.M.P
 $ git push origin :release-M.M.P

Em seguida, aceda à página de lançamentos do GitHub e prima o botão "Draft new release". No formulário apresentado, selecione a etiqueta da versão atual, defina o título da versão semelhante ao commit da versão (Product Name M.M.P release) e uma descrição adequada, com base no ficheiro CHANGELOG.md. Para projectos públicos, a descrição deve conter uma lista de todos os PR incluídos na versão atual.

No caso de algumas correcções de erros terem sido aplicadas no ramo de lançamento, certifique-se de que tem o ramo de desenvolvimento atualizado:

$ git checkout develop && git merge master
$ git push origin develo

Correcções e correcções de erros

A principal diferença entre um bug e as hot fixes são os seus ramos de destino.

Correção de erros

As correcções de erros devem ser aplicadas nos ramos de lançamento como a única forma de atualizar o código antes de o fundir com o master. Primeiro, crie o branch a partir do branch de funcionalidades atual. Certifique-se de que o tem atualizado localmente.

 $ git checkout release-M.M.P && git pull --rebase
 $ git checkout -b bugfix-M.M.P

Em seguida, faça o commit das alterações necessárias. Após a conclusão do processo, crie um pull request e direcione-o para o branch de lançamento. Siga as orientações da secção do ramo de recursos. O título final do commit deve corresponder ao esquema fornecido: "Bugfix M.M.P: Correção da essência do problema". Quando o pull request for aprovado, é altura de o fundir com a versão atual.

 $ git checkout release-M.M.P
 $ git merge bugfix-M.M.P
 $ git push origin release-M.M.P

Correção

Para efetuar uma correção no ramo principal, devem ser seguidos passos muito semelhantes aos de uma correção de erros, tendo em conta que o ramo de destino é agora o ramo principal.

 $ git checkout master && git pull --rebase
 $ git checkout -b hotfix-X.Y.(Z+1) # M.M.P representa a versão atual

De seguida, siga os passos de desenvolvimento habituais e, quando o processo estiver concluído, crie um pedido pull com o ramo principal como destino. Tenha em mente que o commit final deve corresponder ao esquema dado "Hotfix X.Y.(Z + 1): Correção da essência do problema". Quando todos os pontos de controlo tiverem sido aprovados com êxito, execute uma fusão com o ramo principal. Estes passos diferem dos apresentados para uma correção de erro, uma vez que precisamos de fazer o bump da versão de lançamento atual.

 $ git checkout master && git pull --rebase
 $ git merge hotfix-X.Y.(Z+1)
 $ git tag -a X.Y.(Z+1) # a mensagem de adição pode ser definida através do sinalizador -m
 $ git push origem X.Y.(Z+1)
 $ git push origem master
 $ git branch -d hotfix-X.Y.(Z+1)
 $ git push origem :hotfix-X.Y.(Z+1)
 $ git checkout develop && git merge master
 $ git push origem desenvolvimento

Folha de dicas

Repositório de inicialização

 $ git init
 $ git commit --allow-empty -m "Compromisso inicial"
 $ git checkout -b develop master
 $ git push origin develop
 $ git push origin master

Caraterísticas

$ git checkout develop && git pull --rebase
$ git checkout -b feature-JIRA-TASK-ID develop

Iniciar o desenvolvimento e as confirmações

$ git add .
$ git commit -m "IRA-TASK-ID: Descrição da tarefa" #initial commit
$ git push origin feature-JIRA-TASK-ID

Abrir pull request

Rebase e preparação para pull request

$ git checkout develop && git pull --rebase
$ git checkout feature-JIRA-TASK-ID && git rebase develop # use a flag -i para squash
$ git push -f origin feature-JIRA-TASK-ID # Use isso com cuidado, pois o sinalizador -f sobrescreve o repositório remoto

Fundir alterações e eliminar o ramo

$ git checkout develop # o ramo deve ser sincronizado com o ramo develop nesta fase
$ git merge feature-JIRA-TASK-ID
$ git push origin develop
$ git branch -d feature-JIRA-TASK-ID
$ git push origin :feature-JIRA-TASK-ID

Lançamentos

$ git checkout master && git pull --rebase
$ git checkout develop && git pull --rebase
$ git merge master
$ git checkout -b release-M.M.P

Criar commit de liberação

$ git add .
$ git commit -m "Nome do produto M.M.P release" #initial commit
$ git push origin release-M.M.P

Abrir pull request

Fundir alterações, lançar e eliminar o ramo

$ git checkout master # o ramo deve ser sincronizado com o ramo master nesta fase
$ git merge release-M.M.P
$ git tag -a M.M.P # a mensagem de adição pode ser definida através do sinalizador -m
$ git push origin M.M.P
$ git push origin master
$ git branch -d release-M.M.P
$ git push origin :release-M.M.P

Correção de erros

$ git checkout release-M.M.P && git pull --rebase
$ git checkout -b bugfix-M.M.P

$ Commit fixes
$ git add .
$ git commit -m "Bugfix M.M.P: Correção da essência do problema" # Compromisso inicial
$ git push origin bugfix-M.M.P

Abrir pull request

Fundir alterações e eliminar o ramo

$ git checkout release-M.M.P # O ramo deve ser sincronizado com o ramo de lançamento atual nesta fase
$ git merge bugfix-M.M.P
$ git push origin release-M.M.P
$ git branch -d bugfix-M.M.P
$ git push origin :bugfix-M.M.P

Correção

$ git checkout master && git pull --rebase
$ git checkout -b hotfix-X.Y.(Z+1) # M.M.P representa a versão atual

$ Commit fixes
$ git add .
$ git commit -m "Hotfix M.M.P: Correção da essência do problema" # Compromisso inicial
$ git push origin bugfix-M.M.P

Abrir pull request

Mesclar alterações, lançar e excluir ramificações

$ git checkout master # nesta fase, o ramo deve ser sincronizado com o master atual
$ git merge hotfix-X.Y.(Z+1)
$ git tag -a X.Y.(Z+1) # a mensagem de adição pode ser definida através do sinalizador -m
$ git push origem X.Y.(Z+1)
$ git push origem master
$ git branch -d hotfix-X.Y.(Z+1)
$ git push origem :hotfix-X.Y.(Z+1)
$ git checkout develop && git merge master
$ git push origem desenvolvimento

Ler mais:

• As boas práticas da Codest para a construção de software: CircleCI
• Como criar extensões do Google Chrome utilizando o estilizador de legendas da Netflix?
• React: a estrutura JavaScript mais popular