Gitlab flow solo (pt-BR) 
Por @viniciusban Baseado em https://speakerdeck.com/ogom/gitlab-flow
Crie um projeto 
master 
$ git init . 
ou 
$ git clone <url_do_projeto_ja_existente> .
Uma dica 
use branches & tags 
$ git checkout -b PRODUCAO 
$ git checkout master
Crie um feature branch 
master 
feature 
Para cada funcionalidade que será desenvolvida 
$ git checkout -b minha_nova_func...
Faça commits 
master 
feature 
Quantos forem necessários 
$ git add meu_novo_programa.py 
$ git commit -m 'Essa funcionali...
Merge 
master 
feature 
Integre com o branch MASTER 
$ git checkout master 
$ git merge minha_nova_funcionalidade
Deploy 
producao 
master 
Integre MASTER → PRODUCAO. 
Crie uma tag. 
Faça deploy. 
v1.0 
servidor 
web 
deploy 
$ git chec...
quando houver erro 
em produção...
Crie um branch 
producao 
correcao 
master 
Para corrigir o erro 
v1.0 
$ git checkout PRODUCAO 
$ git checkout -b CORRECA...
Faça commits 
producao 
correcao 
master 
No branch CORRECAO 
v1.0 
$ git add programa_com_erro.py 
$ git commit -m 'Pront...
Deploy 
producao 
correcao 
master 
Integre CORRECAO → PRODUCAO. 
Crie uma tag. 
Faça deploy. 
v1.0 
servidor 
web deploy ...
antes de continuar 
nova feature...
Merge 
producao 
master 
Integre PRODUCAO→ MASTER 
v1.0 
v1.0.1 
$ git checkout master 
$ git merge PRODUCAO
Merge 
producao 
master 
Integre PRODUCAO → MASTER 
v1.0 
v1.0.1 
MASTER, agora, tem 
a mesma correção 
que PRODUCAO
Por que branches? 
● Código antigo intacto até saber se o novo 
funciona 
● Produção separada do desenvolvimento e 
manute...
Por que tags? 
● Para voltar versão facilmente 
– Apenas um git checkout <tag> 
– Rapidez e simplicidade em caso de emergê...
Outra dica 
apague os branches 
antigos e sem uso 
$ git branch -d minha_antiga_funcionalidade
referência 
● https://speakerdeck.com/ogom/gitlab-flow
Próximos SlideShares
Carregando em…5
×

Gitlab flow solo (pt-BR)

746 visualizações

Publicada em

Workflow seguro para trabalhar sozinho com git.

Publicada em: Software

Gitlab flow solo (pt-BR)

  1. 1. Gitlab flow solo (pt-BR) Por @viniciusban Baseado em https://speakerdeck.com/ogom/gitlab-flow
  2. 2. Crie um projeto master $ git init . ou $ git clone <url_do_projeto_ja_existente> .
  3. 3. Uma dica use branches & tags $ git checkout -b PRODUCAO $ git checkout master
  4. 4. Crie um feature branch master feature Para cada funcionalidade que será desenvolvida $ git checkout -b minha_nova_funcionalidade
  5. 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. 6. Merge master feature Integre com o branch MASTER $ git checkout master $ git merge minha_nova_funcionalidade
  7. 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. 8. quando houver erro em produção...
  9. 9. Crie um branch producao correcao master Para corrigir o erro v1.0 $ git checkout PRODUCAO $ git checkout -b CORRECAO
  10. 10. Faça commits producao correcao master No branch CORRECAO v1.0 $ git add programa_com_erro.py $ git commit -m 'Pronto, consertei'
  11. 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. 12. antes de continuar nova feature...
  13. 13. Merge producao master Integre PRODUCAO→ MASTER v1.0 v1.0.1 $ git checkout master $ git merge PRODUCAO
  14. 14. Merge producao master Integre PRODUCAO → MASTER v1.0 v1.0.1 MASTER, agora, tem a mesma correção que PRODUCAO
  15. 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. 16. Por que tags? ● Para voltar versão facilmente – Apenas um git checkout <tag> – Rapidez e simplicidade em caso de emergência
  17. 17. Outra dica apague os branches antigos e sem uso $ git branch -d minha_antiga_funcionalidade
  18. 18. referência ● https://speakerdeck.com/ogom/gitlab-flow

×