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

Git - Workflow models for contributing code

Embed Size (px)

Citation preview

Page 1: Git - Workflow models for contributing code

AS CATALYSTS OF SOFTWARE DEVELOPMENT

Lemİ Orhan ERGİNlemiorhanergin.com @lemiorhan@lemiorhan

GIT & GIT workflow MODELs

Page 2: Git - Workflow models for contributing code

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

Page 3: Git - Workflow models for contributing code

I lovegit

Page 4: Git - Workflow models for contributing code

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

Page 5: Git - Workflow models for contributing code

git data model is

It is a directed acyclic graph Objects (blob, tree, commit, tag) are immutable References (branch, remote) always change

hot

Page 6: Git - Workflow models for contributing code

It is not a magical version of SVN. Try to understand what it's actually doing.

Stop comparing SVN with GIT

Page 7: Git - Workflow models for contributing code

“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

Page 8: Git - Workflow models for contributing code

gitchanged the way we think of

merging branching

workflows

Page 9: Git - Workflow models for contributing code

git is a tool for designing vcs workflows

Page 10: Git - Workflow models for contributing code

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

Page 11: Git - Workflow models for contributing code

which are created at the very beginningmain branches are permanent branches

and never deleted!main

bran

ches

Page 12: Git - Workflow models for contributing code

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

Page 13: Git - Workflow models for contributing code

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

Page 14: Git - Workflow models for contributing code

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

Page 15: Git - Workflow models for contributing code

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

Page 16: Git - Workflow models for contributing code

and will be removed eventuallyThese have limited life time

supp

ortin

g bra

nche

s feature branchesHOTFIX branches

release branches

Page 17: Git - Workflow models for contributing code

and strict rules for originating and target branchesThese have specific purpose

supp

ortin

g bra

nche

s feature branchesHOTFIX branches

release branches

Page 18: Git - Workflow models for contributing code

All feature branches should be created from

The development branch

the next release branch

Feat

ure d

evel

opme

nt

Page 19: Git - Workflow models for contributing code

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

Page 20: Git - Workflow models for contributing code

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

Page 21: Git - Workflow models for contributing code

Feat

ure d

evel

opme

ntFeature 1 Feature 2 Feature 3 development

1

Next Release

2

Feature 1 is being developed

Page 22: Git - Workflow models for contributing code

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

Page 23: Git - Workflow models for contributing code

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

Page 24: Git - Workflow models for contributing code

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

Page 25: Git - Workflow models for contributing code

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

Page 26: Git - Workflow models for contributing code

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

Page 27: Git - Workflow models for contributing code

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

Page 28: Git - Workflow models for contributing code

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

Page 29: Git - Workflow models for contributing code

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

Page 30: Git - Workflow models for contributing code

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

Page 31: Git - Workflow models for contributing code

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.

Page 32: Git - Workflow models for contributing code

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

Page 33: Git - Workflow models for contributing code

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

Page 34: Git - Workflow models for contributing code

rele

ase d

evel

opme

ntdevelopment release Production

MASTER

D

D

F

F

Completed features are merged with development

Next

Relea

se

Page 35: Git - Workflow models for contributing code

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

Page 36: Git - Workflow models for contributing code

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

Page 37: Git - Workflow models for contributing code

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

Page 38: Git - Workflow models for contributing code

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

Page 39: Git - Workflow models for contributing code

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

Page 40: Git - Workflow models for contributing code

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

Page 41: Git - Workflow models for contributing code

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

Page 42: Git - Workflow models for contributing code

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

Page 43: Git - Workflow models for contributing code

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.

Page 44: Git - Workflow models for contributing code

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

Page 45: Git - Workflow models for contributing code

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

Page 46: Git - Workflow models for contributing code

This graphic is taken from Vincent Driessen’s article called

“a successful git branching model”

ALL F

LOWS

IN T

HE M

ODEL

Page 47: Git - Workflow models for contributing code

feature development

Page 48: Git - Workflow models for contributing code

➜ 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

Page 49: Git - Workflow models for contributing code

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 

Page 50: Git - Workflow models for contributing code

➜ 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)  

Page 51: Git - Workflow models for contributing code

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”

Page 52: Git - Workflow models for contributing code

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. 

Page 53: Git - Workflow models for contributing code

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

Page 54: Git - Workflow models for contributing code

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

Page 55: Git - Workflow models for contributing code

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!

Page 56: Git - Workflow models for contributing code

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 

Page 57: Git - Workflow models for contributing code

tıps for efficient usageof git and git branching model

Page 58: Git - Workflow models for contributing code

Learn git Command Line by heart, stop using GUI

GUI is extremely messy when you need

to do stuff like merging and branching.

1

Page 59: Git - Workflow models for contributing code

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

Page 60: Git - Workflow models for contributing code

check-in others code at least once a day

It’s better to check-in

whenever possible

3

Page 61: Git - Workflow models for contributing code

ensure that all tests are passing before pushing to upstream

4

Page 62: Git - Workflow models for contributing code

never rebase shared commits

5rebase only the branch where

no one have checked in yet

Page 63: Git - Workflow models for contributing code

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

Page 64: Git - Workflow models for contributing code

Have meaningful distinguishing comments for commits

include bug or story ids too

7

Page 65: Git - Workflow models for contributing code

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>

Page 66: Git - Workflow models for contributing code

Squash commits of your completed story into one before pushing to upstream

we are not interested in

internals of stories

9

Page 67: Git - Workflow models for contributing code

Squash commits of bug fix into one and exactly one commit that completely represents that bug fix

Half of bugfix is useless

10

Page 68: Git - Workflow models for contributing code

Never bundle logically different components in the same commit

think about rolling back too

11

Page 69: Git - Workflow models for contributing code

Commit often, perfect later, publish once

12

Page 70: Git - Workflow models for contributing code

Use .gitıgnore in order not to send irrelevant files

13never push irrelevant binaries,

packages, compiled files, temp files,

IDE or OS related files

Page 71: Git - Workflow models for contributing code

Always review code before Committing it

14check what you sent to

staging area

Page 72: Git - Workflow models for contributing code

Clean up unused and out-of-date suPpoRTing branches

and never delete unmerged

remote branches

15

Page 73: Git - Workflow models for contributing code

do not reset without stashing or committing & tagging

16no one wants to lose code, uh?

Page 74: Git - Workflow models for contributing code
Page 75: Git - Workflow models for contributing code

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

Page 76: Git - Workflow models for contributing code

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

Page 77: Git - Workflow models for contributing code

Lemİ orhan ergİn

@lemiorhan

@lemiorhan

agilistanbul.com

@lemiorhan

Principal Software Engineer @ SonyFounder & Author @ agilistanbul.com

[email protected]