anchor.diff:  2. Tag the version and push the tag upstream:
   +
       git tag 2.1.6
  -    git push -u origin 2.1.6
  +    git push origin 2.1.6
   
   Once the release is complete, the hotfix branch needs to be deleted. Although this can of course be done from the command line, it is cumbersome, and we recommend using a decent Git client (like SourceTree) that can do this for you.
   
  
positive.code: 
  Once a issue is complete and tested, a Pull Request should be created for
  peer review.
  
  === Patch Requests
  
  If the change is a bug fix, contains no new features, and
  does not change any public or protected APIs (class or method signatures in the
  core module, i.e. code included in the release archive) then
  
  1. the Pull Request should target the _master_ branch. Once the Pull Request is created
  2. it should be reviewed and any modifications can be made to the issue branch as recommended.
  3. Once a Pull Request has been approved it can be
  4. scheduled for a patch release (if not already) by updating the milestone label.
  5. Only when a Pull Request is approved *and* scheduled for the next patch release it can be merged
  into the _master_ branch then
  6. the issue branch can be closed.
  7. After a PR has been merged into the _master_ branch, the _master_ branch should
  then be merged into the _develop_ branch and any conflicts (such as due to new
  features) should be resolved.
  This can be done from the command line from a clean checkout as follows:
  
      git checkout develop
  
negative.code: 
  4. Push the newly created branch, as follows:
  +
      git push origin releases/2.1.6
  
  Bug fixes are typically added to a hotfix release branch by https://git-scm.com/docs/git-cherry-pick[cherry-picking] the relevant commits from the _master_ branch. 
  
  