Gitlab flow solo (pt-BR)

611 visualizações

Publicada em

Workflow seguro para trabalhar sozinho com git.

Publicada em: Software
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
611
No SlideShare
0
A partir de incorporações
0
Número de incorporações
7
Ações
Compartilhamentos
0
Downloads
13
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

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

×