GIT FLOW - Passo a passo

gitflowPassoAPasso.md

Conceitos

O que é Gitflow?

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.

Definições das branchs no Gitflow:

Historic Branches:​

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).

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!

Maintenance Branches:​

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.

Release Branches:​

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.

Boas práticas

É 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).

Nomenclaturas de branchs

developer (dev, develop):

A branch developer é o único meio de comunicação direta com a branch master.

feature

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>.

hotfix

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>.

release

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.

Commits

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.

Fluxo de comandos

FLUXO DE CRIAÇÃO DE BRANCH FEATURE E MERGE NA DEVELOPER

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 fetch que faz uma busca no servidor por todos os commits e merges existentes. O segundo faz de fato um git merge da 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, ou git add . (ponto) para adicionar todas as alterações. Caso queira conferir o que foi adicionado para ser commitado (staged changes), utilize o comando git status novamente.

• 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 comando git 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 sim git push que 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 stash para 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 comando git 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 developer e depois git 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 developer para 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 comando git status, se o output desse comando estiver dizendo para você fazer um git 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.

FLUXO DE CRIAÇÃO DE BRANCH HOTFIX E MERGE NA MASTER

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.

Cursos de Git

1. Git e Github - School of Net
2. Controle de Versão com Git - DevMedia
3. Git Completo: Do Básico ao Avançado - Udemy
4. Git, Github e Git flow - Udemy
5. Git flow na prática - School of Net

Fontes e Links úteis

1. Sobre gitflow: https://imasters.com.br/agile/fluxo-de-desenvolvimento-com-gitflow
2. Rebase e merge: https://www.freecodecamp.org/news/an-introduction-to-git-merge-and-rebase-what-they-are-and-how-to-use-them-131b863785f/
3. Este gist foi baseado no gist do Cisino: https://gist.github.com/CisinoJr/dae76fbfac1262b67d33e400e5285d58

Verify Github on Galxe. gid:d2uMnSrxg5UwJhyNVtpskX