Contributing (Pull Requests)
Making your changes available for review
Last updated
Making your changes available for review
Last updated
Whether via automated means (such as unit/functional testing) or peer interaction, all code modifications should be reviewed to ensure quality and maintainability of code, as well as to address any potential performance implications that modifications may introduce.
If you're using a managed code repository provided by P1, we will set up continuous integration (automated testing) and review pull requests when submitted. Depending on your permission level, you may be able to perform code merges and deploy your website code without interaction from the P1 team. We'll outline that process in the second half of this guide and in the publishing guide next.
In order to begin the review process, you should have published your changes to your fork on a new branch. If you haven't yet done so, review the making a change guide for detailed instructions on that.
To submit your changes for review (and automated testing), click on the Create Pull Request button within the GitHub Desktop client, which will open the create pull request page in your browser:
You can also access this page directly on GitHub. To get there, first visit the upstream version of your code repository. You should notice a callout for your branch on the page, with a Compare & pull request button. Click the button to start your pull request.
The upstream version of your repository is the page that you forked your code from in the new developer guide. For P1-managed repositories, this is the main URL provided upon setup. For non-managed repositories, check with your repository administrator
In certain conditions, this callout may not automatically appear. You can access this page by visiting your fork, selecting your new branch, and clicking on the Pull Request button. When using this method, ensure that the "base repository" selected is your upstream! If the base repository field doesn't appear, click on the link that says compare across forks.
Once you've arrived at the pull request page, it's a good idea to review the modifications again to make sure you've included all the changes you meant to make (and haven't included any by accident!).
The modification history at the bottom of the page also gives you a quick look into what changes were made to help inform your pull request messaging.
Fill in the title and message of your pull request. Typically, the title should be a short (<110 character) summary of your changes, and the message should be as long as necessary to describe the modifications you made. Depending on your reviewers' preferences, you way want to include screenshots indicating the modifications, where applicable.
When you're satisfied with your message, click on Create Pull Request. If you're not quite ready for your modifications to be merged but you'd still like to share them, you can create your Pull Request in Draft mode via the dropdown.
Once you submit your PR, automated testing will begin, and any reviewers will be notified that your changes are ready.
Depending on your permission level, you may not have access to merge a pull request, but you can still leave a review!
To review a PR on a repository, click on the Pull requests tab, then select the PR from the list. Review the title/message, and the modifications by clicking on the Files changed tab. Once you've reviewed the changes, select the Review changes button and indicate whether you approve or deny the changes.
Depending on your permissions level, you may not have access to merge a pull request. For assistance with permissions, please reach out to your repository administrator/owner.
For P1-managed repositories, please reach out to support@parameter1.com to modify permissions!
To merge a PR on a repository, click on the Pull requests tab, then select the PR from the list. If required status checks have passed and peer reviews are complete (if required), the Merge button at the bottom of the page will be green.
Click the merge button, then select confirm to merge the changes:
Once the changes have been merged, you can then deploy them to your staging and/or production site.
If using a P1-managed repository, your changes will typically be deployed immediately by a P1 developer after merging your pull request.
