Merge pull request #4 from leapfrogtechnology/github

Github standards initial commit

Author: mesaugat

docs/git/branching_naming_convention.md

@@ -0,0 +1,19 @@
+---
+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>`
+     
+   Examples:
+          * FHF-100
+          * 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

@@ -0,0 +1,25 @@
+---
+id: branching_strategy
+title: Branching Strategy
+sidebar_label: Branching Strategy
+---
+
+#### Main Branches:
+
+* master (Production)
+* dev (Development)
+* qa (QA)
+* uat (UAT)
+* staging (Staging)
+
+#### 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

@@ -0,0 +1,37 @@
+---
+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.
+
+#### List:
+
+* Description Confirmed?
+* The code meets the business requirements
+* Comments are comprehensible and add something to the maintainability of the code
+* Comments are neither too numerous nor verbose
+* Types have been generalized where possible
+* Parameterized types have been used appropriately
+* Exceptions have been used appropriately
+* 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
+* Unit tests are present and correct
+* Common errors have been checked for
+* Potential threading issues have been eliminated where possible
+* Any security concerns have been addressed
+* Performance was considered
+* The functionality fits the current design/architecture
+* The code is unit testable
+* The code does not use unjustifiable static methods/blocks
+* The code complies to coding standards
+* Logging used appropriately (proper logging level and details)
+* The code does not reinvent the wheel
+* The code does not have any side effect on existing functionality
+
+
+##### References: 
+
+<a href="https://lftechnology.atlassian.net/wiki/spaces/PPM/pages/25854080/Code+Review+Checklist+for+Reviewers" target="_blank"> Code Review Checklist</a>

docs/git/pull_request_best_pratices.md

@@ -0,0 +1,15 @@
+---
+id: pull_request_best_pratices
+title: Pull Request Best Practices
+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.

docs/git/smart_commit.md

@@ -0,0 +1,18 @@
+---
+id: smart_commit
+title: Smart Commit
+sidebar_label: Smart Commit
+---
+
+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.
+
+#### Some of the mostly used smart commands:
+
+* `#comment`:  Adds a comment to a JIRA issue. `ISSUE_KEY #comment <your comment text>`
+* `#time` : Records time tracking information against a JIRA issue.
+* `#<transition-name>` :  Moves the JIRA issue to a particular workflow state.
+
+#### 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

@@ -0,0 +1,17 @@
+---
+id: tagging
+title: Tagging
+sidebar_label: Tagging
+---
+
+Semantic Versioning is all about releases, not builds. This means that the version only increases after you release.
+
+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

@@ -1,6 +1,20 @@
 module.exports = {
   "docs": {
     "Overview": ["introduction"],
+    "Github": [
+      "git/branch_naming_convention",
+      "git/branching_strategy",
+      "git/smart_commit",
+      {
+        "type": "category",
+        "label": "Release Management",
+        "items": [
+          "git/tagging"
+        ]
+      },
+      "git/pull_request_best_pratices",
+      "git/code_review_checklist"
+    ],
     "Naming Convention": ["files", "classes", "functions", "variables", "constants", "folders"]
   }
 };