Draft and Regular PRs
Pull Requests (PRs) are how we propose changes, review each other's work, and merge code into the main project.
In our workflow, you must create a Draft Pull Request (DPR) immediately after creating your branch.
A DPR gives visibility to your work, allows peers to support you, and prevents last-minute surprises during review.
- They show your in-progress work early.
- Teammates can help if you're blocked or unsure.
- It reduces merge conflicts by allowing early feedback.
- It signals transparency and collaboration.
- The PR template guides your work from the beginning.
You must make at least one commit before opening a DPR.
Even an empty placeholder commit is fine (e.g., adding a comment or README note).
(Adapted from the NSC Events project standards; unified for practicum use.)
Large pull requests slow down development and lead to poor-quality reviews.
- Smaller PRs = faster reviews, fewer conflicts.
- Large PRs hide mistakes and increase the complexity of review.
- If your issue feels too large, ask the TPM or PM to break it down.
- The project must remain functional at every commit (our CI/CD pipeline will check this).
- Each commit should be focused and descriptive.
- Avoid bundling multiple unrelated changes into one commit.
Example commit breakdown (from 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 fetch articles from API
- Create article card component + styling
- Add tests for components and service
This makes it easy to review, debug, and track changes.
Use this structure to keep titles organized:
_
nsc-events-android_2_5_landing-page
This indicates:
- Repository:
nsc-events-android - Sprint: 2
- Issue: 5
- Name: landing page
We use PR templates for consistency.
Please fill out all required sections.
- Clear description of what was built
- “Resolves ”
- Example:
Resolves #5 - This automatically closes the issue when merged
- Example:
- Testing instructions
- Screenshots if UI changed
- Mockups if available
- Explanation of how the solution works
- Notes on what parts of the project it affects
Linking issues to pull requests:
https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
From GitHub (Web UI):
- Navigate to the main page of the repository.
- In the Branch dropdown, select the branch with your commits.
- Click Compare & pull request.
- Confirm the base branch (usually
developormain) and compare branch (your feature branch). - Add your PR title and fill out the template.
- To create a regular pull request, click Create Pull Request.
- To create a Draft Pull Request, open the dropdown and select Create Draft Pull Request.
GitHub reference:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request
GitHub’s announcement explaining draft PRs:
https://github.blog/2019-02-14-introducing-draft-pull-requests/
- Open your Draft PR right after creating your branch.
- Keep PRs small and focused.
- Respond to review comments promptly and professionally.
- Use screenshots when making UI changes.
- Regularly pull latest
develop/maininto your feature branch.
| Mistake | Why It Matters |
|---|---|
| Creating PRs without linking an issue | Breaks traceability and auto-closing |
| Large PRs with many changes | Hard to review, increases risk |
| Vague PR descriptions | Slows review and causes confusion |
| Forgetting to switch DPR → PR when complete | Your work will not be reviewed |
| Not running the project before submitting | CI/CD failures delay review |
➡️ Proceed to: Commit Messages