Controle de Versão com Git e como Otimizar seu Workflow com Git Flow

966 visualizações

Publicada em

Palestra sobre Git e a otimização do workflow de controle de versão com Git Flow, apresentada no Dev In Company no dia 18 de julho de 2015

Publicada em: Software
3 comentários
9 gostaram
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
966
No SlideShare
0
A partir de incorporações
0
Número de incorporações
13
Ações
Compartilhamentos
0
Downloads
35
Comentários
3
Gostaram
9
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Controle de Versão com Git e como Otimizar seu Workflow com Git Flow

  1. 1. Controle de Versão com Git e como Otimizar seu Workflow com git flow Lucas Mezêncio | Dev In Company 18-07-2015
  2. 2. whoami ■ Desenvolvedor Web desde 2007 ■ PHP, JavaScript, ShellScript e Python ■ Certified Scrum Master ■ Organizador do PHP-MG
  3. 3. Git ■ O que é Git ■ git flow ■ Dicas
  4. 4. O que é Git “cabeça dura, pessoas que acham que sempre tem razão, argumentativas”
  5. 5. O que é o Git “Git é um sistema de controle de versão distribuído e um sistema de gerenciamento de código fonte, com ênfase em velocidade” http://en.wikipedia.org/wiki/Git_(software)
  6. 6. O que é o Git “It's a stupid content tracker. It tracks files and folders.
 I really really designed it coming at the problem from viewpoint of a file system person, I actually have absolutely zero interest in creating a traditional SCM system.” TORVALDS, Linus
  7. 7. Porque o Git é bom? ■ Branching local simples ■ Tudo é local ■ Git é rápido ■ Git é pequeno ■ A área de staging ■ Distribuído ■ Vários tipos de workflows ■ Fácil de aprender ■ Uma puta comunidade
  8. 8. ■ O que iremos ver: ■ Trabalhar com git flow ■ Uma nova maneira de pensar o uso do Git git flow
  9. 9. Mas pra quê? 
 Git é suficiente!
  10. 10. Só um desenvolvedor Imagem de: http://www.slideshare.net/Linoark/the-gitflow-way
  11. 11. Parece bom
  12. 12. Dois desenvolvedores Imagem de: http://www.slideshare.net/Linoark/the-gitflow-way
  13. 13. Ainda parece bom
  14. 14. Realidade Imagem de: http://www.github.com
  15. 15. Afinal, o que é git flow? ■ Um conjunto de extensões para o Git ■ Um branching model simples ■ Uma solução baseada em merges Imagem de: http://nvie.com/posts/a-successful-git-branching-model/
  16. 16. Branches principais ■ master: pronto para a produção ■ develop: mais recente para a próxima release
  17. 17. Branches principais Git inicial para criar o branch develop, inicia o desenvolvimento
  18. 18. Branches de suporte ■ feature ■ release ■ hotfix
  19. 19. feature branches ■ Deve vir do branch develop ■ Deve voltar ao branch develop ■ Convenção de nome feature/*
  20. 20. feature branches ■ Criar um branch de feature ■ Quando iniciar a nova feature, partir do branch develop
 ■ $ git checkout -b feature/minha-feature develop ■ ou ■ $ git flow feature start minha-feature
  21. 21. feature branches ■ Incorporar uma feature finalizada ao develop ■ Fazer merge no branch develop
 ■ $ git checkout develop ■ $ git merge --no-ff feature/minha-feature ■ $ git branch -d feature/minha-feature ■ ou ■ $ git flow feature finish minha-feature
  22. 22. feature branches ■ A flag --no-ff evita que informações de histórico da feature sejam perdidas
  23. 23. release branches ■ Deve vir do branch develop ■ Deve voltar aos branches develop e master ■ Convenção de nome: release/*
  24. 24. release branches ■ Criando um branch de release ■ $ git checkout -b release/v1.0 develop ■ ou ■ $ git flow release start v1.0 ■ Finalizando um branch de release ■ $ git checkout master ■ $ git merge --no-ff release/v1.0 ■ $ git tag -a v1.0 ■ $ git checkout develop ■ $ git merge --no-ff release/v1.0 ■ $ git branch -d release/v1.0 ■ ou ■ $ git flow release finish v1.0
  25. 25. hotfix branches ■ Deve vir do branch master ■ Deve voltar aos branches develop e master ■ Convenção de nome: hotfix/*
  26. 26. hotfix branches ■ Criando um branch de hotfix ■ $ git checkout -b hotfix/v1.0.1 master ■ ou ■ $ git flow hotfix start v1.0.1 ■ Finalizando um branch de hotfix ■ $ git checkout master ■ $ git merge --no-ff hotfix/v1.0.1 ■ $ git checkout develop ■ $ git merge --no-ff hotfix/v1.0.1 ■ $ git branch -d hotfix/v1.0.1 ■ ou ■ $ git flow hotfix finish v1.0.1
  27. 27. Comandos Imagem de: http://danielkummer.github.io/git-flow-cheatsheet/
  28. 28. Dicas ■ Dicas de utilização do Git ■ Ferramentas
  29. 29. Aprenda Git pela linha de comando com muito amor, pare de usar GUI GUI são extremamente falhos quando se tratam de merge e branching
  30. 30. Somente algumas pessoas devem ser autorizadas a fazer merge do branch develop no master para fazer a última revisão durante o merge por líderes técnicos
  31. 31. Confira códigos alheios pelo menos uma vez ao dia é melhor conferir sempre que possível
  32. 32. Tenha certeza de que todos os testes estão passando antes de fazer push
  33. 33. Não faça push de códigos não-testados, incompletos, não-compilando, a-ser-corrigido, não-pronto-para- deploy para o Git faça push somente quando o código estiver pronto para deploy
  34. 34. Faça comentários de distinção significativas para os commits inclua ids de bugs ou histórias de usuário também
  35. 35. Nunca use a flag -m <mensagem> nos commits e siga as boas práticas das mensagens de commit ■ Primeira linha com 50 caracteres ou menos. Ela é o resumo ■ Uma linha em branco ■ O restante do texto deve ser quebrado em 72 caracteres. Ele é a descrição detalhada
  36. 36. Agrupe (git squash) os commits de uma história completa em um só antes de fazer push nós não estamos interessados nos seus commits pessoais
  37. 37. Agrupe os commits de um bug fix em apenas um commit que realmente representa aquele bug fix
  38. 38. Nunca agrupe componentes logicamente diferentes em um mesmo commit pense também no revert
  39. 39. Faça vários commits, perfeccione depois, publique apenas uma vez
  40. 40. Use o .gitignore para não levar arquivos irrelevantes nunca faça push de binários irrelevantes, pacotes, arquivos compilados, arquivos temporários, arquivos relacionados ao IDE e ao SO
  41. 41. Sempre revise seu código antes de fazer um commit confira o que você está enviando para a área de staging
  42. 42. Limpe branches não utilizados e desatualizados e nunca exclua branches remotos que não foram mesclados
  43. 43. Não faça reset sem antes fazer stash ou commit ninguém quer perder códigos, né?
  44. 44. Ferramentas ■ git flow: extensão para a linha de comando ■ git up: extensão para a linha de comando que ajuda bastante na hora de fazer pull ■ http://gitup.co/: GUI que forma o graph em tempo real ■ https://github.com/github/gitignore: Uma coleção de templates para o .gitignore
  45. 45. Referências ■ http://nvie.com/posts/a-successful-git-branching-model/ ■ https://www.atlassian.com/git/tutorials/comparing- workflows/gitflow-workflow ■ http://www.slideshare.net/Linoark/the-gitflow-way ■ http://www.slideshare.net/kenziii/gitflow-model ■ http://www.slideshare.net/lemiorhan/git-branching-model ■ http://www.slideshare.net/lemiorhan/git-and-git-workflow- models-as-catalysts-of-software-development ■ http://danielkummer.github.io/git-flow-cheatsheet/
  46. 46. FIM http://about.me/lucasmezencio http://slideshare.net/lucasmezencio

×