Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Gitlab flow solo

A safe workflow to work alone with git.

  • Inicia sesión para ver los comentarios

Gitlab flow solo

  1. 1. Gitlab flow solo By @viniciusban Based on https://speakerdeck.com/ogom/gitlab-flow
  2. 2. Create a project master $ git init . or $ git clone <existing_project_url> .
  3. 3. An advice use branches & tags $ git checkout -b PRODUCTION $ git checkout master
  4. 4. Create a feature branch master feature For each new feature you'll develop $ git checkout -b my_nice_feature_branch
  5. 5. Do commits master feature As much as needed $ git add my_nice_program.py $ git commit -m 'It is really a nice feature'
  6. 6. Merge master feature Integrate with MASTER branch $ git checkout master $ git merge my_nice_feature_branch
  7. 7. Deploy production master Integrate MASTER → PRODUCTION branch. Create a tag. Make deploy. v1.0 web server deploy $ git checkout PRODUCTION $ git merge master $ git tag -a v1.0 -m '1st running version o/' $ run_my_deploy_script
  8. 8. when error occurs in production...
  9. 9. Create a branch production hotfix master To fix problems v1.0 $ git checkout PRODUCTION $ git checkout -b HOTFIX
  10. 10. Do commits production hotfix master In branch HOTFIX v1.0 $ git add program_with_error.py $ git commit -m 'I fixed that'
  11. 11. Deploy production hotfix master Integrate HOTFIX → PRODUCTION. Create a tag. Run deploy. v1.0 web server deploy v1.0.1 $ git checkout PRODUCTION $ git merge HOTFIX $ git tag -a v1.0.1 -m 'Fixed that annoying bug' $ run_my_deploy_script
  12. 12. before going on with a new feature...
  13. 13. Merge production master Integrate PRODUCTION→MASTER v1.0 v1.0.1 $ git checkout master $ git merge PRODUCTION
  14. 14. Merge production master Integrate PRODUCTION→ MASTER v1.0 v1.0.1 Now, MASTER has the same fix PRODUCTION already had.
  15. 15. Why branches? ● Old code untouched until the new one works. ● Production kept away from development and maintenance ● So: – Never commit on MASTER – Never commit on PRODUCTION – Just merge onto them
  16. 16. Why tags? ● To rewind/forward versions easily – Just a git checkout <tag> – Simplicity and speed when something goes wrong
  17. 17. Another advice delete old, unused branches $ git branch -d my_old_nice_feature_branch
  18. 18. reference ● https://speakerdeck.com/ogom/gitlab-flow

×