Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Game Programming 03 - Git Flow

1,622 views

Published on

Chapter 3 of the lecture Game Programming taught at HAW Hamburg.

Introduction to the Git branching model developed by Vincent Driessen.

Published in: Technology
  • Be the first to comment

Game Programming 03 - Git Flow

  1. 1. Game Programming Git Flow Nick Prühs
  2. 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. 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. 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. 5. Main Branches 5 / 17
  6. 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. 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. 8. Feature Branches 8 / 17
  9. 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. 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. 11. Release Branches 11 / 17
  12. 12. Hint Whenever changes are merged back into master, this is a new production release by definition! 12 / 17
  13. 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. 14. Hotfix Branches 14 / 17
  15. 15. Hint Unlike the two main branches, all supporting branches will be merged and removed eventually! 15 / 17
  16. 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. 17. Thank you! http://www.npruehs.de https://github.com/npruehs @npruehs nick.pruehs@daedalic.com
  18. 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?

×