O documento descreve o fluxo Gitlab para desenvolvimento e deploy de aplicações. Ele explica como criar branches para novas funcionalidades e correções, fazer commits, integrar branches através de merge e realizar deploy em produção com tags. O fluxo mantém branches separadas para desenvolvimento, produção e correções, integrando-as através de merges controlados.

1. Gitlab flow solo (pt-BR)
Por @viniciusban Baseado em https://speakerdeck.com/ogom/gitlab-flow

2. Crie um projeto
master
$ git init .
ou
$ git clone <url_do_projeto_ja_existente> .

3. Uma dica
use branches & tags
$ git checkout -b PRODUCAO
$ git checkout master

4. Crie um feature branch
master
feature
Para cada funcionalidade que será desenvolvida
$ git checkout -b minha_nova_funcionalidade

5. Faça commits
master
feature
Quantos forem necessários
$ git add meu_novo_programa.py
$ git commit -m 'Essa funcionalidade eh muito boa'

6. Merge
master
feature
Integre com o branch MASTER
$ git checkout master
$ git merge minha_nova_funcionalidade

7. Deploy
producao
master
Integre MASTER → PRODUCAO.
Crie uma tag.
Faça deploy.
v1.0
servidor
web
deploy
$ git checkout PRODUCAO
$ git merge master
$ git tag -a v1.0 -m 'Primeira versao de producao o/'
$ rodar_meu_script_de_deploy

8. quando houver erro
em produção...

9. Crie um branch
producao
correcao
master
Para corrigir o erro
v1.0
$ git checkout PRODUCAO
$ git checkout -b CORRECAO

10. Faça commits
producao
correcao
master
No branch CORRECAO
v1.0
$ git add programa_com_erro.py
$ git commit -m 'Pronto, consertei'

11. Deploy
producao
correcao
master
Integre CORRECAO → PRODUCAO.
Crie uma tag.
Faça deploy.
v1.0
servidor
web deploy
v1.0.1
$ git checkout PRODUCAO
$ git merge CORRECAO
$ git tag -a v1.0.1 -m 'Corrigi aquele bug chato'
$ rodar_meu_script_de_deploy

12. antes de continuar
nova feature...

13. Merge
producao
master
Integre PRODUCAO→ MASTER
v1.0
v1.0.1
$ git checkout master
$ git merge PRODUCAO

14. Merge
producao
master
Integre PRODUCAO → MASTER
v1.0
v1.0.1
MASTER, agora, tem
a mesma correção
que PRODUCAO

15. Por que branches?
● Código antigo intacto até saber se o novo
funciona
● Produção separada do desenvolvimento e
manutenção
● Portanto:
– Nunca commit direto em MASTER
– Nunca commit direto em PRODUCAO
– Só faça merge neles

16. Por que tags?
● Para voltar versão facilmente
– Apenas um git checkout <tag>
– Rapidez e simplicidade em caso de emergência

17. Outra dica
apague os branches
antigos e sem uso
$ git branch -d minha_antiga_funcionalidade

18. referência
● https://speakerdeck.com/ogom/gitlab-flow