Jan Mikoláš
Glossary
Pull request
A pull request does not mean the git pull command. It is a workspace for proposing, reviewing, and deliberately merging a change into a target branch; nothing necessarily deploys after merge.
Short definition
A change proposal that gets context, review, and a decision.
A pull request is a GitHub feature. GitLab uses the term merge request for the same principle. The author compares a source branch with a target branch, adds a description, and requests code review. One place then shows changed files, commits, comments, approvals, requested changes, and check results.
Git is a distributed version-control system. A commit is a local history record, a branch is a reference into history, and push sends a branch to a remote repository. A pull request is not part of the Git protocol or a synonym for any of these steps; it is a collaboration object that a hosting service creates around Git history.
The git pull command usually fetches changes from a remote and integrates them into a local branch according to configuration. A pull request, in contrast, does not pull anything into a working directory. Merge accepts a proposal into a target branch using a chosen integration method. Deployment is then a separate operational step that a pipeline may trigger after merge, but it might not happen at all.
What it is for
One place for a change, its context, and its verification
A well-prepared pull request shortens review time and gives a team the material needed to decide on a safe merge.
- comparing a change with the target branch through a readable diff
- describing the problem, solution, tests, limits, and expected impact
- requesting review from people who understand the system area or business rule
- running CI, tests, static analysis, and possibly security checks against a particular change
- tracing comments, decisions, and links to an issue, incident, or release
- protecting the main branch with required approvals and merge checks
Practical example
A small pull request for a shipping-price change
The author creates a feature/free-shipping-threshold branch, adds several commits, and opens a pull request against main. Its description does not only say “shipping changed”; it gives the new rule, who it applies to, which orders are exceptions, which tests ran, and whether administration or a public API changes.
In the diff, the reviewer checks that shipping is not calculated twice, that the change does not bypass currency or a discount voucher, and that a test covers the exact threshold. After green CI and resolved comments, they can approve. Merge joins the change into main; only project workflow then decides whether a release is created and where an artefact is deployed.
Text
Title: Free shipping from CZK 1,500
Problem: Shipping should be free for orders of CZK 1,500 and above.
Solution: The rule belongs in ShippingPriceCalculator, not the checkout controller.
Verification: Unit tests below, at, and above the threshold; manual checkout in CZK.
Risk: Does not apply to oversized shipping. No database migration in this release.Typical flow
From branch to merge, not automatically all the way to production
Text diagram: branch and commits → pull request → diff, description, and CI → review → approval or requested changes → merge → separate release or deployment.
- Source and target branch The author proposes merging a specific source branch into, for example, main. The system calculates a diff against the selected target branch.
- Description and context The pull request states why the change exists, how it was verified, what is not included, and whether it affects data, security, or release.
- Automated checks CI attaches test, build, and static analysis results to a specific commit or simulated merge result.
- Review and decision A reviewer provides a comment, approval, or requested changes. The repository rule, not the pull-request name itself, determines required approvals and blocking checks.
- Merge and the next lifecycle Merge creates or updates the target-branch history. Release, database migration, deployment, smoke test, and monitoring are separate later steps.
Important parts
A pull request holds code, context, and merge rules together.
A platform shows much information at once. Its purpose is to help a team make a better decision, not to fill a form.
Diff and commits
A diff shows the difference between source and target branches. A commit is one Git history record; a pull request can contain several commits and is not a copy of them.
Author and reviewer
The author provides context and responds to feedback. The reviewer checks the proposal and diff; merge permission, required reviews, and code owners are rules of a particular repository.
Comment, approval, and requested changes
A comment need not block merge. Approval confirms readiness in a particular review scope. Requested changes highlights work before the next approval; whether it technically blocks merge depends on platform settings.
Draft and ready for review
A draft shares work in progress without requesting a final decision. Only after the author completes the description, stabilises the diff, and finishes basic verification should the change be marked ready for review.
Checks are not review
Tests and PHPStan can block a known mistake. They do not automatically assess a product trade-off, unclear request, unsuitable class responsibility, or customer-process impact.
Merge is not deployment
Merge integrates a change in Git history. Deployment transfers an artefact to a particular environment and needs its own rules, secrets, migrations, and verification. Push and merge alone are not a release.
Benefits and limits
Collaboration around a change at the cost of discipline and waiting for decisions.
Benefits
- a transparent diff and reason for a change before integration
- review, automated checks, and a decision connected in one record
- protection of the main branch from accidental merges
- easier tracing of why a particular contract or rule changed
Common mistakes
- confusing a pull request with git pull, a commit, or a branch itself
- opening a large pull request with no description and expecting a reviewer to infer product context
- treating merge as automatic production deployment
- approving a green CI result without reading the diff and risky scenario
- mixing a feature, refactoring, formatting, and dependency update in one proposal without explanation
When it fits
For changes that should be understandable and safely integrated.
A pull request works for team development and for an individual who wants traceable context and automated checks before merge. Match process scope to risk: a payment, permission, price, or database-migration change needs more explanation and more experienced review than a small text correction.
It does not replace a design decision for a broad problem or a release plan. If a team does not agree on a rule or system boundary, clarify it before writing hundreds of diff lines. The pull request then captures the concrete implementation of that decision.
Practical rules
A pull request should save reviewer time, not transfer work to them.
An author can greatly improve review quality before the first comment.
- write the title and description as problem, solution, verification, limits, and risk, not only as a technical task
- keep the diff cohesive; submit formatting, dependencies, or mechanical refactoring separately
- before requesting review, inspect your own diff and finish local and required automated checks
- choose a reviewer by domain, security, database, or integration knowledge, not only availability
- after an important change, answer the comment, resolve the thread under team rules, and request another review
- before merge, check required approvals, check state, conflicts, release notes, and compatibility impact
Frequently asked questions
Pull requests without common mix-ups
Is a pull request the same as git pull?
No. git pull is a local Git command to obtain and usually integrate changes from a remote. A pull request is a merge proposal and collaboration space in a service around a Git repository.
Is a pull request a commit or branch?
No. A commit is a Git history record and a branch is a reference into history. A pull request usually compares source and target branches and can contain several commits, comments, and checks.
Is merge automatic deployment?
No. Merge integrates a change into a target Git branch. Deployment is a separate process; automation may start it, it may wait for approval, or it may not start at all.
Is green CI sufficient reason to merge?
No. CI only confirms the automated checks that ran. A team still needs review of intent, security and business impact, required approvals, and release readiness.
When should I use a draft pull request?
When an author wants to share work direction early or get informal feedback, but the change is not yet ready for final review and merge.
How I work with quality
I use a pull request to connect a change, review, and deliberate release.
For maintainable development, I connect small diffs, CI, tests, review, and clear rules for integrating changes into the main branch.