Git branching strategies

GIT Branching Strategies 2

GIT Branching Strategies

https://nl.linkedin.com/in/tizianatroukens@tizianatroukens

Tiziana TroukensWeb Application Consultant

20/09/2016


GIT: Concepts

20/09/2016


GIT: Concepts

REF: pointer to an object

TAG: special REF used to mark a commit in history

20/09/2016


GIT: Concepts

BRANCH: REF to a commit = HEAD

20/09/2016


GIT: Branches

20/09/2016


GIT: Branches

20/09/2016


GIT: Merges

20/09/2016


GIT: Concepts

MERGE: keeps the context of the feature’s commits

FAST-FORWARD MERGE: will shift the HEAD tag

20/09/2016


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


A Succesful Git Branching Model

20/09/2016



20/09/2016



20/09/2016


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


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


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


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


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


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


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


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

Software

Git branching strategies