Gitlab flow solo (pt-BR)
3 gostaram1,051 visualizações
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.
Gitlab flow solo (pt-BR)
- 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