Skip to Content
DevelopmentProcessesPull Request

Pull Request Process

Branch name

<prefix>/<task ID>-<task name>
  • Prefix: Using prefixes in branch names helps to quickly identify the purpose of the branches. Here are some common types of branches with their corresponding prefixes: - Feature Branches: These branches are used for developing new features. Use the prefix feature/. For instance, feature/login-system.
    • Bugfix Branches: These branches are used to fix bugs in the code. Use the prefix bugfix/. For example, bugfix/header-styling. - Hotfix Branches : These branches are made directly from the production branch to fix critical bugs in the production environment. Use the prefix hotfix/. For instance, hotfix/critical-security-issue.
    • Release Branches: These branches are used to prepare for a new production release. Use the prefix release/. For example, release/v1.0.1.
    • Documentation Branches: These branches are used to write, update, or fix documentation. Use the prefix docs/. For instance, docs/api-endpoints.
  • Task ID: is the Task ID on Redmine or the other task management tool
  • Task name: is the name of the task in KebabCase

Examples

  • The Redmine task: #2131 [FE] Implement api add device

    The branch name: feature/2131-implement-api-add-device

Commit

Commit message

The commit message should have less than 72 characters in the first line and should be in the present tense.

The first line should be a concise summary of the commit.

The commit message should be structured as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

The commit contains the following structural elements, to communicate intent to the consumers of your library:

  1. fix: a commit of the type fix patches a bug in your codebase.
  2. feat: a commit of the type feat introduces a new feature to the codebase.
  3. BREAKING CHANGE: a commit that appends a ! after the type/scope, introduces a breaking API change.
  4. types other than fix: and feat: are allowed, for example @commitlint/config-conventional recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.

Examples

  • Commit message with description 
    feat: allow provided config object to extend other configs
  • Commit message with ! to draw attention to breaking change 
    feat!: send an email to the customer when a product is shipped
  • Commit message with scope and ! to draw attention to breaking change 
    feat(api)!: send an email to the customer when a product is shipped

Pull Request description

Format:

## What?
## Why?
## How?
## Testing?
## Screenshots (optional)
## Anything Else?

What

Explain the changes you’ve made

Example

## What?
I've added support for authentication to implement Key Result 2 of OKR1. It includes
model, table, controller and test. For more background, see ticket #2131.

Why

The “why” tells us what business or engineering goal this change achieves

Example

## Why?
These changes complete the user login and account creation experience. See #2131 for more information.

How

Example

## How?
This includes a migration, model and controller for user authentication. I'm using Devise to do the heavy lifting. I ran Devise migrations and those are included here.

Testing

Some conditions or edge cases were tested and not tested, why they weren’t tested, how likely they will occur, and if so, any associated risks.

The testing checklist you can referent here

Example

## What?
I've added support for authentication to implement Key Result 2 of OKR1. It includes model, table, controller and test. For more background, see ticket
#2131.
## Why?
These changes complete the user login and account creation experience. See #2131 for more information.
## How?
This includes a migration, model and controller for user authentication. I'm using Devise to do the heavy lifting. I ran Devise migrations and those are included here.
## Testing?
- Functional Testing: Pass
- Security: Pass
- Performance: Pass
- Error Handling: 75%
  - Check for efficient use of resources (CPU, memory): The used CPU increases 25% when using login API. Will improve on the next PR
- Code Quality: Pass
- Documentation: Pass
- Database: Pass
- Deployment: Pass
- Final Review: Pass
## Screenshots (optional)
0
## Anything Else?
Let's consider using a 3rd party authentication provider for this, to offload MFA and other considerations as they arise and as the privacy landscape evolves. AWS Cognito is a good option, so is Firebase. I'm happy to start researching this path. Let's also consider breaking this out into its own service. We can then re-use it or share the accounts with other apps in the future.

Request review Pull Request

For easy to track and get the notification, we use request review Pull Request via Slack message

The message should tag the reviewer and contain the PR’s link, a brief description of this PR

Example

Hi @Pha Nguyen
Please help me review this PR
PR: https://github.com/digitalfortress-dev/foundation/pull/15
Description: Define the Pull Request convention
Last updated on
Project ConfigurationRedmine