Palestra apresentada na PHP Conference Brasil, o maior evento de PHP da América Latina, edição 2012.
Mais informações:
- http://www.phpconference.com.br/
- https://joind.in/talk/view/7764
8. … aí que entra o …
SEMANTIC VERSIONING
• http://semver.org/
enquanto a tradução
oficial não for
mesclada
• https://github.com/rogeriopradoj/translations/blob/master/
translated/semantic-versioning/pt_BR.md
Elaborado pelo
criador do
@mojombo
11. SEMANTIC VERSIONING
é o que a gente já fazia…
http://semver.org/
X.Y.Z
major
minor
patch
…mas agora com uma regra
mais rígida…
…um manifesto!
12. Um dos principais pontos do tema é
evitar que você (e seus usuários) entre
em pânico quando seu produto cresce
de tamanho…
… e consequentemente o
número de dependências
aumenta também
https://en.wikipedia.org/wiki/Dependency_hell
23. esse é o padrão formal no
SVN (subversion)…
…que geralmente só
usuários avançados
usavam pela
complexidade…
… nos manuais de SVN
são sempre os últimos
capítulos.
Mesmo assim,
corporativamente era um
bom modelo…
… por causa de seu
controle e rigidez
(mesmo deixando os
DEVs malucos!!!)
Quem
nunca
ouviu:
“para
tudo aí
que eu
vou
mesclar!
e "tô"
dando
lock!
24. No GIT a criação de
branches é assunto
básico…
O próprio ícone do GIT
mostra uma ramificação!!!
… primeiros capítulos do
manual
O problema é que não
existe formalismo…
… o que
corporativamente poderia
ser problema
(apesar dos
DEVs
adorarem!!!)
25. A SUCCESSFUL GIT
BRANCHING MODEL
• http://nvie.com/posts/a-successful-git-branching-model/
• https://github.com/rogeriopradoj/translations/blob/master/
translated/a-successful-git-branching-model/pt_BR.md
Um modelo de
ramificação parecido
com o SVN (formal)…
…mas no GIT (sem os
problemas do SVN)
26. É o que eles
chamaram de
• Descentralizado
Centralizado
Descentralizado
porque é GIT
Centralizado pois
usa um repositório
“central”, ou
principal, que é
usado para sincronia
de todos os outros
27. Um “origin único”
para todos
Mas que não impede
que existam as
interações normais
do GIT (vários
remotos, por
exemplo)
29. Regras para nomes
de branches…
Main
- master
- develop
… facilitando a
comunicação
Supporting
- feature
- release
- hotfix
30. feature
branches
develop
release branches
hotfixes
master
Time
Tag
0.1
Feature
for future
release
Severe bug
fixed for
production:
hotfix 0.2
Major
feature for
next release
Incorporate
bugfix in
develop
Tag
0.2
Start of
release
branch for
1.0
From this point on,
“next release”
means the release
after 1.0
Only
bugfixes!
Bugfixes from
rel. branch
may be
continuously
merged back
into develop
Author: Vincent Driessen
Original blog post: http://nvie.com/archives/323
License: Creative Commons
Tag
1.0
Modelo
da
empresa
NVIE
aplicado
…
… que
até esse
momento
não tinha
nome.
31. Em pouco
tempo foi criado
o nome do
modelo…
GIT-FLOW
… e também uma ferramenta para
facilitar seu uso fora da NVIE
• https://github.com/nvie/gitflow/
• Ferramenta
CLI para agilizar o processo de implementação
do modelo git flow da NVIE.com
32. Alguns
cheatsheets para
facilitar o uso
• http://danielkummer.github.com/git-flow-cheatsheet/
• http://danielkummer.github.com/git-flow-cheatsheet/
index.pt_BR.html
33. Importante saber que existem
outros fluxos de trabalho no GIT…
…alguns famosos:
Git "OpenSource" Flow
GitHub Flow: usado pela
empresa GitHub
Nome inventado por
@rogeriopradoj :-)
Principal diferença em relação ao
NVIE git-flow: usa menos
branches, mas mantém a ideia de
repositório central
É o que é usado na maioria dos
projetos OpenSource, com a
ideia de Forks, Pull Requests etc.
34. É isso aí, pessoal!
SEMANTIC VERSIONING
GIT (*) FLOW