Pull Request: What is a Pull Request?

What is a Pull Request?

A pull request (often abbreviated PR, or "merge request" on GitLab) is a collaboration mechanism that allows a developer to signal that their changes are ready to be integrated into a target branch, usually the project's main branch. It is much more than a simple merge request: it is a space for discussion, code review, and quality assurance at the heart of the modern development workflow.

Concretely, a pull request creates a dedicated page on the hosting platform (GitHub, GitLab, Bitbucket) that displays the difference (the diff) between the source branch and the target branch. Team members can then examine each modified line of code, leave comments, suggest corrections, and approve or request changes before the code is merged.

At Kern-IT, pull requests are at the center of our development process. No code reaches the main branch without being reviewed and approved by at least one other developer. This practice ensures code quality and fosters knowledge sharing within the team.

Why Pull Requests Matter

Pull requests have transformed the way development teams work together. They bring structure and rigor to a process that would otherwise be chaotic and error-prone.

• Systematic code review: every change is examined by at least one peer before integration. This helps detect bugs, security vulnerabilities, or design issues that the code author may have missed.
• Living documentation: discussions in PRs constitute a valuable history. They explain why a particular technical decision was made, making the code easier to understand for future developers.
• CI/CD integration: pull requests automatically trigger test pipelines. Code can only be merged if all tests pass, ensuring that each integration does not break existing functionality.
• Access control: branch protection rules allow requiring a minimum number of approvals before merging, thus protecting critical branches.
• Knowledge transfer: code review is an excellent learning vehicle. Junior developers learn from senior feedback, and seniors discover new approaches proposed by the team.

How It Works

The lifecycle of a pull request follows a well-defined process. The developer starts by creating a topic branch from the main branch (git checkout -b feature/new-feature), makes their changes, commits them, and pushes them to the remote repository.

They then create the pull request on the platform, specifying a clear title, a detailed description of the changes, and ideally screenshots or testing instructions. On GitHub, PR templates allow standardizing these descriptions across the team.

Reviewers are notified and examine the code. They can leave general comments or comments tied to specific lines of code. The developer responds to comments, makes the requested corrections, and pushes new commits on the same branch, which automatically updates the PR.

Once all reviewers have approved and CI tests pass, the PR is ready to be merged. The developer or a maintainer clicks the "Merge" button, and the changes are integrated into the target branch. The source branch can then be deleted to keep the repository clean.

Merge Types in a Pull Request

GitHub offers three merge strategies for pull requests. "Merge commit" creates a merge commit that preserves the complete branch history. "Squash and merge" combines all branch commits into a single clean commit in the target branch, ideal for keeping a readable history. "Rebase and merge" replays the branch commits on top of the target branch, creating a linear history without merge commits.

The choice of strategy depends on team conventions. At Kern-IT, we favor squash and merge for feature branches, which produces a clean and easy-to-browse history.

Concrete Example

A Kern-IT developer needs to implement an email notification system for a client application. They create a branch feature/email-notifications, develop the feature over several days with about ten commits, then open a pull request.

The PR description explains the business context, the technical choices (using Celery for asynchronous sending, Django templates for email HTML), and includes screenshots of the rendered emails. A senior colleague reviews the code, notices a potential SQL injection in a filter, and leaves a comment. The developer fixes the vulnerability, pushes the fix, and the reviewer approves. CI tests pass, and the PR is squash-merged into main.

Best Practices

1. Keep PRs small and focused: a 200-line PR will be reviewed in depth; a 2000-line PR will barely be skimmed. Break large features into successive PRs.
2. Write a complete description: explain the context, technical choices, and how to test. The reviewer should not have to guess the intention behind the code.
3. Respond to comments quickly: a stagnating PR loses relevance. Address feedback within the day to maintain development flow.
4. Use labels and assignments: categorize your PRs (bug, feature, refactoring) and assign the right reviewers for efficient handling.
5. Automate with CI: configure automatic checks (tests, linting, coverage) that must pass before merging.

Conclusion

The pull request is much more than a technical tool: it is a cultural practice that promotes quality, collaboration, and continuous learning. By structuring the code integration process, it reduces production bugs, improves codebase consistency, and strengthens trust within the development team.