Mall developing standards
===

## Branch naming
> It's recommended to use all lower caps letters and hyphen (-) to separate words unless it is a specific item name or ID. Underscore (_) could be used to separate the ID and description.

e.g. `GI-1234_more-gray-shades`

#### Feature
> This branch is created based on the current development branch.

e.g. `feature/support-dark-theme`

#### Bug fix
> Any necessary fixes should be done on the bugfix branch.

e.g. `bugfix/GI-1234_more-gray-shades`

#### Merging
> A temporary branch for resolving merge conflicts.

e.g. `merge/9.6-to-9.7`

==:rocket: Discussion==
- [ ] hyphen approach<br>e.g. `bugfix/GI-1234-more-gray-shades` or `bugfix-GI-1234-more-gray-shades` or `bugfix-gi-1234-more-gray-shades`
- [x] feature/more-gray-shades
- [x] bugfix/GI-1234-more-gray-shades
- [x] header-refactor/more-gray-shades

## Git commit message
#### Rules
1. Capitalize the subject line
2. Do not end the subject line with a period
3. Use the body to explain what changes you have made and why you made them

#### Template

<type>: <description>

[optional body]

[optional footer(s)]

* Type:
* **feat**: introduces a new feature to the codebase
* **fix**: fix a bug in your codebase
* **docs**: everything related to documentation
* **style**: feature and updates related to styling
* **refactor**: refactoring a specific section of the codebase
* **perf**: A code change that improves performance
* **test**: everything related to testing
* **chore**: regular code maintenance (e.g. lib upgrade)
* **revert**

#### Example

#Commit message with ! to draw attention to breaking change
refactor!: drop support for Node 6


#Commit message with multi-paragraph body and footer
fix: Capitalized, short (50 chars or less) summary

Wrap it to about 72 characters or so.  
Further paragraphs come after blank lines.

- Bullet points are okay, too

- Typically a hyphen or asterisk is used for the bullet, followed by a single space, with blank lines in between, but conventions vary here

If you use an issue tracker, add a reference(s) to them at the bottom,
like so:

Ref: #GI-1234

## Pull request template

### PR Title
> Make a self-explanatory title describing what the pull request does.

Template: [status][type][ticket number] title
Sample: `[WIP][Header Refactor][9.6][GI-21126] Fix product links in search page`

Feature: `[Header Refactor][9.6][GI-21126] Fix product links in search page`

Feature Bug: `[Fix][Header Refactor][9.6][GI-21126] Fix product links in search page`

Sprint Bug: `[Fix][9.6][GI-21126] Fix product links in search page`

* status tags:
* **WIP**: Work in progress
* **URGENT**
* **PENDING**
* **TBD**: To be discussed
* **DO NOT MERGE**
* type tags:
* **Fix**
* **Feature**
* **Refactor**
* **Experiment**
* **Merge**

==:rocket: Discussion==
- [x] Including release version or not<br>e.g. `[WIP][Fix][9.6][GI-21126] Fix product links in search page`
- [x] Define status tags
- [x] Define type tags

### PR Description
Detail with what was changed, why it was changed, and how it was changed.

:::info
### Description
Clearly and concisely describe the PR
### Spec & Design (optioal)
Attach the design or realted document
spec:
Wireframe:
Mockup: https://zpl.io/VKMoO88
### Related PR & Ticket (optional)
* [#3511](https://gitpub.rakuten-it.com/projects/GEPMALL/repos/tw-ui-mall/pull-requests/3511/overview)
* [#3512](https://gitpub.rakuten-it.com/projects/GEPMALL/repos/tw-ui-mall/pull-requests/3512/overview)
### Personal deploy
https://rwasp-pr3417-qa-www.rakuten.com.tw/

### How to test
Provide the appropriate test case

### Area affected
- [] Search
- [] Shop
- [] Top
- [] Checkout

### Check before merge
- [] merged the current development branch (before testing)
- [] merged the current development branch (before testing)

### TODO (optional)
- [] to do list
:::

==:rocket: Discussion==
- [ ] Code coverage or test case

## Change log
- [ ] Automation tool for Conventional Commits and CHANGELOG

## Merge strategy
TBD

==:rocket: Discussion==
- [ ] Squash commit