O fluxo apresentado abaixo baseia-se no modelo de Feature Branches com release, isto é, cada nova feature gera um novo branch, que é integrado com o develop
. Esse, por sua vez, aguarda a data de liberação de uma release para ser integrado ao master
.
Nota: Os passos descritos a seguir têm por princípio a segurança e a eliminação de conflitos de merge. Por isso, os merges são feitos várias vezes, mesmo aparentando redundantes.
- Desenvolvendo uma funcionalidade nova
- Implantando uma funcionalidade nova
- Corrigindo um bug de produção
$ git checkout develop
$ git pull
$ git checkout -b funcionalidade-xx
Lerêêê, lerêêê... (trabalha, mano!)
$ git pull
$ git merge develop
$ git push
Trabalhe mais... Faça novamente o pull
+ merge develop
+ push
. De preferência, várias vezes ao dia.
Pra quê? Pra não ficar muito tempo sem integrar com o develop. Quanto mais tempo ficar sem integrar, mais risco de conflito.
Dica: Quando você faz um merge e tem muitos conflitos, principalmente em arquivos que você não mexeu, significa que você ficou muito tempo sem integrar.
Faça novamente o pull
+ merge develop
+ push
.
Agora, entre no hosting e crie um Pull Request (se for Gitlab, é Merge Request).
Depois que seu PR for aprovado:
Faça novamente o pull
+ merge develop
+ push
. Depois:
$ git checkout develop
$ git merge --no-ff funcionalidade-xx
$ git push
Ou use a interface web para fazer o merge por lá mesmo.
$ git checkout develop
$ git pull
$ git merge master
$ git push
$ git checkout master
$ git merge --no-ff develop
$ git push
Faça o deploy.
Pra quê? Para os outros membros da equipe terem acesso ao branch master
com todos os merges do develop
, quando fizerem o pull
+ merge develop
.
$ git checkout master
$ git pull
$ git checkout -b bug-xx
Lerêêê, lerêêê... (trabalha, mano!)
$ git pull
$ git merge master
$ git push
Trabalhe mais... Faça novamente o pull
+ merge master
+ push
. De preferência, várias vezes ao dia.
Pra quê? Pra não ficar muito tempo sem integrar com o master. Quanto mais tempo ficar sem integrar, mais risco de conflito.
Dica: Quando você faz um merge e tem muitos conflitos, principalmente em arquivos que você não mexeu, significa que você ficou muito tempo sem integrar.
Faça novamente o pull
+ merge master
+ push
.
Agora, entre no hosting e crie um Pull Request (se for Gitlab, é Merge Request).
Depois que seu PR for aprovado:
Faça novamente o pull
+ merge master
+ push
. Depois:
$ git checkout master
$ git merge --no-ff bug-xx
$ git push
Ou use a interface web para fazer o merge por lá mesmo.
Faça o deploy.
$ git pull
$ git checkout develop
$ git merge master
$ git push
Pra quê? Para os outros membros da equipe terem acesso à sua correção quando fizerem o pull
+ merge develop
.
fim