Push Pull Request Guidelines - PelletierConstructionGroup/pelletier-construction-group-nextjs GitHub Wiki
- Large pull requests take more time to review, result in less effective reviews and slow down development.
- The team should decide how to limit length (lines of code, files changed, scope). TBD.
- Ask TPM or PM to break down large issues as needed; we are all more than happy to!
- Make sure the project is working whenever you make a commit (CI/CD will be a judge of this).
- Each commit should have a descriptive commit message.
- Each commit should do one thing.
Example of these two previous points from this Medium article:.
- Let's say you're developing a page that displays a list of articles that comes from an API.
- Creating multiples commits can look like:
- Create articles page component
- Create service to get articles from API
- Create article card component with style
- Add components and service tests
Our naming convention for PR titles:
< repo > _ < sprint > _ < issue > _ < pr or issue name >
Example:
PelletierConstructionGroup.github.io_2_5_landing-page
This would be for the PelletierConstructionGroup.github.io repo, sprint 2, issue 5, with the name "landing page."
- We are utilizing pull request templates in this project for the sake of uniformity and efficiency. Please fill in all appropriate fields and complete all tasks prompted by the template.
-
Please make sure to include which issue is resolved by the PR and use the format “Resolves <>” → Resolves #5
- This will automatically status the issue as complete. Read more about linking issues to pull requests here.
- This is already in the template but is especially helpful to include.
- Some other useful things to consider when creating your description:
- What is the feature?
- How did you implement the solution?
- What other areas of the project does it impact (if applicable)?
- Changes in the UI? Screenshots if applicable (before and after is helpful).
- Screenshots of mockup if applicable.
- How to test the feature.