This is the slides of my latest talk in DevFest Istanbul 2013 which is organized by Google Developers Group Istanbul. The content mainly has 3 sections. Git branching model in theory, creating a feature by git commands and git best practices.

1. GIT & GIT workflow MODELs
AS CATALYSTS OF SOFTWARE DEVELOPMENT
@lemiorhan
Lemİ Orhan ERGİN
lemiorhanergin.com
@lemiorhan

2. Lemİ Orhan Ergİn
CSM, PSM1
2013
Principal Software Engineer at Sony
2001
has worked in Tüsside, BYM, GittiGidiyor/eBay
and Sony as lead developer, technical leader,
technical coordinator and scrum master
2009
2
2005
using Git, but not an expert
agile
0.5M
experienced in agile transformation and
building agile culture in teams & organisations
organisational level SVN to GIT migration
projects experienced so far
doing code reviews as a daily habit
total number of views of his presentations

3. I love
git

4. I love
git
because…
I used SVN for a while
Local branching is cheap
Everything is local
Distributed
Ruby on Rails with full history
and branches weight 13Mb.
Small and efficient
It weights 115Mb in SVN
Any workflow
Each object is compressed by
zlib and transferred over wire
Lightening Fast
one by one
Huge community
More than 3M people˝
More than 5M repositories˝
GitHub… Thanks God!
Raised $100 million on July'12

5. git data model is
hot
It is a directed acyclic graph
Objects (blob, tree, commit, tag) are immutable
References (branch, remote) always change

6. Stop comparing SVN with GIT
It is not a magical version of SVN. Try to understand what it's actually doing.

7. “
It's a stupid content tracker.
It tracks files and folders.
I really really designed it coming at the
problem from the viewpoint of a file
system person, I actually have
absolutely zero interest in creating a
traditional SCM system.
LINUS TOVALDS
”

8. git
changed the way we think of
merging
branching
workflows

9. git is a tool for designing vcs workflows

10. main branches
supporting branches
Feature development
release development
hot fixes in production
git
workflow
model

11. main branches
main branches are permanent branches
which are created at the very beginning
and n
ever
d
elete
d!

12. main branches
OPTıONAL
development
It reflects the latest
delivered development
changes for the next
release
Automatic nightly
builds
test & QA
STAGING & UAT
MASTER
Production

13. main branches
OPTıONAL
development
test & QA
It reflects the code which
is deployed to test/qa
environment for testing
Automatic nightly
builds
Automatically
deployed to test/qa
servers every night
STAGING & UAT
MASTER
Production

14. main branches
OPTıONAL
development
test & QA
STAGING & UAT
It reflects the code which
is deployed to staging/uat
environment for testing
Automatic nightly
builds
Automatically
deployed to staging
servers every night
Automatically
deployed to test/qa
servers every night
MASTER
Production

15. main branches
OPTıONAL
development
test & QA
STAGING & UAT
MASTER
Production
It reflects the code which
is deployed to production
Automatic nightly
builds
Automatically
deployed to staging
servers every night
Automatically
deployed to test/qa
servers every night
Automatically
deployed to
production servers
on demand

16. supporting branches
feature branches
HOTFIX branches
release branches
These have limited life time
and will be removed eventually

17. supporting branches
feature branches
HOTFIX branches
release branches
These have specific purpose
and strict rules for originating and target branches

18. Feature development
All feature branches should be created from
The development branch
the n
ext r
eleas
e bra
nch

19. Feature development
take a new feature branch
regardless of the feature size
you ca
comm n fix v
in dev on issue ery mino
elopm s direc r
like f ent b tly
ixing ranch
typos ,

20. Feature development
Ne
Feature 1
Feature 2
2
Feature 2 is
completed and ready for
the next release
Feature 3
xt
development Rel
ea
se

21. Ne
Feature development
Feature 1
Feature 1 is being
developed
Feature 2
2
1
Feature 3
xt
development Rel
ea
se

22. Feature development
Ne
Feature 1
Feature 2
Feature 3
xt
development Rel
ea
se
2
1
D
Feature 2 is completed and
merged back to master

23. Ne
Feature development
Feature 1
Feature 1 gets the
commits in Feature 2
Feature 2
Feature 3
development Rel
ea
se
2
1
D
1
xt

24. Ne
Feature development
Feature 1
Pulls all the commits
from other features and
resolve conflicts
Feature 2
Feature 3
development Rel
ea
se
2
1
D
1
1
xt
D

25. Feature development
Ne
Feature 1
Feature 2
Feature 3
xt
development Rel
ea
se
2
1
D
1
D
1
3
Feature 3 is created from
development. It has commits
of Feature 2

26. Feature development
Ne
Feature 1
Feature 2
Feature 3
xt
development Rel
ea
se
2
1
D
1
D
1
3
D
Feature 1 is completed and
merged back to master

27. Feature development
Ne
Feature 1
Feature 2
Feature 3
development Rel
ea
se
2
1
D
1
D
1
3
D
3
Feature 3 gets the
commits of Feature 1
xt

28. Feature development
Ne
Feature 1
Feature 2
Feature 3
development Rel
ea
se
2
1
D
1
D
1
3
D
3
3
Feature 3 pull updates
frequently
xt
D

29. Feature development
Ne
Feature 1
Feature 2
Feature 3
xt
development Rel
ea
se
2
1
D
1
D
1
3
D
3
3
D
D
Typo is fixed directly in
development branch

30. Feature development
Ne
Feature 1
Feature 2
Feature 3
development Rel
ea
se
2
1
D
1
D
1
3
D
3
Feature 3 pulls commit
about fixing the typo
3
3
xt
D
D

31. Feature development
Ne
Feature 1
Feature 2
Feature 3
xt
development Rel
ea
se
2
1
D
1
D
1
3
D
3
3
D
D
3
D
Feature 3 is completed
and merged back to master.
It has commits of all 3
features now.

32. release development
Release branch is created when
all features are ready for the next release
some
featu times w
re fre e call
eze it as

33. release development
Release branch is deleted when
the release completes
we w
code, ill tag t
branc no need he releas
to ke ed
h..
ep th
e

34. release development
el
N
t
ex
s
ea
e
R development
F
D
F
D
Completed features are
merged with development
release
MASTER
Production

35. release development
el
N
t
ex
s
ea
e
R development
F
D
F
D
D
All features are ready for
the next release
release
MASTER
Production

36. release development
el
N
t
ex
s
ea
e
R development
release
MASTER
Production
F
D
F
D
Start a release branch
when features are freezed
D
R

37. release development
el
N
t
ex
s
ea
e
R development
release
MASTER
Production
F
D
F
D
D
R
Only fixes are allowed
R
D
R
Bug fixes are
continuously merged back
to development brach
D

38. release development
el
N
t
ex
s
ea
e
R development
release
MASTER
Production
F
D
F
D
D
R
R
D
R
D
R
Release is ready now

39. release development
el
N
t
ex
s
ea
e
R development
release
F
D
F
D
D
R
R
D
R
Latest fixes are merged
back to development branch
D
R
D
MASTER
Production

40. release development
el
N
t
ex
s
ea
e
R development
release
MASTER
Production
F
D
F
D
D
R
R
D
R
D
Merge release branch
with master branch
and get a new tag
R
D
M

41. hot fixes in production
Fix branches are required because every fix should be
well tested and verified
it me
to rol ans, you
done i lback w may nee
n the hat yo d
fix
u’ve

42. hot fixes in production
el
N
t
ex
s
ea
e
R development
Hot-FIX
MASTER
Production
Hot fix is required! A
new branch is created from
production branch
M

43. hot fixes in production
el
N
t
ex
s
ea
e
R development
Hot-FIX
MASTER
Production
M
Fix is developed, tested and
verified. Ready to go.
H

44. hot fixes in production
el
N
t
ex
s
ea
e
R development
Hot-FIX
MASTER
Production
M
H
D
Hot fixes are merged back
to development branch

45. hot fixes in production
el
N
t
ex
s
ea
e
R development
Hot-FIX
MASTER
Production
M
H
Hot fix is merged with
production branch and
production branch is tagged
D
M

46. ALL FLOWS IN THE MODEL
This graphic is taken from Vincent
Driessen’s article called
“a successful git branching model”

47. feature development

48. 1
creatE permanent branches
If these does not exist
➜ git:(master) git checkout -b development
Switched to a new branch 'development'
➜ git:(development) git push origin development
Total 0 (delta 0), reused 0 (delta 0)
To UberProject.git
* [new branch] development -> development
➜ git:(development) git branch -a
* development
master
remotes/origin/development
remotes/origin/master
it cre
branc ates de
v
pushe h from m elopme
s to r aste nt
emot r and
e

49. 2
Pull to update
local development branch
be sure you run tests directly afterwards
➜ git:(master) git fetch origin
From UberProject
* [new branch] development -> origin/development
➜ git:(master) git checkout development
Branch development set up to track remote branch development from origin.
Switched to a new branch ‘development'
➜ git:(development) git pull
remote: Counting objects: 19, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 17 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (17/17), done.
From UberProject
3eb8b34..c827c84 development -> origin/development
Updating 3eb8b34..c827c84
Fast-forward
grails-app/controllers/org/example/BookController.groovy | 6 ++++++
grails-app/domain/org/example/Book.groovy | 7 +++++++
test/unit/org/example/BookControllerTests.groovy | 17 +++++++++++++++++
test/unit/org/example/BookTests.groovy | 17 +++++++++++++++++
4 files changed, 47 insertions(+)
create mode 100644 grails-app/controllers/org/example/BookController.groovy
create mode 100644 grails-app/domain/org/example/Book.groovy
create mode 100644 test/unit/org/example/BookControllerTests.groovy
create mode 100644 test/unit/org/example/BookTests.groovy

50. 3
create a feature branch
from development
with a name having story id and descriptive title
➜ git:(development) git checkout -b feature-1185-add-commenting
Switched to a new branch 'feature-1185-add-commenting'
➜ git:(feature-1185-add-commenting)
the t
hints itle shou
about ld giv
what e
’s in
it

51. 4
work in your feature branch
commit early and often
Be careful!
“push early it does not mean
and often”
➜ git:(feature-1185-add-commenting) vi web-app/WEB-INF/applicationContext.xml
➜ git:(feature-1185-add-commenting) ✗ git add .
➜ git:(feature-1185-add-commenting) ✗ git commit -m "added comment for applicationContext.xml"
[feature-1185-add-commenting b6f68cc] added comment for applicationContext.xml
1 file changed, 2 insertions(+), 1 deletion(-)
!
➜ git:(feature-1185-add-commenting) vi web-app/WEB-INF/sitemesh.xml
➜ git:(feature-1185-add-commenting) ✗ git add .
➜ git:(feature-1185-add-commenting) ✗ git commit -m "added comment for sitemesh.xml"
[feature-1185-add-commenting 0e74f89] added comment for sitemesh.xml
1 file changed, 3 insertions(+), 1 deletion(-)
!
➜ git:(feature-1185-add-commenting) vi .application.properties
➜ git:(feature-1185-add-commenting) ✗ git add .
➜ git:(feature-1185-add-commenting) ✗ git commit -m "increased the application version"
[feature-1185-add-commenting 7ce1f07] increased the application version
1 file changed, 1 insertion(+), 1 deletion(-)

52. 5
rebase frequently
to incorporate upstream changes
to prevent your branch from diverging significantly
➜ git:(feature-1185-add-commenting) git fetch origin development
From UberProject
* branch development -> FETCH_HEAD
➜ git:(feature-1185-add-commenting) git rebase origin/development
First, rewinding head to replay your work on top of it...
Fast-forwarded feature-1185-add-commenting to origin/development.

53. 5
rebase frequently
to incorporate upstream changes
to prevent your branch from diverging significantly
➜ git:(feature-988-add-shelf-controller) git checkout development
Switched to branch 'development'
Your branch is behind 'origin/development' by 2 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)
➜ git:(development) git pull
Updating 4559eba..d55ee12
Fast-forward
application.properties | 2 + grails-app/domain/org/example/Shelf.groovy | 7 +++++++
test/unit/org/example/ShelfTests.groovy | 17 +++++++++++++++++
web-app/WEB-INF/applicationContext.xml | 3 ++ web-app/WEB-INF/sitemesh.xml | 4 +++ 5 files changed, 30 insertions(+), 3 deletions(-)
create mode 100644 grails-app/domain/org/example/Shelf.groovy
create mode 100644 test/unit/org/example/ShelfTests.groovy
➜ git:(development) git checkout feature-1185-add-commenting
Switched to branch 'feature-988-add-shelf-controller'
➜ git:(feature-988-add-shelf-controller) git merge development
Updating 7761c9c..d55ee12
Fast-forward
application.properties | 2 + web-app/WEB-INF/applicationContext.xml | 3 ++ web-app/WEB-INF/sitemesh.xml | 4 +++ 3 files changed, 6 insertions(+), 3 deletions(-)
ing
th s
me tep
e sara s onal
th xt iti
oes h e add mit
t d wit an com
i
and erge
m

54. 6
Interactive rebase
to squash your commits
be sure that we only deal with the local commits
➜ git:(feature-1185-add-commenting) git rebase -i origin/development
git will display an editor with a list of the commits to be modified
pick 4559eba updated application version
pick d1706ae added comments for applicationContext.xml
pick d3c2734 added comments for sitemesh.xml
Now we need to tell git what to do. keep the first one as it is and change the others as “squash”
pick 4559eba updated application version
squash d1706ae added comments for applicationContext.xml
squash d3c2734 added comments for sitemesh.xml
Git squashes the commits together to one commit and opens a new editor to enter commit message
updated application version, added comments to
applicationContext.xml and siteMesh.xml files
Now the last 3 commits are squashed into one commit with a special commit message

55. 7
merge your changes
with development branch
It’s time to merge the completed work
➜ git:(feature-1185-add-commenting) git checkout development
Switched to branch 'development'
Your branch is behind 'origin/development' by 3 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)
➜ git:(development) git pull
Updating c827c84..7761c9c
Fast-forward
application.properties | 2 + grails-app/controllers/org/example/ShelfController.groovy | 6 ++++++
grails-app/domain/org/example/Shelf.groovy | 7 +++++++
test/unit/org/example/ShelfControllerTests.groovy | 17 +++++++++++++++++
test/unit/org/example/ShelfTests.groovy | 17 +++++++++++++++++
5 files changed, 48 insertions(+), 1 deletion(-)
create mode 100644 grails-app/controllers/org/example/ShelfController.groovy
create mode 100644 grails-app/domain/org/example/Shelf.groovy
create mode 100644 test/unit/org/example/ShelfControllerTests.groovy
create mode 100644 test/unit/org/example/ShelfTests.groovy
some
we m one push
erge, ed bef
damm ore
it!
➜ git:(development) git merge feature-1185-add-commenting
Updating 7761c9c..d55ee12
Fast-forward
application.properties | 2 + web-app/WEB-INF/applicationContext.xml | 3 ++ web-app/WEB-INF/sitemesh.xml | 4 +++ 3 files changed, 6 insertions(+), 3 deletions(-)

56. 8
push your changes to the upstream
➜ git:(feature-1185-add-commenting) git push origin development
Counting objects: 13, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 759 bytes | 0 bytes/s, done.
Total 7 (delta 4), reused 0 (delta 0)
To UberProject.git
7761c9c..d55ee12 development -> development

57. tıps forand git branching model
efficient usage
of git

58. 1
Learn git Command Line by heart, stop using GUI
GUI is
to do extrem
stuff ely m
like m essy w
erging hen y
and b ou need
ranch
ing.

59. 2
Only few people should be authorised
for merging development branch to master branch
for do
durin ing a th
g mer e last
ge by revie
techn w
ical le
ads

60. 3
check-in others code at least once a day
It’s b
when etter to
ever
c
possibheck-in
le

61. 4
ensure that all tests are passing
before pushing to upstream

62. 5
never rebase shared commits
rebas
no one e only th
have e bran
check ch w
ed in here
yet

63. 6
do not push half-baked, untested, incomplete,
not-compiling, to-be-fixed, not-ready-to-deploy code to git
push
code i to remot
s read e wh
y to d enever
eploy the

64. 7
Have meaningful distinguishing comments for commits
includ
e bug
or sto
ry ids
too

65. 8
Never use -­‐m <message> flag to git commit and
Follow Commit message best practices
characters or less. That is summary.
• First line is 50line
• Then a blanktext should be wrapped at 72 characters.
• Remaining description
That is detailed

66. 9
Squash commits of your completed story into one
before pushing to upstream
we ar
inter e not int
nals o eres
f stor ted in
ies

67. 10
Squash commits of bug fix into one and exactly one commit
that completely represents that bug fix
Half o
f bug
fix is
usele
ss

68. 11
Never bundle logically different components
in the same commit
think
about
rolling
back
too

69. 12
Commit often, perfect later, publish once

70. 13
Use .gitıgnore in order not to send irrelevant files
never
packa push irr
IDE or ges, com elevant
OS re piled binar
lated files, ies,
files temp
file
s,

71. 14
Always review code before Committing it
check
stagi what y
ng are ou se
nt to
a

72. 15
Clean up unused and out-of-date suPpoRTing branches
and n
remotever del
e bra ete un
nches merg
ed

73. 16
do not reset without stashing or committing & tagging
no one
want
s to l
ose co
de, uh
?

75. references
and good to reads
“A successful git branching model”
http://nvie.com/posts/a-successful-git-branching-model
“A git workflow for agile teams”
http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
“merge or rebase”
http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/
“git pull --rebase by default”
http://d.strelau.net/post/47338904/git-pull-rebase-by-default
“a rebase workflow for git”
http://www.randyfay.com/node/91
“A DEEP DIVE INTO THE MYSTERIES OF REVISION CONTROL”
http://blog.experimentalworks.net/2009/03/merge-vs-rebase-a-deep-dive-into-the-mysteries-of-revision-control

76. references
and good to reads
“GIT BEST Practices”
http://sethrobertson.github.io/GitBestPractices
“GIT BEST Practices: Workflow Guidelines”
http://www.lullabot.com/blog/article/git-best-practices-workflow-guidelines
“5 useful tips for a better commit message”
http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
“Proper git commit messages and elegant git history”
http://ablogaboutcode.com/2011/03/23/proper-git-commit-messages-and-an-elegant-git-history
“branch per feature”
http://dymitruk.com/blog/2012/02/05/branch-per-feature/
ımages
http://www.flickr.com/photos/ableman/1209643278
http://www.flickr.com/photos/ibnhusin/3883416540
http://www.flickr.com/photos/mylor/314975954/
http://www.ccjdigital.com/files/2010/08/highways.jpg
http://www.flickr.com/photos/librariesrock/4275765000
http://15pictures.com/wp-content/gallery/15-pictures-adriana-lima/adriana-lima-1.jpg

77. @lemiorhan
@lemiorhan
@lemiorhan
agilistanbul.com
Lemİ orhan ergİn
lemiorhan@agilistanbul.com
lemiorhanergin.com
Principal Software Engineer @ Sony
Founder & Author @ agilistanbul.com