Pull Request (PR)
Definition
A pull request (PR) is the standard mechanism for proposing changes in a Git-based workflow. It encapsulates a set of commits, a human-readable diff, automated checks, and a discussion thread so the team can evaluate correctness, security, performance and product impact before merging into the target branch. Mature teams regard the PR as the source of truth for the 'why' and the 'how' of a change, from design rationale to the deployment and rollback plan.
Typical workflow
Start from an up-to-date base branch, create a feature branch, and commit in small, coherent increments. Push your branch, then open a PR with a clear, action-oriented title and a concise scope. Link relevant issues, add screenshots or videos, and note any migrations or visible impacts. Request the appropriate reviewers and code owners. CI runs automatically (formatting, linting, type checking, tests, build, security). Iterate until you have green checks and approvals, then merge using the appropriate strategy, clean up the branch, and publish release notes if necessary.
An effective review process
Reviewers focus on correctness, security, architectural fit, performance, readability, and test coverage. Prefer specific, constructive comments; distinguish blocking issues from minor details; offer concrete suggestions when appropriate. Authors clarify intent, respond promptly, and keep the PR synchronized with the base branch. Mark conversations as resolved once addressed; stale PRs should be rebased or closed to clean up the backlog.
Merge strategies and history
Three common approaches: Merge Commit (preserves history and context), Squash & Merge (a clean commit that captures the PR’s final state), and Rebase & Merge (ensures a linear history). Squash is often preferred for feature branches; merge commits are useful for collaborative efforts; rebase is ideal when a strictly linear history is required. Choose a strategy per repository and document exceptions.
CI checks and automation
Automate repeatable checks: formatting, linting, type checking, unit/integration/E2E tests, builds, preview environments, security scans (SAST/DAST), dependency and license checks, size budgets, and database migrations. Protect target branches with required checks and approval rules. Use bots to label, assign, update changelogs and, if desired, auto‑merge when all criteria are met.
PR Templates and Draft PRs
A PR template helps capture the 'why' and the 'how': the problem, the proposed solution, screenshots, test plan, migration notes, risks, deployment/rollback strategy, and links to the specification. Draft PRs are ideal for early feedback — mark them ready for review when the scope is stable.
Best practices
Prefer small, focused PRs (a few hundred lines of diff), descriptive titles and summaries, atomic commits, up-to-date tests and docs, and avoid mixing unrelated refactors. Use commit conventions (Conventional Commits) to keep the history scannable. In the description, emphasize the 'why' rather than repeating the diff.
Common pitfalls
Overly large PRs, merges without review, ignored tests, force-pushing during a review without context, unrelated changes included in the same PR, flaky checks masking regressions, missing migrations or rollbacks, and lack of consideration for performance or accessibility.
Security and compliance
Enable secret scanning, dependency updates, and code-scan alerts. Require approvals from code owners for sensitive areas and a second review if necessary. Sign commits when required, avoid logging sensitive data, and treat the PR as an audit artifact with traceable decisions and controls.
Working in a monorepo
In a monorepo, a PR can touch multiple packages. Limit the scope to a coherent change, run only the affected tests, and coordinate with the owners. Use changesets or a release tool to record versions and release notes. Keep cross-package refactors small, or split them into incremental PRs.
Metrics and Governance
Track lead time, review latency, time to merge, and change failure rate. Set service expectations for reviews, use protected branches, and adopt lightweight governance so that quality signals remain consistent without slowing teams down.
Related terms
Continue exploring with these definitions
CSS (Cascading Style Sheets)
CSS, short for Cascading Style Sheets, is one of the three technological pillars of modern web development alongside HTML and JavaScript. This style sheet language allows you to define the visual presentation of HTML and XML documents by separating content from its formatting. Introduced in 1996 by the World Wide Web Consortium, CSS revolutionizes web design by giving developers precise control over the appearance of web pages while maintaining a logical structure in the code.
Automation
Automation refers to the set of processes and technologies that enable mechanical, electronic, or computer systems to perform tasks without direct human intervention. This concept is based on the ability to design machines and algorithms capable of carrying out repetitive, complex, or hazardous operations autonomously, either by following predefined instructions or by adapting to their environment. Automation is not limited to the mere mechanization of processes, it also involves a dimension of intelligence and control that enables systems to make decisions, self-regulate, and optimize their performance according to variable parameters. This fundamental transformation now affects virtually every sector of human activity, from manufacturing to financial services, as well as healthcare, transportation, and agriculture.
CMS (Content Management System)
A CMS, an acronym for Content Management System (Système de Gestion de Contenu in French), refers to a software application that allows the creation, management, editing, and publishing of digital content without requiring in-depth technical programming knowledge. These platforms emerged in the late 1990s in response to a growing need to simplify web content publishing. Before their emergence, creating and updating websites consistently required developers who could work directly with HTML, CSS, and server-side programming languages. CMSs revolutionized this approach by separating content from its technical presentation, enabling editors, writers, and site managers to focus on the substance of their message rather than the technical aspects of delivering it.
Frequently Asked Questions
Have questions about the lexicon? We have the answers.
Leonard
Co-founder
Let's talk about your project
Our team of experts will respond promptly to understand your needs and recommend the best solution.