Git - Workflow models for contributing code
-
Upload
alex-lefur -
Category
Technology
-
view
113 -
download
5
Transcript of Git - Workflow models for contributing code
AS CATALYSTS OF SOFTWARE DEVELOPMENT
Lemİ Orhan ERGİNlemiorhanergin.com @lemiorhan@lemiorhan
GIT & GIT workflow MODELs
Lemİ Orhan ErgİnPrincipal Software Engineer at Sony
has worked in Tüsside, BYM, GittiGidiyor/eBay and Sony as lead developer, technical leader, technical coordinator and scrum master
using Git, but not an expert
organisational level SVN to GIT migration projects experienced so far
doing code reviews as a daily habit
experienced in agile transformation and building agile culture in teams & organisations
2001
2013
20092
2005
agile
CSM, PSM1
0.5M total number of views of his presentations
I lovegit
I lovegitbecause…
I used SVN for a while Local branching is cheap
Everything is local Distributed
Small and efficient Any workflow
Lightening Fast Huge community
GitHub… Thanks God!More than 3M people˝
More than 5M repositories˝Raised $100 million on July'12
Ruby on Rails with full history and branches weight 13Mb.
It weights 115Mb in SVN
Each object is compressed by zlib and transferred over wire
one by one
git data model is
It is a directed acyclic graph Objects (blob, tree, commit, tag) are immutable References (branch, remote) always change
hot
It is not a magical version of SVN. Try to understand what it's actually doing.
Stop comparing SVN with GIT
“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.
It's a stupid content tracker. It tracks files and folders.
”LINUS TOVALDS
gitchanged the way we think of
merging branching
workflows
git is a tool for designing vcs workflows
git workflow
model
main
bran
ches
supp
ortin
g bra
nche
sFe
atur
e dev
elop
ment
rele
ase d
evel
opme
ntho
t fix
es in
prod
uctio
n
which are created at the very beginningmain branches are permanent branches
and never deleted!main
bran
ches
test & QA STAGING & UAT ProductiondevelopmentMASTER
It reflects the latest delivered development
changes for the next release
Automatic nightly builds
OPTıONALma
in br
anch
es
test & QA STAGING & UAT ProductiondevelopmentMASTER
It reflects the code which is deployed to test/qa
environment for testing
Automatic nightly builds
Automatically deployed to test/qa servers every night
OPTıONALma
in br
anch
es
test & QA STAGING & UAT ProductiondevelopmentMASTER
It reflects the code which is deployed to staging/uat environment for testing
Automatic nightly builds
Automatically deployed to test/qa servers every night
Automatically deployed to staging servers every night
OPTıONALma
in br
anch
es
test & QA STAGING & UAT ProductiondevelopmentMASTER
It reflects the code which is deployed to production
Automatic nightly builds
Automatically deployed to test/qa servers every night
Automatically deployed to staging servers every night
Automatically deployed to
production servers on demand
OPTıONALma
in br
anch
es
and will be removed eventuallyThese have limited life time
supp
ortin
g bra
nche
s feature branchesHOTFIX branches
release branches
and strict rules for originating and target branchesThese have specific purpose
supp
ortin
g bra
nche
s feature branchesHOTFIX branches
release branches
All feature branches should be created from
The development branch
the next release branch
Feat
ure d
evel
opme
nt
take a new feature branch
regardless of the feature size
you can fix very minor
common issues directly
in development branch, like fixing typosFe
atur
e dev
elop
ment
Feat
ure d
evel
opme
ntFeature 1 Feature 2 Feature 3 development
Next Release
2
Feature 2 is completed and ready for
the next release
Feat
ure d
evel
opme
ntFeature 1 Feature 2 Feature 3 development
1
Next Release
2
Feature 1 is being developed
Feat
ure d
evel
opme
ntFeature 1 Feature 2 Feature 3 development
1
D
Next Release
2
Feature 2 is completed and merged back to master
Feat
ure d
evel
opme
ntFeature 1 Feature 2 Feature 3 development
1
D
1
Next Release
2
Feature 1 gets the commits in Feature 2
Feat
ure d
evel
opme
ntFeature 1 Feature 2 Feature 3 development
1
D
1
1
D
Next Release
2
Pulls all the commits from other features and
resolve conflicts
Feat
ure d
evel
opme
ntFeature 1 Feature 2 Feature 3 development
1
D
3
1
1
D
Next Release
2
Feature 3 is created from development. It has commits
of Feature 2
Feat
ure d
evel
opme
ntFeature 1 Feature 2 Feature 3 development
1
D
3
1
1
D
Next Release
D
2
Feature 1 is completed and merged back to master
Feat
ure d
evel
opme
ntFeature 1 Feature 2 Feature 3 development
1
D
3
1
1
D
3
Next Release
D
2
Feature 3 gets the commits of Feature 1
Feat
ure d
evel
opme
ntFeature 1 Feature 2 Feature 3 development
1
D
3
1
1
D
3
Next Release
D
D
3
2
Feature 3 pull updates frequently
Feat
ure d
evel
opme
ntFeature 1 Feature 2 Feature 3 development
1
D
3
1
1
D
3
Next Release
D
D
3D
2
Typo is fixed directly in development branch
Feat
ure d
evel
opme
ntFeature 1 Feature 2 Feature 3 development
1
D
3
1
1
D
3
Next Release
D
D
3
3
D
2
Feature 3 pulls commit about fixing the typo
Feat
ure d
evel
opme
ntFeature 1 Feature 2 Feature 3 development
1
D
3
1
1
D
3
Next Release
D
D
3
3
D
D
2
Feature 3 is completed and merged back to master.
It has commits of all 3 features now.
Release branch is created when
all features are ready for the next release
sometimes we call it as
feature freeze
rele
ase d
evel
opme
nt
Release branch is deleted when
the release completes
we will tag the released
code, no need to keep the
branch..
rele
ase d
evel
opme
nt
rele
ase d
evel
opme
ntdevelopment release Production
MASTER
D
D
F
F
Completed features are merged with development
Next
Relea
se
rele
ase d
evel
opme
ntdevelopment release Production
MASTER
D
D
D
F
F
All features are ready for the next release
Next
Relea
se
rele
ase d
evel
opme
ntdevelopment release Production
MASTER
D
R
D
D
F
F
Start a release branch when features are freezed
Next
Relea
se
rele
ase d
evel
opme
ntdevelopment release Production
MASTER
D
R
R
R
D
D
D
D
F
F
Only fixes are allowed
Bug fixes are continuously merged back
to development brach
Next
Relea
se
rele
ase d
evel
opme
ntdevelopment release Production
MASTER
D
R
R
R
R
D
D
D
D
F
F
Release is ready now
Next
Relea
se
rele
ase d
evel
opme
ntdevelopment release Production
MASTER
D
R
R
D
R
R
D
D
D
D
F
F
Latest fixes are merged back to development branch
Next
Relea
se
rele
ase d
evel
opme
ntdevelopment release Production
MASTER
D
R
M
R
D
R
R
D
D
D
D
F
F
Merge release branch with master branch
and get a new tag
Next
Relea
se
Fix branches are required because every fix should be
well tested and verified
it means, you may need
to rollback what you’ve
done in the fix
hot f
ixes
in pr
oduc
tion
hot f
ixes
in pr
oduc
tion development Hot-FIX Production
MASTER
Next
Relea
se
M
Hot fix is required! A new branch is created from
production branch
hot f
ixes
in pr
oduc
tion development Hot-FIX Production
MASTER
Next
Relea
se
M
H
Fix is developed, tested and verified. Ready to go.
hot f
ixes
in pr
oduc
tion development Hot-FIX Production
MASTER
Next
Relea
se
M
H
D
Hot fixes are merged back to development branch
hot f
ixes
in pr
oduc
tion development Hot-FIX Production
MASTER
Next
Relea
se
M
H
D
M
Hot fix is merged with production branch and
production branch is tagged
This graphic is taken from Vincent Driessen’s article called
“a successful git branching model”
ALL F
LOWS
IN T
HE M
ODEL
feature development
➜ 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
creatE permanent branchesIf these does not exist1
it creates development
branch from master and
pushes to remote
Pull to updatelocal development branch
be sure you run tests directly afterwards2 ➜ 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
➜ git:(development) git checkout -b feature-1185-add-commenting Switched to a new branch 'feature-1185-add-commenting'
create a feature branch from development
with a name having story id and descriptive title3the title should give
hints about what’s in it
➜ git:(feature-1185-add-commenting)
work in your feature branchcommit early and often4
➜ 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(-)
Be careful! it does not mean “push early and often”
rebase frequentlyto incorporate upstream changes
to prevent your branch from diverging significantly5➜ 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.
rebase frequentlyto incorporate upstream changes
to prevent your branch from diverging significantly5 ➜ 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(-)
it does the same thing
with extra steps
and an additional
merge commit
Interactive rebaseto squash your commits
be sure that we only deal with the local commits6 ➜ git:(feature-1185-add-commenting) git rebase -i origin/development
pick 4559eba updated application version
pick d1706ae added comments for applicationContext.xml
pick d3c2734 added comments for sitemesh.xml
git will display an editor with a list of the commits to be modified
pick 4559eba updated application version
squash d1706ae added comments for applicationContext.xml
squash 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”
updated application version, added comments to applicationContext.xml and siteMesh.xml files
Git squashes the commits together to one commit and opens a new editor to enter commit message
Now the last 3 commits are squashed into one commit with a special commit message
merge your changes with development branch
It’s time to merge the completed work7 ➜ 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
➜ 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(-)
someone pushed before
we merge, dammit!
push your changes to the upstream8➜ 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
tıps for efficient usageof git and git branching model
Learn git Command Line by heart, stop using GUI
GUI is extremely messy when you need
to do stuff like merging and branching.
1
Only few people should be authorised for merging development branch to master branch
for doing a the last review
during merge by technical leads
2
check-in others code at least once a day
It’s better to check-in
whenever possible
3
ensure that all tests are passing before pushing to upstream
4
never rebase shared commits
5rebase only the branch where
no one have checked in yet
do not push half-baked, untested, incomplete, not-compiling, to-be-fixed, not-ready-to-deploy code to git
push to remote whenever the
code is ready to deploy
6
Have meaningful distinguishing comments for commits
include bug or story ids too
7
Never use flag to git commit and Follow Commit message best practices
8• First line is 50 characters or less. That is summary. • Then a blank line • Remaining text should be wrapped at 72 characters.
That is detailed description
-‐m <message>
Squash commits of your completed story into one before pushing to upstream
we are not interested in
internals of stories
9
Squash commits of bug fix into one and exactly one commit that completely represents that bug fix
Half of bugfix is useless
10
Never bundle logically different components in the same commit
think about rolling back too
11
Commit often, perfect later, publish once
12
Use .gitıgnore in order not to send irrelevant files
13never push irrelevant binaries,
packages, compiled files, temp files,
IDE or OS related files
Always review code before Committing it
14check what you sent to
staging area
Clean up unused and out-of-date suPpoRTing branches
and never delete unmerged
remote branches
15
do not reset without stashing or committing & tagging
16no one wants to lose code, uh?
references
“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
http://nvie.com/posts/a-successful-git-branching-model
and good to reads
references
“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/
and good to reads
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ımages
Lemİ orhan ergİn
@lemiorhan
@lemiorhan
agilistanbul.com
@lemiorhan
Principal Software Engineer @ SonyFounder & Author @ agilistanbul.com