Pull Requests

The diplomatic way to sneak your changes into main.

Just in case you forgot: Rebasing onto main before continuing work is the secret to happiness.

Always Simple Rebase

Always simple rebase your branch onto main before creating a pull request. This ensures that your branch is up-to-date with the latest changes in the main branch. Branch and PR rules are set up for the repo just in case as a guardrail.

Do your best to close a single issue per pull request, and always use the same PR title as the issue name. This makes debugging easier later. If the current issue is blocking the next, simply create a new branch off the branch for the pull request and continue working on the next issue on that branch. This technique is called branch stacking. With the power of git rebase, you can continually apply PR feedback for the first branch while making progress for the next task on the second branch. Once again, Lazygit makes this quick and easy to do cleanly.

Pull Request Guidelines

When creating a Pull Request (PR), be mindful about what you're trying to contribute and the type of contribution:

Be sure to checkout Branching Guidelines, Coding Guidelines and Commit Conventions before making a PR.
Use the appropriate template that matches with your branch type.
Ensure your PR scope and subject align with your main commit(s).
If your code isn’t fully ready to be merged, consider creating a draft PR instead.
Be sure to link your PR branches with the according issue (if applicable).
Make sure your PR description is solution-specific (describes only the solution since the issue describes the problem at hand already).

If you're getting tired of storing work in progress by stashing changes or amending commits and then switching branches, it's a great sign to look into using Git Worktrees.

Here is an example of a well-documented PR: Pull Request #60

Here are a few PR templates to get you started: GitHub PR Templates

You can create pull requests (PRs) that address multiple issues, but to avoid overwhelming reviewers, it may be better to break them down into smaller, more focused PRs that tackle one issue at a time. This would save a lot of overhead and would make the documentation process easier.

If you find that your issue blows up and splitting it into multiple issues doesn't make sense, you can always keep the issue open and make multiple PRs that complete it in increments, as shown in Issue #40.

Below is also a checklist to ensure your PR is ready for review.

Pull Request Checklist

Code Quality

Done	Checklist Item
	Code is clean and readable (functions used appropriately)
	Code is commented appropriately (no unnecessary comments, follows guidelines)
	Code is DRY (no repeated code)
	Functions are named appropriately (camelCase)
	Variables are named appropriately (camelCase)
	Files are named appropriately (kebab-case)
	Code performs as expected (no errors or issues when running)
	Code is committed and branched accordingly

PR Review Readiness

Done	Checklist Item
	PR is linked to an issue (if applicable)
	PR is clear and comprehensible
	PR is ready for review (if not, consider using a draft PR)
	PR title follows template guidelines
	PR description follows template guidelines

What is a CODEOWNER?

In our project, CODEOWNERS are typically subject matter experts for specific areas of the codebase. When you submit a pull request, the relevant CODEOWNERS will be automatically notified and requested to review your changes. See our CODEOWNERS file below for more info on who in our team has ownership.

CODEOWNERS

#========== DEPENDENCIES ==========
*package*        @MFarabi619
 
#=========== APPS ==========
/apps/*             @MFarabi619
/apps/docs/         @JeremyFriesenGitHub
 
#========== CONFIGURATIONS ==========
*config*            @MFarabi619
*build*             @MFarabi619
/.github/           @MFarabi619
/.husky/            @MFarabi619
/.vscode/           @MFarabi619
/.cz.json           @MFarabi619
/nx.json            @MFarabi619
/.editorconfig      @MFarabi619
 
#========== LIBRARIES ==========
/libs/utils/        @MFarabi619
/libs/ui/           @MFarabi619
/libs/api           @MFarabi619
/libs/env           @MFarabi619
/libs/db            @MFarabi619 @JeremyFriesenGitHub

For more information, you can check out GitHub's CODEOWNERS documentation.