mirror of https://github.com/nocodb/nocodb
Navi
3 years ago
committed by
GitHub
7 changed files with 331 additions and 120 deletions
@ -0,0 +1,130 @@ |
|||||||
|
## Git Commit Message Convention |
||||||
|
|
||||||
|
> This is adapted from [Conventional Commits 1.0.0](https://www.conventionalcommits.org/en/v1.0.0/). |
||||||
|
|
||||||
|
## Summary |
||||||
|
|
||||||
|
The Conventional Commits specification is a lightweight convention on top of commit messages. |
||||||
|
It provides an easy set of rules for creating an explicit commit history; |
||||||
|
which makes it easier to write automated tools on top of. |
||||||
|
This convention dovetails with [SemVer](http://semver.org), |
||||||
|
by describing the features, fixes, and breaking changes made in commit messages. |
||||||
|
|
||||||
|
The commit message should be structured as follows: |
||||||
|
|
||||||
|
--- |
||||||
|
|
||||||
|
``` |
||||||
|
<type>[optional scope]: <description> |
||||||
|
[optional body] |
||||||
|
[optional footer(s)] |
||||||
|
``` |
||||||
|
--- |
||||||
|
|
||||||
|
<br /> |
||||||
|
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 (this correlates with [`PATCH`](http://semver.org/#summary) in Semantic Versioning). |
||||||
|
1. **feat:** a commit of the _type_ `feat` introduces a new feature to the codebase (this correlates with [`MINOR`](http://semver.org/#summary) in Semantic Versioning). |
||||||
|
1. **BREAKING CHANGE:** a commit that has a footer `BREAKING CHANGE:`, or appends a `!` after the type/scope, introduces a breaking API change (correlating with [`MAJOR`](http://semver.org/#summary) in Semantic Versioning). |
||||||
|
A BREAKING CHANGE can be part of commits of any _type_. |
||||||
|
1. _types_ other than `fix:` and `feat:` are allowed, for example [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (based on the [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) recommends `build:`, `chore:`, |
||||||
|
`ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others. |
||||||
|
1. _footers_ other than `BREAKING CHANGE: <description>` may be provided and follow a convention similar to |
||||||
|
[git trailer format](https://git-scm.com/docs/git-interpret-trailers). |
||||||
|
|
||||||
|
Additional types are not mandated by the Conventional Commits specification, and have no implicit effect in Semantic Versioning (unless they include a BREAKING CHANGE). |
||||||
|
<br /><br /> |
||||||
|
A scope may be provided to a commit's type, to provide additional contextual information and is contained within parenthesis, e.g., `feat(parser): add ability to parse arrays`. |
||||||
|
|
||||||
|
## Examples |
||||||
|
|
||||||
|
### Commit message with description and breaking change footer |
||||||
|
``` |
||||||
|
feat: allow provided config object to extend other configs |
||||||
|
|
||||||
|
BREAKING CHANGE: `extends` key in config file is now used for extending other config files |
||||||
|
``` |
||||||
|
|
||||||
|
### 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 |
||||||
|
``` |
||||||
|
|
||||||
|
### Commit message with both `!` and BREAKING CHANGE footer |
||||||
|
``` |
||||||
|
chore!: drop support for Node 6 |
||||||
|
|
||||||
|
BREAKING CHANGE: use JavaScript features not available in Node 6. |
||||||
|
``` |
||||||
|
|
||||||
|
### Commit message with no body |
||||||
|
``` |
||||||
|
docs: correct spelling of CHANGELOG |
||||||
|
``` |
||||||
|
|
||||||
|
### Commit message with scope |
||||||
|
``` |
||||||
|
feat(lang): add polish language |
||||||
|
``` |
||||||
|
|
||||||
|
### Commit message with multi-paragraph body and multiple footers |
||||||
|
``` |
||||||
|
fix: prevent racing of requests |
||||||
|
|
||||||
|
Introduce a request id and a reference to latest request. Dismiss |
||||||
|
incoming responses other than from latest request. |
||||||
|
|
||||||
|
Remove timeouts which were used to mitigate the racing issue but are |
||||||
|
obsolete now. |
||||||
|
|
||||||
|
Reviewed-by: Z |
||||||
|
Refs: #123 |
||||||
|
``` |
||||||
|
|
||||||
|
## Specification |
||||||
|
|
||||||
|
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). |
||||||
|
|
||||||
|
1. Commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc., followed |
||||||
|
by the OPTIONAL scope, OPTIONAL `!`, and REQUIRED terminal colon and space. |
||||||
|
1. The type `feat` MUST be used when a commit adds a new feature to your application or library. |
||||||
|
1. The type `fix` MUST be used when a commit represents a bug fix for your application. |
||||||
|
1. A scope MAY be provided after a type. A scope MUST consist of a noun describing a |
||||||
|
section of the codebase surrounded by parenthesis, e.g., `fix(parser):` |
||||||
|
1. A description MUST immediately follow the colon and space after the type/scope prefix. |
||||||
|
The description is a short summary of the code changes, e.g., _fix: array parsing issue when multiple spaces were contained in string_. |
||||||
|
1. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description. |
||||||
|
1. A commit body is free-form and MAY consist of any number of newline separated paragraphs. |
||||||
|
1. One or more footers MAY be provided one blank line after the body. Each footer MUST consist of |
||||||
|
a word token, followed by either a `:<space>` or `<space>#` separator, followed by a string value (this is inspired by the |
||||||
|
[git trailer convention](https://git-scm.com/docs/git-interpret-trailers)). |
||||||
|
1. A footer's token MUST use `-` in place of whitespace characters, e.g., `Acked-by` (this helps differentiate |
||||||
|
the footer section from a multi-paragraph body). An exception is made for `BREAKING CHANGE`, which MAY also be used as a token. |
||||||
|
1. A footer's value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer |
||||||
|
token/separator pair is observed. |
||||||
|
1. Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the |
||||||
|
footer. |
||||||
|
1. If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., |
||||||
|
_BREAKING CHANGE: environment variables now take precedence over config files_. |
||||||
|
1. If included in the type/scope prefix, breaking changes MUST be indicated by a |
||||||
|
`!` immediately before the `:`. If `!` is used, `BREAKING CHANGE:` MAY be omitted from the footer section, |
||||||
|
and the commit description SHALL be used to describe the breaking change. |
||||||
|
1. Types other than `feat` and `fix` MAY be used in your commit messages, e.g., _docs: updated ref docs._ |
||||||
|
1. The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase. |
||||||
|
1. BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer. |
||||||
|
|
||||||
|
## Why Use Conventional Commits |
||||||
|
|
||||||
|
* Automatically generating CHANGELOGs. |
||||||
|
* Automatically determining a semantic version bump (based on the types of commits landed). |
||||||
|
* Communicating the nature of changes to teammates, the public, and other stakeholders. |
||||||
|
* Triggering build and publish processes. |
||||||
|
* Making it easier for people to contribute to your projects, by allowing them to explore |
||||||
|
a more structured commit history. |
@ -0,0 +1,130 @@ |
|||||||
|
# NocoDB Contributing Guide |
||||||
|
|
||||||
|
Thanks for spending your time to contribute! The following is a set of guidelines for contributing to NocoDB. |
||||||
|
|
||||||
|
## Table of Contents |
||||||
|
|
||||||
|
- [Pull Request Guidelines](#pull-request-guidelines) |
||||||
|
- [Development Setup](#development-setup) |
||||||
|
* [Committing Changes](#committing-changes) |
||||||
|
* [Applying License](#applying-license) |
||||||
|
+ [Modifying existing file](#modifying-existing-file) |
||||||
|
+ [Creating new file](#creating-new-file) |
||||||
|
+ [Sign your existing work](#sign-your-existing-work) |
||||||
|
+ [Sign your previous work](#sign-your-previous-work) |
||||||
|
- [Project Structure](#project-structure) |
||||||
|
- [Financial Contribution](#financial-contribution) |
||||||
|
- [Credits](#credits) |
||||||
|
|
||||||
|
## Pull Request Guidelines |
||||||
|
|
||||||
|
- When you create a PR, you should fill in all the info defined in this [template](https://github.com/nocodb/nocodb/blob/master/.github/pull_request_template.md). |
||||||
|
|
||||||
|
- We adopt [Gitflow Design](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow). However, we do not have release branches. |
||||||
|
|
||||||
|
![git flow design](https://wac-cdn.atlassian.com/dam/jcr:cc0b526e-adb7-4d45-874e-9bcea9898b4a/04%20Hotfix%20branches.svg?cdnVersion=176) |
||||||
|
|
||||||
|
- The `master` branch is just a snapshot of the latest stable release. All development should be done in dedicated branches. |
||||||
|
**Do not submit PRs against the `master` branch.** |
||||||
|
|
||||||
|
- Checkout a topic branch from the relevant branch, e.g. `develop`, and merge back against that branch. |
||||||
|
|
||||||
|
- Multiple small commits are allowed on the PR - They will be squashed into one commit before merging. |
||||||
|
|
||||||
|
- If your changes are related to a special issue, add `ref: #xxx` to link the issue where xxx is the issue id. |
||||||
|
|
||||||
|
## Development Setup |
||||||
|
|
||||||
|
Please refer to [Development Setup](https://github.com/nocodb/nocodb#development-setup). |
||||||
|
|
||||||
|
### Committing Changes |
||||||
|
|
||||||
|
We encourage all contributors to commit messages following [Commit Message Convention](./COMMIT_CONVENTION.md). |
||||||
|
|
||||||
|
### Applying License |
||||||
|
|
||||||
|
NocoDB doesn't require a CLA (Contributor License Agreement). |
||||||
|
We require [Developer Certificate of Origin (DCO)](https://github.com/nocodb/nocodb/blob/master/.github/developer-certificate-of-origin) as an additional safeguard |
||||||
|
for the NocoDB project. This is a well established and widely used |
||||||
|
mechanism to assure contributors have confirmed their right to license |
||||||
|
their contribution under the project's license. |
||||||
|
|
||||||
|
#### Modifying existing file |
||||||
|
If you modify an existing file, please keep the existing license header as |
||||||
|
it is and just add your copyright notice and author: |
||||||
|
|
||||||
|
```` |
||||||
|
@author <your name> <your email address> |
||||||
|
```` |
||||||
|
|
||||||
|
#### Creating new file |
||||||
|
|
||||||
|
```` |
||||||
|
/** |
||||||
|
* @copyright Copyright (c) <year>, <your name> (<your email address>) |
||||||
|
* |
||||||
|
* @author <your name> <your email address> |
||||||
|
* |
||||||
|
* @license GNU AGPL version 3 or any later version |
||||||
|
* |
||||||
|
* This program is free software: you can redistribute it and/or modify |
||||||
|
* it under the terms of the GNU Affero General Public License as |
||||||
|
* published by the Free Software Foundation, either version 3 of the |
||||||
|
* License, or (at your option) any later version. |
||||||
|
* |
||||||
|
* This program is distributed in the hope that it will be useful, |
||||||
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of |
||||||
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
||||||
|
* GNU Affero General Public License for more details. |
||||||
|
* |
||||||
|
* You should have received a copy of the GNU Affero General Public License |
||||||
|
* along with this program. If not, see <http://www.gnu.org/licenses/>. |
||||||
|
* |
||||||
|
*/ |
||||||
|
```` |
||||||
|
|
||||||
|
#### Sign your existing work |
||||||
|
|
||||||
|
Usually email will be already configured with your Github. |
||||||
|
|
||||||
|
```bash |
||||||
|
git config --global user.name "FirstName LastName" |
||||||
|
git config --global user.email "email@provider.com" |
||||||
|
``` |
||||||
|
Refer [here](https://support.atlassian.com/bitbucket-cloud/docs/configure-your-dvcs-username-for-commits/) for additional details. |
||||||
|
|
||||||
|
```bash |
||||||
|
git add . |
||||||
|
git commit -s -m "commit message" |
||||||
|
``` |
||||||
|
|
||||||
|
Please note : Use your real name (sorry, no pseudonyms or anonymous contributions). |
||||||
|
|
||||||
|
Once pushed - you should see the commit have the following template in github |
||||||
|
```` |
||||||
|
Signed-off-by: FirstName Initials/Lastname <email@provider.com> |
||||||
|
```` |
||||||
|
|
||||||
|
#### Sign your previous work |
||||||
|
|
||||||
|
In case you forget to sign your work, you can do the following: |
||||||
|
|
||||||
|
```bash |
||||||
|
# sign the last N commits - replace N before executing the command |
||||||
|
git rebase HEAD~N --signoff |
||||||
|
git push -f |
||||||
|
``` |
||||||
|
|
||||||
|
## Project Structure |
||||||
|
|
||||||
|
Please refer to [NocoDB Repository Structure](https://docs.nocodb.com/#nocodb-repository-structure). |
||||||
|
|
||||||
|
## Financial Contribution |
||||||
|
|
||||||
|
Isn't this product cool? We are working on this full time. Your donations will definitely help us to make this even better. |
||||||
|
|
||||||
|
- [Funding NocoDB's work on Github](https://github.com/sponsors/nocodb) |
||||||
|
|
||||||
|
## Credits |
||||||
|
|
||||||
|
Once again. Thank you to all the people who have already contributed to NocoDB! |
@ -1,73 +0,0 @@ |
|||||||
# How to apply a license |
|
||||||
NocoDB doesn't require a CLA (Contributor License Agreement). |
|
||||||
We require Developer Certificate of Origin (DCO) as an additional safeguard |
|
||||||
for the NocoDB project. This is a well established and widely used |
|
||||||
mechanism to assure contributors have confirmed their right to license |
|
||||||
their contribution under the project's license. |
|
||||||
|
|
||||||
## Modifying existing file |
|
||||||
If you modify an existing file, please keep the existing license header as |
|
||||||
it is and just add your copyright notice and author: |
|
||||||
|
|
||||||
```` |
|
||||||
@author <your name> <your email address> |
|
||||||
```` |
|
||||||
|
|
||||||
## Creating new file |
|
||||||
```` |
|
||||||
/** |
|
||||||
* @copyright Copyright (c) <year>, <your name> (<your email address>) |
|
||||||
* |
|
||||||
* @author <your name> <your email address> |
|
||||||
* |
|
||||||
* @license GNU AGPL version 3 or any later version |
|
||||||
* |
|
||||||
* This program is free software: you can redistribute it and/or modify |
|
||||||
* it under the terms of the GNU Affero General Public License as |
|
||||||
* published by the Free Software Foundation, either version 3 of the |
|
||||||
* License, or (at your option) any later version. |
|
||||||
* |
|
||||||
* This program is distributed in the hope that it will be useful, |
|
||||||
* but WITHOUT ANY WARRANTY; without even the implied warranty of |
|
||||||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
|
||||||
* GNU Affero General Public License for more details. |
|
||||||
* |
|
||||||
* You should have received a copy of the GNU Affero General Public License |
|
||||||
* along with this program. If not, see <http://www.gnu.org/licenses/>. |
|
||||||
* |
|
||||||
*/ |
|
||||||
```` |
|
||||||
|
|
||||||
|
|
||||||
## How to sign your work |
|
||||||
|
|
||||||
### First configure your Git username/email : |
|
||||||
Usually email will be already configured with your github. |
|
||||||
|
|
||||||
```bash |
|
||||||
git config --global user.name "FirstName LastName" |
|
||||||
git config --global user.email "email@provider.com" |
|
||||||
``` |
|
||||||
Refer [here](https://support.atlassian.com/bitbucket-cloud/docs/configure-your-dvcs-username-for-commits/) for additional details |
|
||||||
|
|
||||||
```bash |
|
||||||
git add . |
|
||||||
git commit -s -m "commit message" |
|
||||||
``` |
|
||||||
|
|
||||||
Please note : Use your real name (sorry, no pseudonyms or anonymous contributions). |
|
||||||
|
|
||||||
Once pushed - you should see the commit have the following template in github |
|
||||||
```` |
|
||||||
Signed-off-by: FirstName Initials/Lastname <email@provider.com> |
|
||||||
```` |
|
||||||
|
|
||||||
## How to sign your previous work |
|
||||||
|
|
||||||
In case you forget to sign your work, you can do the following: |
|
||||||
|
|
||||||
```bash |
|
||||||
# sign the last N commits - replace N before executing the command |
|
||||||
git rebase HEAD~N --signoff |
|
||||||
git push -f |
|
||||||
``` |
|
Loading…
Reference in new issue