A pull request (PR) is a feature provided by version control systems, such as Git, that enables developers to propose changes to a codebase. It serves as a mechanism for collaboration and code review within a development team or an open-source project.

When working with a version control system, such as Git, developers typically create a separate branch to work on a specific feature or bug fix. Once the changes are complete, the developer creates a pull request to merge their branch into the main codebase (usually the master or main branch).

The pull request contains a set of changes or commits that the developer wants to add to the main codebase. It includes details such as the branch being merged, the proposed changes, and a description of the purpose and scope of the changes.

Once a pull request is created, it can undergo a code review process. Other developers on the team or project can review the proposed changes, leave comments, suggest improvements, and discuss any concerns or questions they may have. The code review process helps ensure the quality and correctness of the code before it is merged.

After the code review, the pull request can be either approved and merged into the main branch, or further changes may be requested. Pull requests provide a transparent and collaborative workflow, enabling multiple team members to contribute to the codebase and maintain a high standard of code qualityFundamentally a Pull Request is simply a request for another dev to review work before committing it to a code repository and publishing it. At Kalamuna, the process involves the original developer(s) who worked on the task (the author); another developer who reviews the task for quality and completeness; and ideally a Project Manager to provide a Quality Assurance check. These steps are necessary to ensure that Kalamuna continues to provide high-quality, version-controlled code that follows our best practices.

PR Process

1. Dev completes work on a Jira ticket and assigns it to a reviewer in JIRA

2. Dev creates Pull Request for the reviewer in GitHub following best practices below

3. Reviewer pulls the branch locally, tests per the ticket guidelines, and verifies it works as expected

4. Reviewer adds notes to the ticket on how to QA it (links to relevant pages on dev where the change appears, how to check to see if it’s working, etc)

5. Reviewer assigns ticket to PM for QA review

6. PM reviews the outcome to ensure it accomplishes the client’s goals

   1. If approved, PM contacts the client for approval or updates

   2. If not approved, PM documents the issue(s) and reassigns to the reviewer

7. Once client approval is received, code is merged to the main branch and deployed

...