Chapter 3 of the lecture Game Programming taught at HAW Hamburg. Introduction to the Git branching model developed by Vincent Driessen.

1. Game Programming
Git Flow
Nick Prühs

2. Objectives
• To understand how to develop separate features without interfering
with other team members
• To get an idea of how to prepare a new release using a dedicated
branch
• To learn how to integrate hotfixes in live environments
2 / 17

3. GitFlow
• Originally developed by Vincent Driessen
• Assigns very specific roles to different branches, and defines how
and when they should interact
• Allows merging and branching to be part of your daily workflow
3 / 17

4. Main Branches
• master
 origin/master HEAD is always ready for production
• develop
 origin/develop HEAD always contains the latest delivered
development changes
 Nightly builds are created from this branch
 Whenever considered stable, merged back into master and
tagged
4 / 17

5. Main Branches
5 / 17

6. Supporting branches
• Feature branches
 Allow parallel development
 Make tracking features easier
• Release branches
 Help preparing for releases
• Hotfix branches
 Enable you to quickly fix live problems
6 / 17

7. Feature Branches
• Branch from and merge back into develop
• Used for developing new features
• Exists while the feature is in development
• Will eventually be
 Merged back, to include the new feature in the next release, or
 Discarded, if the feature should not be included
• Never directly interact with the master branch
7 / 17

8. Feature Branches
8 / 17

9. Hint
Merging with the “no fast-
forward” option causes the
merge to always create a new
commit. This makes tracking of
your branches a lot easier!
9 / 17

10. Release Branches
• Branch from develop, and merge back into develop and master
• Created when all desired features for the next release have been
merged back into develop
• Supports preparation of a new production release
 Setting up meta-data such as version numbers or database
connections
 Generating API documentation
• Features for the next release can already merge back into develop
10 / 17

11. Release Branches
11 / 17

12. Hint
Whenever changes are
merged back into master,
this is a new production
release by definition!
12 / 17

13. Hotfix Branches
• Branch from master, and merge back into develop and master
• Created when a critical bug in a production release has to be
resolved immediately
• Other team members can continue working on new features or the
next release
13 / 17

14. Hotfix Branches
14 / 17

15. Hint
Unlike the two main
branches, all supporting
branches will be merged
and removed eventually!
15 / 17

16. References
• Vincent Driessen. A successful Git branchin model.
http://nvie.com/posts/a-successful-git-branching-model/, January 5,
2010.
• Atlassian. Comparing Workflows.
https://www.atlassian.com/git/tutorials/comparing-workflows, April
2017.
16 / 17

17. Thank you!
http://www.npruehs.de
https://github.com/npruehs
@npruehs
nick.pruehs@daedalic.com

18. 5 Minute Review Session
• Name the two main branches and their roles!
• When and where are feature branches created?
• When and where are feature branches merged back?
• When and where are release branches created?
• When and where are release branches merged back?
• When and where are hotfix branches created?
• When and where are hotfix branches merged back?