Fixed the issue mentioned in pull request.

Author: bipenc

docs/git/branching_naming_convention.md

@@ -1,14 +1,20 @@
 ---
-id: branching_naming_convention
-title: Branching Naming Convention
-sidebar_label: Branching Naming Convention
+id: branch_naming_convention
+title: Branch Naming Convention
+sidebar_label: Branch Naming Convention
 ---
 
 #### The following convention should be followed:
 
-* Branch name should exactly match with the corresponding jIRA ticket that you will be working on. `<project-name>-<ticket-number>`
+* Branch name should exactly match with the corresponding JIRA ticket that you will be working on. `<project-name>-<ticket-number>`
 
+   Examples:
 
-   eg:  
           * FHF-100
-          * DEL-200
+          * DEL-200
+
+* If there's no JIRA or project management tool in use, the branch naming strategy should be feature specific. 
+
+   Examples: 
+           * upgrade-php 
+           * add-button-tooltip          

docs/git/branching_strategy.md

@@ -4,21 +4,22 @@ title: Branching Strategy
 sidebar_label: Branching Strategy
 ---
 
-#### Main branches:
+#### Main Branches:
 
 * master (Production)
 * dev (Development)
 * qa (QA)
 * uat (UAT)
 * staging (Staging)
 
-#### Supporting branches:
+#### Supporting Branches:
 
 * Feature branches
 * Release branches
 * Hotfix branches
 
 #### The following convention should be followed:
+
 * Every branch should be a branch of `dev` and should be merged to `dev` after PR is reviewed
 * Every feature, task is done in a separate branch <b>named according to the JIRA issue name</b>.
 * Any critical bug after production release is done via hotfix branches. It is branched off from `master` and <b>merged back to master and dev after it’s done</b>. 

docs/git/code_review_checklist.md

@@ -1,10 +1,10 @@
 ---
-id: code_reviewe_checklist
+id: code_review_checklist
 title: Code Review Checklist
 sidebar_label: Code Review Checklist
 ---
 
-Smart commits allows a team to perform actions on Jira issues from a single commit.  Users can enter the issue key and the desired action such as time tracking or closing an issue.
+Smart commits allows a team to perform actions on JIRA issues from a single commit. Users can enter the issue key and the desired action such as time tracking or closing an issue.
 
 #### List:
 
@@ -18,7 +18,6 @@ Smart commits allows a team to perform actions on Jira issues from a single comm
 * Repetitive code has been factored out
 * Frameworks have been used appropriately – methods have all been defined appropriately
 * Command classes have been designed to undertake one task only
-* JSPs do not contain business logic
 * Unit tests are present and correct
 * Common errors have been checked for
 * Potential threading issues have been eliminated where possible
@@ -29,7 +28,6 @@ Smart commits allows a team to perform actions on Jira issues from a single comm
 * The code does not use unjustifiable static methods/blocks
 * The code complies to coding standards
 * Logging used appropriately (proper logging level and details)
-* NPEs and AIOBs
 * The code does not reinvent the wheel
 * The code does not have any side effect on existing functionality
 

docs/git/pull_request_best_pratices.md

@@ -5,11 +5,11 @@ sidebar_label: Pull Request Best Practices
 ---
 
 #### Best Practices:
+
 * Pull Request should atleast be <b>reviewed by 1 person</b> before merging it to the base branch.
 * Only comment author can resolve comment – if code was corrected or after discussion author decides to fix it.
 * Don’t mention the same problem many times. Don’t bloat the code, say it once and ask to fix everywhere.
 * If there are pending, not resolved comments, the assignee is a code author who should fix or comment back.
 * If there are discussions commented by the code author, the assignee is reviewer, who should continue a discussion or resolve comments and approve.
 * Use labels to mark what actions should be next – e.g. `needs review`, `Reviewed By... ` etc.
-* Provide details/screenshots about what has been changed
-* In cases of frontend, use screenshots if applicable.
+* Provide details/screenshots about what has been changed.

docs/git/smart_commit.md

@@ -12,6 +12,7 @@ Smart commits allows a team to perform actions on Jira issues from a single comm
 * `#time` : Records time tracking information against a Jira issue.
 * `#<transition-name>` :  Moves the Jira issue to a particular workflow state.
 
-eg: 
-* `git commit -m "TEST-34 #time 1w 2d 4h 30m Total work logged"`.
-* `TEST-101 #time 4h 30m Fix null pointers #comment Fixed code #resolve`
+#### Examples:
+
+    - git commit -m "FHF-34 #time 1w 2d 4h 30m Total work logged".
+    - DEL-101 #time 4h 30m Fix null pointers #comment Fixed code #resolve

docs/git/tagging.md

@@ -9,15 +9,9 @@ Semantic Versioning is all about releases, not builds. This means that the versi
 Following are the standards that should be followed while tagging releases:
 
 * Every release should have a tag.
-
 * You can tag from any long running branch ( dev, qa, staging, master). However, we strictly follow tagging from master branch.
-
 * Tag name should follow the *major.minor.patch_* naming conventions as suggested by <a href="https://semver.org/" target="_blank">Semantic Versioning</a>
-
 * The tag for a version is in "X.Y.Z" format where,
-
     * Z is hot-fixes and patch release. If the release includes hot-fixes and patches, we increment this value by 1. Example : "2.7.1", "2.7.2"
-
     * Y includes major feature releases. If the release includes a major feature which is going to production for the first time we increase this value by 1. Example: "2.8.0", "2.9.0"
-
     * X is increased when there is a major change in the system which affects the entire application flow or UI/UX(flow) of a system. Example: "3.0.0", "4.0.0" .

sidebars.js

@@ -2,7 +2,7 @@ module.exports = {
   "docs": {
     "Overview": ["introduction"],
     "Github": [
-      "git/branching_naming_convention",
+      "git/branch_naming_convention",
       "git/branching_strategy",
       "git/smart_commit",
       {
@@ -13,7 +13,7 @@ module.exports = {
         ]
       },
       "git/pull_request_best_pratices",
-      "git/code_reviewe_checklist"
+      "git/code_review_checklist"
     ],
     "Naming Convention": ["files", "classes", "functions", "variables", "constants", "folders"]
   }