git branching strategies
TRANSCRIPT
GIT Branching Strategies 2
GIT Branching Strategies
https://nl.linkedin.com/in/tizianatroukens@tizianatroukens
Tiziana TroukensWeb Application Consultant
20/09/2016
GIT Branching Strategies 3
GIT: Concepts
20/09/2016
GIT Branching Strategies 4
GIT: Concepts
REF: pointer to an object
TAG: special REF used to mark a commit in history
20/09/2016
GIT Branching Strategies 5
GIT: Concepts
BRANCH: REF to a commit = HEAD
20/09/2016
GIT Branching Strategies 6
GIT: Branches
20/09/2016
GIT Branching Strategies 7
GIT: Branches
20/09/2016
GIT Branching Strategies 8
GIT: Merges
20/09/2016
GIT Branching Strategies 9
GIT: Concepts
MERGE: keeps the context of the feature’s commits
FAST-FORWARD MERGE: will shift the HEAD tag
20/09/2016
GIT Branching Strategies 10
Pull Requests
• Commonly 2 reviewers• Share pull requests over the whole team
• To avoid overloading a reviewer/developer• To spread knowledge of the codebase• To share your ideas
• Provide a good, detailed description/ pull request name• Preferably provide a link to a build running in an environment -> TESTING
20/09/2016
GIT Branching Strategies 11
A Succesful Git Branching Model
20/09/2016
GIT Branching Strategies 12
A Succesful Git Branching Model
20/09/2016
GIT Branching Strategies 13
A Succesful Git Branching Model
20/09/2016
GIT Branching Strategies 14
A Succesful Git Branching Model: Naming conventions
• Feature branches: “feature-*” (essentially: anything but “release-*”, “hotfix-*”, “master”, “develop”)• Release branches: “release-*”• Hotfix branches: “hotfix-*”
• “/” are possible, so make team-specific conventions:• Username/workitem: “ttrouken/MT-7654”• Username/type: “ttrouken/bugfix”• Username/type/workitem: “ttrouken/feature/MT-7654”, “ttrouken/bugfix/ALM-85463”• Type/description: “hotfix/pageXdoesntload”• ...
20/09/2016
GIT Branching Strategies 15
GitHub Flow
• Simple: every feature, every bugfix, every hotfix -> create a new branch• As soon as the feature, bugfix, hotfix is delivered -> merge back to master (pull request)• Before a merge to master happens:
• Merge master back (rebase or merge, up to you)• Test thoroughly, make sure code is deployable!• Finally: create pull request to merge
• As soon as merge happened, redeploy master• Preferably in a continuous way
20/09/2016
GIT Branching Strategies 16
GitHub Flow, but slightly different
• Simple: every feature, every bugfix, every hotfix -> create a new branch• As soon as the feature, bugfix, hotfix is delivered -> merge to QA (pull request)• As soon as the QA branch is approved -> merge all approved features/bugfixes/hotfixes back to master (pull request)• Before a merge to master happens:
• Merge master back (rebase or merge, up to you)• Test thoroughly, make sure code is deployable!• Finally: create pull request to merge
• As soon as merge happened, redeploy master• Preferably in a continuous way
20/09/2016
GIT Branching Strategies 17
Branch Per Platform
• One branch per platform, next to master• “staging” -> test environment• “QA”• “live” -> production environment• “integration”• ...
• Master contains the latest development code -> could compare to “develop” in other models• As soon as code is deployed on an environment -> code is merged to the corresponding branch• Hotfix needed in production:
• Fix code on “live” branch• Merge back to master• Fix will flow through to the other branches as development continues
20/09/2016
GIT Branching Strategies 18
Branch Per Release
• One branch per release, next to master• “Release/1”, “Release/1/1”, ...
• Release-branches are long-lived -> they can be “locked” but never removed• Master branch keeps a good, strong, stable codebase to start release branches from• When a release is good to go:
• Create a FEATURE branch off master• Cherry-pick changes from RELEASE to this FEATURE• Merge FEATURE back to master• => release-specific changes stay in that release branch
• Why not tagging?• Not automatically created (separate step from committing)• Not automatically pushed (need to use “push –tags”)
20/09/2016
GIT Branching Strategies 19
Case: Telenet Workflow
• Master branch: currently on production• RELEASE_xx.xx branches: designated release
• RELEASE_16.30, RELEASE_16.40, ... (quarterly)• Merged from master
• FEATURE/BUGFIX branches• Merged from RELEASE_xx.xx• Pull requests back to RELEASE_xx.xx
• No hotfixes• If really necessary, a PGL or emergency release can be opened• Actually: hotfix = “new release”
20/09/2016
GIT Branching Strategies 20
Case: Telenet Workflow
• FEATURE/BUGFIX branches are never deployed• FEATURE done:
• Pull request to RELEASE_xx.xx• RELEASE_xx.xx gets deployed on test environment -> auto-update minor version number (16.30.2)• Tag is created with full versioning (16.30.2)• Remove FEATURE branch
• RELEASE done:• RELEASE gets deployed on production• Merge back to MASTER• No new tag is created! Done when releasing the RELEASE_xx.xx branch• Remove RELEASE branch
20/09/2016
GIT Branching Strategies 21
Common
• Master = production code (almost always) - stable• Master and other “long running branches”: never commited to directly
• Merge: use merge commits• Merge: pull request (code reviews)
• Feature branches: regularly “git rebase” • Feature branches: merge & delete -> fully reviewed, fully tested!
• Feature/Hotfix/Bugfix branch: single deliverable
20/09/2016