O documento discute o sistema de controle de versão Git e o modelo de fluxo de trabalho Git flow. Explica o que é o Git, por que é útil, e como o Git flow adiciona um modelo de ramificação para melhor organizar fluxos de trabalho com múltiplos desenvolvedores. Também fornece dicas sobre como usar o Git flow de forma eficaz e ferramentas relacionadas.

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. whoami ■ Desenvolvedor Web desde
2007
■ PHP, JavaScript, ShellScript e
Python
■ Certified Scrum Master
■ Organizador do PHP-MG

3. Git ■ O que é Git
■ git flow
■ Dicas

4. O que é Git
“cabeça dura, pessoas que acham que sempre tem
razão, argumentativas”

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. 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. 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. ■ O que iremos ver:
■ Trabalhar com git
flow
■ Uma nova maneira
de pensar o uso do
Git
git flow

9. Mas pra quê?
Git é suficiente!

10. Só um desenvolvedor
Imagem de: http://www.slideshare.net/Linoark/the-gitflow-way

11. Parece bom

12. Dois desenvolvedores
Imagem de: http://www.slideshare.net/Linoark/the-gitflow-way

13. Ainda parece bom

14. Realidade
Imagem de: http://www.github.com

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. Branches principais
■ master: pronto para a produção
■ develop: mais recente para a próxima release

17. Branches principais
Git inicial para criar o branch develop, inicia o
desenvolvimento

18. Branches de suporte
■ feature
■ release
■ hotfix

19. feature branches
■ Deve vir do branch develop
■ Deve voltar ao branch develop
■ Convenção de nome feature/*

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. 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. feature branches
■ A flag --no-ff evita que informações de
histórico da feature sejam perdidas

26. release branches
■ Deve vir do branch develop
■ Deve voltar aos branches develop e master
■ Convenção de nome: release/*

27. 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

31. hotfix branches
■ Deve vir do branch master
■ Deve voltar aos branches develop e master
■ Convenção de nome: hotfix/*

32. 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

36. Comandos
Imagem de: http://danielkummer.github.io/git-flow-cheatsheet/

37. Dicas ■ Dicas de utilização do
Git
■ Ferramentas

38. 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

39. 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

40. Confira códigos alheios pelo menos uma vez ao dia
é melhor conferir sempre que possível

41. Tenha certeza de que todos os testes estão
passando antes de fazer push

42. 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

43. Faça comentários de distinção significativas para os
commits
inclua ids de bugs ou histórias de usuário também

44. 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

45. 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

46. Agrupe os commits de um bug fix em apenas um
commit que realmente representa aquele bug fix

47. Nunca agrupe componentes logicamente diferentes
em um mesmo commit
pense também no revert

48. Faça vários commits, perfeccione depois, publique
apenas uma vez

49. 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

50. Sempre revise seu código antes de fazer um commit
confira o que você está enviando para a área de staging

51. Limpe branches não utilizados e desatualizados
e nunca exclua branches remotos que não foram mesclados

52. Não faça reset sem antes fazer stash ou commit
ninguém quer perder códigos, né?

53. 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

54. 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/

55. FIM
http://about.me/lucasmezencio
http://slideshare.net/lucasmezencio