Devoxx UK 2024 - Going serverless with Quarkus, GraalVM native images and AWS...
Git flow workflow example
1. GETTING STARTED WITH GIT FLOW
BASIC WORKFLOW EXAMPLE
COMPILED FOR KOSMOS AND KAOS
2. Time
release
feature develop branches hotfixes master
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
Start of release
branch for
1.0
Only bugfixes!
Author: Vincent Driessen
Original blog post: http://nvie.com/archives/323
License: Creative Commons
git flow branching model
3. 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 :)
5. Time
develop master
Tag
0.1
Author: Vincent Driessen
Original blog post: http://nvie.com/archives/323
License: Creative Commons
git flow branching model
When starting
with git flow
you will have
two branches
Master is the
Production Branch
Develop is the
Development Branch
Git flow is initialized
with “git flow init”
6. Programmer
starts a feature
“git flow feature start myFeature”
Time
feature develop master
branches
Major
feature for
next release
Tag
0.1
Author: Vincent Driessen
Original blog post: http://nvie.com/archives/323
License: Creative Commons
git flow branching model
Programmer
gets assigned
a task from the
project manager
Publish feature to peers
“git flow feature myFeature”
7. Time
feature develop master
branches
Feature for
future
release
Major
feature for
next release
Tag
0.1
Author: Vincent Driessen
Original blog post: http://nvie.com/archives/323
License: Creative Commons
git flow branching model
Programmer commits to the
myFeature branch and when
finished he finishes the myFeature
“git flow feature finish myFeature”
You can have multiple feature
branches
8. Time
feature develop master
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 Driessen
Original blog post: http://nvie.com/archives/323
License: Creative Commons
git flow branching model
9. 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
11. 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
12. Time
release
feature develop branches master
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
Start of release
branch for
1.0
Only bugfixes!
Author: Vincent Driessen
Original blog post: http://nvie.com/archives/323
License: Creative Commons
git flow branching model
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”
13. 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
15. 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.
16. Time
release
feature develop branches hotfixes master
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
Start of release
branch for
1.0
Only bugfixes!
Author: Vincent Driessen
Original blog post: http://nvie.com/archives/323
License: Creative Commons
git flow branching model
Programmer starts a
hotfix by issuing
“git flow hotfix start myHotfix”
Programmer finishes a
hotfix by issuing
“git flow hotfix finish myHotfix”
17. 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.
18. 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/