Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Sign up
Appearance settings

Github standards initial commit #4

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
mesaugat merged 8 commits into develop from github
Jun 22, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions docs/git/branching_naming_convention.md
View file Open in desktop
Original file line number Diff line number Diff line change
@@ -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
25 changes: 25 additions & 0 deletions docs/git/branching_strategy.md
View file Open in desktop
Original file line number Diff line number Diff line change
@@ -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>.
37 changes: 37 additions & 0 deletions docs/git/code_review_checklist.md
View file Open in desktop
Original file line number Diff line number Diff line change
@@ -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>
15 changes: 15 additions & 0 deletions docs/git/pull_request_best_pratices.md
View file Open in desktop
Original file line number Diff line number Diff line change
@@ -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.
Copy link
Member

@mesaugat mesaugat Jun 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to be very strict. I think other team members should be able to resolve a comment too.

* 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.
18 changes: 18 additions & 0 deletions docs/git/smart_commit.md
View file Open in desktop
Original file line number Diff line number Diff line change
@@ -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
17 changes: 17 additions & 0 deletions docs/git/tagging.md
View file Open in desktop
Original file line number Diff line number Diff line change
@@ -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" .
14 changes: 14 additions & 0 deletions sidebars.js
View file Open in desktop
Original file line number Diff line number Diff line change
@@ -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"]
}
};

AltStyle によって変換されたページ (->オリジナル) /