gaspersic/freeCodeCamp
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

feat(docs): host docs with docsify

Browse Source
This commit is contained in:
Mrugesh Mohapatra
2020-04-06 17:47:40 +05:30
parent 40c5d4384e
commit 09cd14fd22
16 changed files with 1037 additions and 437 deletions
Download Patch File Download Diff File Expand all files Collapse all files

71
docs/how-to-open-a-pull-request.md
View File

@ -1,49 +1,68 @@
<!-- do not translate this -->
| [Read these guidelines in other languages](/docs/i18n-languages) |
|-|
<!-- do not translate this -->
# How to open a Pull Request (PR)
# How to open a Pull Request
A pull request enables you to send changes from your fork on GitHub to freeCodeCamp.org's main repository. Once you are done making changes to the code, or coding challenges you should follow these guidelines to send a PR.
## How to prepare a good Pull Request title:
## Prepare a good PR title
When opening a Pull Request(PR), use the following scope table to decide what to title your PR in the following format:
`fix/feat/chore/refactor/docs/perf (scope): PR Title`
We recommend using [conventional title and messages](https://www.conventionalcommits.org/) for commits and pull request. The convention has the following format:
An example is `fix(learn): Fixed tests for the do...while loop challenge`.
> `<type>([optional scope(s)]): <description>`
>
> For example:
>
> `fix(learn): tests for the do...while loop challenge`
| Scope | Documentation |
|---|---|
| `learn`,`curriculum` | For Pull Requests making changes to the curriculum challenges. |
| `client` | For Pull Requests making changes to client platform logic or user interface |
| `guide` | For Pull Requests which make changes to the guide. |
| `docs` | For Pull Requests making changes to the project's documentation. |
When opening a Pull Request(PR), you can use the below to determine the type, scope (optional) and description.
## Proposing a Pull Request (PR)
**Type:**
| Type | When to select |
| :---- | :--------------------------------------------------------------------------- |
| fix | Changed or updated/improved functionality, tests, verbiage of a lesson, etc. |
| feat | Only if you are adding new functionality, tests, etc. |
| chore | Changes that are not related to code, tests or verbiage of a lesson. |
| docs | Changes to `/docs` directory or the contributing guidelines, etc. |
**Scope:**
You can select a scope from [this list of labels](https://github.com/freeCodeCamp/freeCodeCamp/labels?q=scope).
**Description:**
Keep it short (less than 30 characters) and simple, you can add more information in the PR description box and comments.
Some examples of good PRs titles would be:
- `fix(a11y): improved search bar contrast`
- `feat: add more tests to html and css challenges`
- `fix(api,client): prevent CORS errors on form submission`
- `docs(i18n): Chinese translation of local setup`
## Proposing a Pull Request
1. Once the edits have been committed, you will be prompted to create a pull request on your fork's GitHub Page.
![Image - Compare pull request prompt on GitHub](/docs/images/github/compare-pull-request-prompt.png)
![Image - Compare pull request prompt on GitHub](./images/github/compare-pull-request-prompt.png)
2. By default, all pull requests should be against the freeCodeCamp main repo, `master` branch.
Make sure that your Base Fork is set to freeCodeCamp/freeCodeCamp when raising a Pull Request.
Make sure that your Base Fork is set to freeCodeCamp/freeCodeCamp when raising a Pull Request.
![Image - Comparing forks when making a pull request](/docs/images/github/comparing-forks-for-pull-request.png)
![Image - Comparing forks when making a pull request](./images/github/comparing-forks-for-pull-request.png)
3. Submit the pull request from your branch to freeCodeCamp's `master` branch.
4. In the body of your PR include a more detailed summary of the changes you made and why.
- You will be presented with a pull request template. This is a checklist that you should have followed before opening the pull request.
- You will be presented with a pull request template. This is a checklist that you should have followed before opening the pull request.
- Fill in the details as you see fit. This information will be reviewed and the reviewers will decide whether or not your pull request is accepted.
- Fill in the details as you see fit. This information will be reviewed and the reviewers will decide whether or not your pull request is accepted.
- If the PR is meant to address an existing GitHub Issue then, at the end of
your PR's description body, use the keyword _Closes_ with the issue number to [automatically close that issue if the PR is accepted and merged](https://help.github.com/en/articles/closing-issues-using-keywords).
> Example: `Closes #123` will close issue 123
- If the PR is meant to address an existing GitHub Issue then, at the end of
your PR's description body, use the keyword _Closes_ with the issue number to [automatically close that issue if the PR is accepted and merged](https://help.github.com/en/articles/closing-issues-using-keywords).
> Example: `Closes #123` will close issue 123
5. Indicate if you have tested on a local copy of the site or not.
This is very important when making changes that are not just edits to text content like documentation or a challenge description. Examples of changes that need local testing include JavaScript, CSS, or HTML which could change the functionality or layout of a page.
This is very important when making changes that are not just edits to text content like documentation or a challenge description. Examples of changes that need local testing include JavaScript, CSS, or HTML which could change the functionality or layout of a page.