GETTING STARTED WITH GIT FLOWBASIC WORKFLOW EXAMPLE

COMPILED FOR KOSMOS AND KAOS

Time

release branches masterdevelop hotfixesfeature

branches

Feature for future

release

Tag

1.0

Major feature for

next release

From this point on, “next release” means the

release after 1.0

Severe bug fixed for

production:hotfix 0.2

Bugfixes from rel. branch

may be continuously merged back into develop

Tag

0.1

Tag

0.2

Incorporate bugfix in develop

Only bugfixes!

Start of release branch for

1.0

Author: Vincent DriessenOriginal blog post: http://nvie.com/archives/323License: Creative Commons

git

flow

bra

nch

ing

mod

el

DEVELOPING WITH GIT FLOW

• Benefits

• Parallel development

• code that is not finished is not hindering development of other features

• Collaboration

• developing features increases clarity

• features have their own sandbox (feature branch)

• Release branches

• Allows better control of what get shipped to test and production

• Easier to integrate with CI tools (Contious Integration)

• Hotfixes

• Special branch to do emergency fixes to “tagged” releases.

• Disadvantages

• You might have to learn something new and memorize :)

Developing Features

Time

masterdevelop

Tag

0.1

Author: Vincent DriessenOriginal blog post: http://nvie.com/archives/323License: Creative Commons

git

flow

bra

nch

ing

mod

el

When startingwith git flow

you will have two branches

Master is theProduction Branch

Develop is theDevelopment Branch

Git flow is initializedwith “git flow init”

Programmer starts a feature

“git flow feature start myFeature”

Time

masterdevelopfeature branches

Major feature for

next release

Tag

0.1

Author: Vincent DriessenOriginal blog post: http://nvie.com/archives/323License: Creative Commons

git

flow

bra

nch

ing

mod

el

Programmergets assigned

a task from theproject manager

Publish feature to peers“git flow feature myFeature”

Time

masterdevelopfeature branches

Feature for future

release

Major feature for

next release

Tag

0.1

Author: Vincent DriessenOriginal blog post: http://nvie.com/archives/323License: Creative Commons

git

flow

bra

nch

ing

mod

el

Programmer commits to the myFeature branch and when

finished he finishes the myFeature

“git flow feature finish myFeature”

You can have multiple feature branches

Time

masterdevelopfeature branches

Feature for future

release

Major feature for

next release

From this point on, “next release” means the

release after 1.0

Tag

0.1

Author: Vincent DriessenOriginal blog post: http://nvie.com/archives/323License: Creative Commons

git

flow

bra

nch

ing

mod

el

DEVELOPING FEATURES RECAP

• git flow feature start myFeature

• git flow feature publish myFeature (for peer programmers)

• commit work as usual

• git flow feature finish myFeature

• myFeature is now a part of the development branch

Release Branch

RELEASING CODE

• Now we want to release our code

• we start off by creating a release branch

• then we review our release branch and apply bug fixes until we are satisfied.

• and when this is done we finish the release

Time

release branches masterdevelopfeature

branches

Feature for future

release

Tag

1.0

Major feature for

next release

From this point on, “next release” means the

release after 1.0

Bugfixes from rel. branch

may be continuously merged back into develop

Tag

0.1

Incorporate bugfix in develop

Only bugfixes!

Start of release branch for

1.0

Author: Vincent DriessenOriginal blog post: http://nvie.com/archives/323License: Creative Commons

git

flow

bra

nch

ing

mod

el Create the release branch

“git flow release start 0.1”

Publish the release branch“git flow release publish 0.1”

Do commit as ususal

Finish the release branch“git flow release finish 0.1”

RELEASING RECAP

• Release 0.1

• git flow release start 0.1

• git flow release publish 0.1

• git commit -a -m “Some fixes"

• git flow release finish 0.1

• Release 0.1 is now a “tag” and is merged back into master and development branches

Hotfixes

HOTFIXES

• Sometimes we have to do hot fixes

• Minor tweaks and changes (typos and such)

• Critical bugs that needs to be fixed

• etc …

• For stabilizing or fixing current release in production. Fixes are merged back into development branch.

Time

release branches masterdevelop hotfixesfeature

branches

Feature for future

release

Tag

1.0

Major feature for

next release

From this point on, “next release” means the

release after 1.0

Severe bug fixed for

production:hotfix 0.2

Bugfixes from rel. branch

may be continuously merged back into develop

Tag

0.1

Tag

0.2

Incorporate bugfix in develop

Only bugfixes!

Start of release branch for

1.0

Author: Vincent DriessenOriginal blog post: http://nvie.com/archives/323License: Creative Commons

git

flow

bra

nch

ing

mod

el

Programmer starts a hotfix by issuing

“git flow hotfix start myHotfix”

Programmer finishes a hotfix by issuing

“git flow hotfix finish myHotfix”

PIMPING UP YOUR .GITCONFIG

• Can increase productivity

• See mine for example https://gist.github.com/samueljon/1042930

• When using git flow it can be useful to do a

• “git push -v —tags origin develop:develop master:master” see alias in gist named kosmos.

• git lola (alias for git log —graph —decorate —pretty=online —abbrev-commit —all) see alias in gist named lola.

WRAPPING UP

• Git flow is extremely useful

• Adds complexity but benefits are greater once you get used to the workflow

• This handy cheat sheet can help you while you get the hang of it : http://danielkummer.github.io/git-flow-cheatsheet/

Thank you

Samúel Jón Gunnarsson@samueljon