• 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.

• 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.