This project makes use of the Gitflow workflow.
productions- The master branch is for code ready to be released to the production environment.preview- The staging branch is for new, larger feature or changes introduced by one or more PR's that needs ongoing, external review atpreview.theworld.org. If more than one major project is in progress, new "preview" domains and branches will need to be made for those projects.{feat|fix|docs}/{issue-number}--{short-description}- Work branches for issue specific work. Bug fixes and minor new features branch offmasterand PR's merge back intomaster. Issues related to larger feature projects should branch of ofpreview(or the develop branch created for that project) and merge back into that branch.
Pull requests should be named with the GitHub Issue Number (if applicable) plus a brief description. Example:
{ticket-number}: {short description}
The description should start with closing keyword and issue id to link PR to the issues being addressed.
Closes #1234
Also include a brief description of what the pull request is doing if it is more involved than what can be adequately communicated in the title.
Lastly, include complete steps to functionally test the pull request.
You will be presented with a template containing these main components when you create a new PR. Some default intialization steps will be included. Append your review steps to those.
If the PR is for work still in progress, save it as a Draft Pull Request.
All pull requests need to go through a review process. When your pull request is ready to be reviewed:
- Select at least one Reviewer.
- Set your self as the Assignee.
- For Draft PR, Click Ready for review.
Reviewer will then review PR and provide feedback. Address any feedback as it comes in, discussing the issues in the comments of the PR. Once the reviewer approves chnages, make sure all checks a greenare green, then merge the PR. If the PR can not be merged to master, use GitHub to merge master into the work branch and resolve conflicts.
- Generally, pull requests should resolve a single GitHub issue. Try to avoid combining multiple issues into a single pull request. There may be instances where it makes sense to do otherwise but please use discretion.
- Try to keep pull requests reasonably small and discrete. Following the one pull request per issue paradigm should accomplish this by default. However, if you are beginning to work on an issue and it feels like it will result in a giant pull request with lots of custom code, changes across many features, and lots of testing scenarios, think about how you might break down the issue into smaller subtasks that could be incrementally developed and tested. Convert the issue into an epic, then create new issues for the subtasks, assigning the issue to that epic.
Coding standards will be rigorously enforced on this project. Please save everybody time by checking for common syntax errors in your custom code and fixing them before you send your pull request into review. This project has few yarn scripts that, when run, will analyze the codebase and produce a report of all coding standards violations that should be corrected. These scripts will be executed prior to a commit being formed to ensure code committed to the project is correctly formed.
There are scripts included in this project to help check your custom code for common errors. From within the project you can run:
yarn lintto lint all of your custom code.yarn format:checkto automatically format your code.
This project makes use of the Commitizen commit convention, which is documented explicity in Angular's contribution docs. A simple commit validation precommit hook is in place to help facilitate the adoption of this convention.