git flow

An (opinionated) git Branching Model allowing better Release Management

Transcript

1. git flow An (opinionated) git Branching Model allowing better Release Management By Tanmay Patel (tanmaypatel.com)
2. Typical Product  More than one person working on code, maybe from more than one location  In more than one Technology  With more than one “module” required to power a feature  With more than one feature being developed at a time  With more than one version to be managed at a time, on more than one environment
3. Typical Working Day  We need to work on the next feature, which needs more than one module to be worked upon  We need to show progress to the client, and chasing managers, on those features by demoing them  Client needs a feature to be able to use by users soon as they see it working
4. Typical Environments  Somewhere I can play alone – Local Development Machines  Somewhere I can play with others – Development Environment (Pre-Releases)  Somewhere others can see us playing – Staging Environment (Release Candidates)  Somewhere where the world is watching us – Production Environment (LIVE!)
5. Typical Collaboration  And all more than one things requires Collaboration  Collaboration for same understanding of,  Product as a whole  The way we work as a pack and to reduce conflicts or impact of our work on others  Current Feature being worked upon  Dependencies on each other for the feature  Impact of feature on past and future of the product
6. git –for Code Collaboration  Version Control System like SVN & CVS (if you are as or more old then me!)  Distributed – for Collaboration  Cheap Branches – for Release Management  Powering companies (Github and Atlassian) and package managers (from my JS background, Bower, NPM, JSPM)
7. So how git can help with all these typical products, working days, environments, and collaborations, etc?
8. git flow  A Branching model  Made with collaborations and rapid releases in mind  Provides clear connection between stuff deployed and stuff developed for different environments  Reduces ways we can screw up something working on server or dependencies  Integration with other git tools like Source Tree
9. git flow master hotfix release develop feature/x feature/y v0.1.2 v0.1.1 v0.2.0
10. Branches for Environments master --- production --- live release --- staging --- candidate develop --- development --- pre-release
11. The main branches  Two main branches with infinite timeline  master  develop  origin/master to be the main branch where the HEAD always reflects a production-ready state  origin/develop to be the main branch where the HEAD always reflects a state with the latest development changes for the next release
12. Supporting Branches  To allow parallel development  feature branches  release branches  hotfix branches  Unlike the main branches, these branches always have a limited life time, and will be removed eventually
13. feature Branches  May branch off from, develop  Must merge back into, develop  Branch naming convention, feature/{feature-name}
14. More on feature Branches  Used to develop new features on next or distant releases, which may be unknown yet  It will be merged back to develop or can be discarded in case of experiments!  It might stay in developer machines and not on origins
15. release Branches  May branch off from, develop  Must merge back into, master and develop  Branch naming convention, release/{release-number}
16. More on release Branches  Release branches support preparation of a new production release  They allow for minor bug fixes and preparing meta-data for a release  It is exactly at the start of a release branch that the upcoming release gets assigned a version number  Once merged with master, they will also be tagged from master
17. hotfix Branches  May branch off from, master  Must merge back into, master and develop  Branch naming convention, hotfix/{version-number}
18. More on hotfix Branches  hotfix branches resolution support of critical bug fixes  They allow work of team members (on the develop branch) can continue, while a person is doing a quick production fix  When finished, it needs to be merged back into master, but also needs to be merged back into develop, to safeguard that the fix is included in the next release as well
19. More at, http://nvie.com/posts/a-successful-git-branching-model/
20. Keep Flowing!