Resumidamente, o Gitflow é um modelo fortemente baseado em branches, mas focado nas entregas. Foi criado em 2010 e hoje em dia é muito utilizado por equipes de desenvolvedores em todo o mundo.
Ao invés de trabalhar apenas com a branch master, esse workflow utiliza dois branches principais para guardar histórico do projeto. A branch master guarda o histórico oficial das entregas, já a branch developer serve como integração entre todas as branches de funcionalidades (feature branches).
Cada funcionalidade deve ter sua própria branch, e ela deve ser criada a partir da branch developer. Quando uma funcionalidade for concluída, ela é mesclada (merged) novamente com a sua branch pai. As features nunca devem interagir diretamente com a master. NUNCA!
Também conhecidas como hotfix. Elas são usadas para corrigir rapidamente algum problema em produção. Este é a única branch que deve ser criada a partir do master. Assim que a correção for finalizada, o branch é fechada e mesclada com a master e developer, mantendo assim as linhas completamente atualizadas.
Quando a branch developer estiver com funcionalidades suficientes para uma entrega, é criada uma branch de entrega (release branch). Com isso, é dado início ao próximo ciclo de entrega, ou seja, nenhuma nova funcionalidade pode ser incluída a partir deste momento. Quando estivermos prontos para realizar a entrega, a release é mesclada com as branches master e developer.
É extremamente indicado executar o comando "git fetch" várias vezes ao dia, principalmente ao iniciar o trabalho e antes de fazer merge da sua feature. Por quê? Porque dessa forma, você garante que a estoria do seu repositório local esteja sempre atualizada com a do servidor. O Gitflow já nos traz um padrão de nomenclatura para a criação de branchs (tirando master, que deve ser mantida por definição do próprio Git).
A branch developer é o único meio de comunicação direta com a branch master.
As features são branchs para desenvolver novas funcionalidades, e são geradas a partir da developer. Ao final do ciclo de vida mesclam (fazem merge) de volta para a developer. Convenção de nomenclatura: feature/<nome_da_nova_funcionalidade>.
Seguem o mesmo padrão das branchs de feature, e essas branchs geralmente são criadas para correções de bugs de uma release, que não podem esperar por uma próxima release. As hotfix são criadas diretamente na master. Convenção de nomenclatura: hotfix/<nome_da_funcionalidade>.
Nem sempre são usadas. As releases são branch usadas para preparação do lançamento da próxima versão de produção. Na criação do branch de lançamento é decidido qual versão o projeto terá, até este momento a branch developer reflete as alterações da próxima versão, independente de qual for. Convenção de nomenclatura: release/MAJOR.MINOR.PATCH.
As mensagens de commits são muito importantes. Elas possuem duas partes: um header e um body. No header você deve descrever de forma sucinta o que você implementou/corrigiu. No body, você pode escrever de forma mais detalha tudo o que você fez. E lembre-se, de preferência os seus commits devem conter poucas modificações sobre um mesmo assunto/contexto.
Sempre ao atualizar uma branch (fazer git pull), utilize a flag --rebase (git pull --rebase), isso evita que seja criado um commit de merge da branch que você está atualizando, nela mesma, mantendo uma estoria limpa.
A) Atualizar a developer
Antes de começar a trabalhar individualmente em uma branch separada, é preciso atualizar a branch developer para a partir dela criarmos uma branch feature. Seguem os passos:
- 1- Primeiramente check se você de fato está na branch developer, para isso utilize o comando
git branch. - 2- Estando na branch developer, para atualizar a mesma com a branch do servidor (origin), utilize o comando
git pull --rebase. - Explicação do comando 'git pull --rebase' - O comando anterior atualizou a branch impedindo que fosse criado um commit de merge. O motivo é que ao realizar git pull, 2 comandos são executados por debaixo dos panos. O primeiro é
git fetchque faz uma busca no servidor por todos os commits e merges existentes. O segundo faz de fato umgit mergeda developer do servidor na developer da sua máquina (local). Para que não ocorra o risco de fazer push do commit gerado por esse merge, é utilizada a flag--rebase. Com isso sua developer local fica atualizada e livre de efeitos colaterais.
B) Criando uma branch feature (nova funcionalidade)
- 1- Estando já com a developer atualizada, utilize o comando
git checkout -b feature/<nome-da-funcionalidade>para criar uma nova branch a partir da developer. - 2- Com a sua branch criada agora é possível trabalhar somente nela e sempre que tiver completado uma etapa do desenvolvimento, subir para a branch remota (origin).
C) Commitando na branch feature
-
1- Primeiramente verifique todas as alterações realizadas até o momento por meio do comando
git status. -
2- Após verificar, para adicionar os arquivos que deseja que sejam commitados, utilize o comando
git add <nome-arquivo1> <nome-arquivo2> <nome-arquivoN>para adicionar separadamente cada arquivo, ougit add .(ponto) para adicionar todas as alterações. Caso queira conferir o que foi adicionado para ser commitado (staged changes), utilize o comandogit statusnovamente. -
3- Após se certificar de que todas as alterações desejadas já estão prontas para serem commitadas, utilize o comando
git commit -am "Mensagem de commit aqui". Esse comando tem a flag -a (adiciona todos os arquivos caso tenha esquecido de fazer na etapa anterior) e -m (mensagem do commit seguido de aspas). -
4- Para finalizar, e já definir a sua branch como a origin padrão dos próximos commits, digite o comando
git push. Caso tudo esteja ok com sua branch, irá surgir uma mensagem dizendo que é possível deixar definido sua branch origin como a sua local por meio do comandogit push --set-upstream origin <nome-da-sua-branch-feature>. Copie esse comando, cole no console e execute. Pronto, você acaba de realizar subir seu primeiro commit dessa branch freature. -
Explicação do comando 'git push' somente Fazendo o passo anterior, não será mais preciso, para todo novo commit, ter que digitar
git push origin <nome-da-sua-branch-feature>e simgit pushque o git já saberá que é um puch para a sua branch.
D) Atualizando a branch feature com a developer (rebase da developer na sua branch):
Ponderações Iniciais | LEIA COM ATENÇÃO É importante de tempos em tempos, manter a sua branch feature atualizada em relação a developer, para que quando for realizado o merge com a developer, o número de conflitos sejam menores. Antes de qualquer coisa, certifique-se de que você não tenha NENHUM COMMIT para fazer ou alterações que não foram commitadas ainda. Caso existam alterações, e você não pode subir elas no momento, utilize o comando
git stashpara salvar os arquivos modificados em uma branch temporária, e depois de realizar o rebase completamente (que será descrito nos próximos passos), você pode trazer de volta esses arquivos com o comandogit stash pop.
-
1- Para começarmos o rebase da developer na nossa branch, primeiramente será preciso atualizar a developer local com a developer remota (origin), para isso vá para a branch developer utilizando o comando
git checkout developere depoisgit pull --rebase. -
2- Após ter atualizado a developer, retorne para a sua branch utilizando o comando
git checkout <nome-da-sua-branch-feature> -
3- De volta a sua branch, e já com a developer atualizada, utilize o comando
git rebase developerpara atualizar (rebasear) sua branch em relação a developer. Repare que nesse processo poderão surgir conflitos. Caso isso ocorra, você precisará resolvê-los. -
4- Para resolver os conflitos, você pode fazer diretamente com o VS Code, ou com uma ferramenta especializada como o TortoiseGit . Caso haja necessidade de resolver um conflito específico com algum colega de equipe, não exite em contatá-lo para esclarecerem as dúvidas e mergearem os dados de forma correta na sua branch.
-
5- A cada resolução de conflito, será preciso executar o comando
git rebase --continue. -
6- Caso exista alguma dúvida quanto a execução do rebase, ou existam conflitos que necessitem de um terceiro que esteja ausente, você pode a qualquer momento abortar o processo com o comando
git rebase --abort -
7- Caso tenha resolvido todos os conflitos, e mesmo usando o rebase --continue o git não permita você prosseguir, pode ser o caso de ele já ter resolvido os conflitos, e ele está ignorando a sua resolução. Nesse caso, você deverá utilizar o
git rebase --skip -
8- Após ter finalizado todo o processo e todos os conflitos já foram resolvidos, é chegado o momento de subir essas alterações para a sua branch origin (servidor). Porém caso você tente executar
git push, vai dar erro, pois é muito provável que a sua branch local esteja divergindo da branch remota (você pode verificar isso ao executar o comandogit status, se o output desse comando estiver dizendo para você fazer umgit pull, significa que sua branch local está, de fato, divergindo da remota). Isso se deve ao fato de a sua branch no servidor não ter as diversas alterações que entraram no merge feito pelo rebase da developer na sua branch. Para que a branch do servidor aceite o push, será necessário utilizar a flag--force. -
9- Para subir a branch para o servidor, utilize o comando
git push --force-with-lease. Usamos o -with-lease apenas por questões de segurança caso um outro colega tenha feito commit também (issue do stackoverflow.
E) Merge da branch feature com a developer
-
1- Estando com a sua branch feature atualizada com a developer. Já é possível realizar o merge caso seja o momento oportuno.
-
2- Para isso volte para a branch developer com o comando:
git checkout developer(ou outro nome que sua equipe tenha adotado, como: dev ou developer) -
2- Execute o comando:
git merge --no-ff <feature/nome_funcionalidade>. A flag --no-ff é utilizada para não deixar o git fazer um fast-foward, ou seja, ele irá manter o histórico da branch que está voltando para developer. -
3- Após executar o comando acima no terminal, caso apareça o editor Vim com a mensagem de commit gerada automaticamente, utilize o comando :wq e aperte ENTER para sair do editor e finalizar o merge. Não é necessário alterar a mensagem padrão de commit do merge.
-
4- Rode o projeto e teste, se tudo estiver certo, execute o comando git push, para subir o seu merge para a branch developer remota.
OBS: Caso a master seja intocável, os passos descritos nesse fluxo serão feitos baseados na developer
A) Atualizar a master Antes de começar a trabalhar individualmente em uma branch separada, é preciso atualizar a branch master para a partir dela criarmos uma branch hotfix. Seguem os passos:
- 1- Primeiramente check se você de fato está na branch master, para isso utilize o comando
git branch. - 2- Estando na branch master, para atualizar a mesma com a branch do servidor (origin), utilize o comando
git pull --rebase.
B) Criando uma branch feature (nova funcionalidade)
- 1- Estando já com a master atualizada, utilize o comando
git checkout -b hotfix/<nome-da-funcionalidade>para criar uma nova branch a partir da developer. - 2- Com a sua branch criada agora é possível trabalhar somente nela e sempre que tiver completado uma etapa do desenvolvimento, subir para a branch remota (origin).
OS DEMAIS PASSOS PODEM SEGUIR O MESMO FLUXO DA BRANCH FEATURE, DESCRITOS ACIMA.
- Git e Github - School of Net
- Controle de Versão com Git - DevMedia
- Git Completo: Do Básico ao Avançado - Udemy
- Git, Github e Git flow - Udemy
- Git flow na prática - School of Net
- Sobre gitflow: https://imasters.com.br/agile/fluxo-de-desenvolvimento-com-gitflow
- Rebase e merge: https://www.freecodecamp.org/news/an-introduction-to-git-merge-and-rebase-what-they-are-and-how-to-use-them-131b863785f/
- Este gist foi baseado no gist do Cisino: https://gist.github.com/CisinoJr/dae76fbfac1262b67d33e400e5285d58
Verify Github on Galxe. gid:d2uMnSrxg5UwJhyNVtpskX