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

Lucas Mezêncio | Dev In Company 18-07-2015

whoami ■ Desenvolvedor Web desde 2007

■ PHP, JavaScript, ShellScript e Python

■ Certified Scrum Master

■ Organizador do PHP-MG

Git ■ O que é Git

■ git flow

■ Dicas

O que é Git

“cabeça dura, pessoas que acham que sempre tem razão, argumentativas”

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)

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

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

■ O que iremos ver:

■ Trabalhar com git flow

■ Uma nova maneira de pensar o uso do Git

git flow

Mas pra quê? Git é suficiente!

Só um desenvolvedor

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

Parece bom

Dois desenvolvedores

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

Ainda parece bom

Realidade

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

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/

Branches principais

■ master: pronto para a produção

■ develop: mais recente para a próxima release

Branches principais

Git inicial para criar o branch develop, inicia o desenvolvimento

Branches de suporte

■ feature

■ release

■ hotfix

feature branches

■ Deve vir do branch develop

■ Deve voltar ao branch develop

■ Convenção de nome feature/*

feature branches

■ Criar um branch de feature

■ Quando iniciar a nova feature, partir do branch develop

■ $ git checkout -b feature/minha-feature develop

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

■ $ git push origin develop

feature branches

■ A flag --no-ff evita que informações de histórico da feature sejam perdidas

release branches

■ Deve vir do branch develop

■ Deve voltar aos branches develop e master

■ Convenção de nome: release/*

release branches

■ Criando um branch de release

■ $ git checkout -b release/1.0 develop

■ Finalizando um branch de release ■ $ git checkout master

■ $ git merge --no-ff release/1.0

■ $ git tag -a 1.0

■ $ git checkout develop

■ $ git merge --no-ff release/1.0

■ $ git branch -d release/1.0

■ $ git push origin --all --tags

hotfix branches

■ Deve vir do branch master

■ Deve voltar aos branches develop e master

■ Convenção de nome: hotfix/*

hotfix branches

■ Criando um branch de hotfix

■ $ git checkout -b hotfix/1.0.1 master

■ Finalizando um branch de hotfix ■ $ git checkout master

■ $ git merge --no-ff hotfix/1.0.1

■ $ git checkout develop

■ $ git merge --no-ff hotfix/1.0.1

■ $ git branch -d hotfix/1.0

■ $ git push origin master

Dicas ■ Dicas de utilização do Git

■ Ferramentas

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

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

Confira códigos alheios pelo menos uma vez ao dia

é melhor conferir sempre que possível

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

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

Faça comentários de distinção significativas para os commits

inclua ids de bugs ou histórias de usuário também

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

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

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

Nunca agrupe componentes logicamente diferentes em um mesmo commit

pense também no revert

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

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

Sempre revise seu código antes de fazer um commit

confira o que você está enviando para a área de staging

Limpe branches não utilizados e desatualizados

e nunca exclua branches remotos que não foram mesclados

Não faça reset sem antes fazer stash ou commit

ninguém quer perder códigos, né?

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

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

FIMhttp://about.me/lucasmezencio

http://slideshare.net/lucasmezencio

54