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
Lead Scoring
Lead Scoring is a methodology that assigns a numerical value to each prospect based on predefined criteria, enabling Sales and Marketing teams to prioritize their efforts on the leads most likely to convert. This approach combines demographic data (who the prospect is) and behavioral data (what they do) to create a score reflecting the likelihood of conversion and the lead’s potential value. Lead scoring turns intuition into science, aligning Sales and Marketing around an objective definition of lead quality.
ABM (Account-Based Marketing)
Account-Based Marketing (ABM), or account-based marketing, is a B2B strategy that focuses marketing and sales efforts on a targeted set of high-value accounts rather than on a broad audience. This approach flips the traditional funnel by first identifying the ideal target companies and then creating personalized campaigns specifically designed to engage the key decision-makers within those organizations. ABM tightly aligns Marketing and Sales teams around shared goals of penetrating strategic accounts.
Cookie
Cookies, also known in French as “témoins de connexion”, are small text files stored on a user's computer or mobile device when they visit a website. These files are created and placed by the visited website's web server and are then kept locally in a dedicated area of the web browser. Contrary to a common misconception, cookies are not executable programs and therefore cannot contain viruses or malware. They are simply structured text data that allow the website to recognize the user on subsequent visits and to personalize their browsing experience.
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.