- Setting up your local environment
- The process of making changes
- Creating pull requests
- Reviewing pull requests
- Merging pull requests
To get started, you will need to have git installed locally. Depending on your operating system, there are also several other dependencies required. These are detailed in the building guide.
Once you have git and all other dependencies installed, you can proceed to the following steps:
Fork the project on Github and clone it locally:
git clone https://github.com/username/<repository-name>.git
cd <repository-name>
git remote add upstream <repository-git-url>
git fetch upstreamIf you haven't done that already, configure git so that it knows who you are:
git config user.name "Your name"
git config user.email "Your e-mail"As a best practice, keep your development environment as organized as possible. An excellent way to organize is to split your work into a new branch. These should also be created directly off the main branch:
git checkout -b my-branch -t upstream/main💡 TIP: We suggest using the gitflow pattern as a naming pattern for your branches
You can pick an issue to solve directly from our [issues board][repository-issues-board]. There are many labels you can use that would help you choose the right fit for you.
If this is your first contribution, we suggest starting by filtering the [good first issue label][good-first-issue-label-url] since we add this label only to issues with a constrained scope that is easier to solve.
While coding, we suggest following the best practices and keep in mind the [SOLID principles][solid-explanation]. Also, it would be best if you considered reading our [architecture decision log][architecture-decision-log] to understand the details regarding our system architecture.
As a best practice, try to keep your changes as logically grouped as possible within individual commits. We don't limit the number of commits in a particular pull request, so you can commit as many times as you want.
To make it easier while debugging, your commit messages should be standardized. We follow the [Conventional Commits Standard][conventional-commits].
This project follows a strict lint pattern. We've decided to do so to keep a standard in our codebase. A standardized codebase is easier to explore and understand. After finishing your issue, you can run the following snippet to lint your code, fixing any warnings and errors afterward:
<project-linting-snippet>Before opening a pull request, it is a good practice to merge your work with the upstream main branch. We suggest using rebase for it. You can do so with the following:
git fetch upstream
git rebase upstream/mainBefore opening a pull request, you must ensure that all previous tests are passing and that the new code you're adding is covered with tests. We've created a simple [writting tests guide][writting-tests-guide] that explains how you can add tests for your solved issue.
Read the [running tests guide][running-tests-guide] to understand how to execute this project's automated tests.
Once you've finished your issue, rebased, linted, and all tests are passing, you can push your code to your remote branch. You can do so with the following command:
git push origin my-branchFrom GitHub, opening a new pull request will present you with a [pull request template][pull-request-template]. Please try to do your best at filling out the details, but feel free to skip parts if you're not sure what to put.
Once opened, pull requests are usually reviewed within a few days.
You will probably get feedback or requests for changes to your pull request. This is a big part of the submission process, so don't be discouraged! Some contributors may sign off on the pull request right away; others may have more detailed comments or feedback. This is a necessary part of the process to evaluate whether the changes are correct and necessary.
Make changes to an existing pull request, make the changes to your local branch, add a new commit with those changes, and push those to your fork. GitHub will automatically update the pull request.
git add my/changed/files
git commit
git push origin my-branchIt is also frequently necessary to synchronize your pull request with other changes that have landed in main by using git rebase:
git fetch --all
git rebase upstream/master
git push originIt is an excellent practice to review your code, as well as other contributors' pull requests. We encourage everyone to contribute with pull requests by commenting and suggesting improvements.
While reviewing a pull request, we suggest the [Netlify's Feedback Ladder][netlify-feedback-ladder-explanation]. It is an easy standard to apply, improving our feedback structure while making pull requests.
Also, don't forget to always follow our [Code of Conduct][code-of-conduct] while interacting with others.
To land, a pull request must be reviewed and approved by one Phant collaborator. After that, as long as there are no objections from other contributors, the pull request can be merged.
[repository-issues-board]: /issues [good-first-issue-label-url]: /labels/good%20first%20issue [solid-explanation]: https://en.wikipedia.org/wiki/SOLID [architecture-decision-log]: ../adl [conventional-commits]: https://www.conventionalcommits.org/en/v1.0.0/ [writting-tests-guide]: ../writting-tests.md [running-tests-guide]: ../running-tests.md [pull-request-template]: ../../../.github/PULL_REQUEST_TEMPLATE.md [netlify-feedback-ladder-explanation]: https://www.netlify.com/blog/2020/03/05/feedback-ladders-how-we-encode-code-reviews-at-netlify/ [code-of-conduct]: ../../../CODE_OF_CONDUCT.md