Skip to content

Pull Requests

In order to manage the code quality of contributions in remote (public) repositories, such as on GitHub, GitLab or Azure DevOps, not everybody is simply allowed to push and merge changes in whatever branch they see fit to. This is where a PR (pull request) comes in.

In their most basic form, pull requests are a mechanism for the developer to notify co-developers that they have completed a contribution, and they would like to have it integrated in the (public) remote repository. Once their contribution is ready, the developer creates a pull request, which notifies the repository's maintainer there is a contribution ready for review. The repository's maintainer can then review the code, ask questions, suggest changes, and/or allow for the changes to be merged.

However, a pull request is more than this. It also provides a space to discuss the feature, or any issues with it, at length. Furthermore, the changes made within the pull request can even be altered and improved upon by follow-up commits, within the pull request itself, before allowing it to be merged into the repository.

Note

The Git CLI does have the git request-pull command. Generally, pull requests are created from within the service where the remote repository is hosted, for instance on GitHub. This provides a lot more flexibility.

There are many options for creating pull requests on such platforms, without interfacing with the website (i.e. from your CLI or IDE), however that is beyond the scope of this document.

Protected main branches

Often, public repositories have a protected main branch, or multiple protected branches. This ensures the main branch can never be directly committed in, or pushed to. Trying to do so, will yield an error. This is done to ensure a bug-free and stable release branch.

The only way to get your changes incorporated into these protected branch is via a pull request.