Pull Request
You might say
My changes are done. Have someone review them before they go into the main version.
Ask others to review and merge the work from one branchA pull request is a collaboration feature on Git hosting platforms, not a core Git command. It collects the change summary, discussion, automated checks, and review before a branch is merged. Keep its scope focused and explain how the result was verified.
You can say this to an AI Agent
Checks pass, but a mobile button is clipped. Fix it on the same branch, recheck mobile and desktop, and update the pull request summary and verification. Confirm the latest diff contains only this feature before requesting review, and do not bypass the PR by editing main.
When to use it
- Request code reviewfeat/dark-mode was pushed to the remotefeat/dark-modeCompare & pull request
- Discuss a proposed changefeat: add dark mode to the home pageWhat changed: dark-mode support for navigation and cards
How to verify: toggle the switch in the upper-right corner - Run checks before mergingSquash and merge ▾Create a merge commitSquash and mergeRebase and mergeSquash 7 intermediate commits into 1 main-branch commit
- Keep a record of why a branch entered mainMerged#12 feat: dark modeMerged#11 fix: mobile navigation wrappingPersonal projects can keep documented change records too
When NOT to use it
- Open one request for several unrelated features$ git pull-requestgit: 'pull-request' is not a git command.A PR is a GitHub web feature, not a command
- Use only the title and provide no contextOpenupdate #14The title and description are too vague to understand the scope
- Merge while required checks or questions remain unresolvedFiles changed 37+2,140 −867One PR contains three features, making the review scope too large
- Treat review as permission to skip your own testingCommit message:
● wip
● Adjust implementation
● Fix styles
● Finish changesHistory was not organized by project convention, making later tracing harder
Anatomy
● Openfeat: Home page with dark mode #12
Alex Chen wants to merge feat/dark-mode into main
ConversationCommits 3Checks ✓Files changed 2
✓ No conflict, can be automatically mergedSquash and merge ▾
Explain in one sentence what was changed; #12 is the number of this application form
From which branch to merge into which branch: feat/dark-mode → main
Conversation discussion, Commits save point, Files changed line by line changes
Click after passing inspection, testing and approval; the method of merging follows the project agreement.
Variants
Squash
3 commits → Organized into 1 entry into main
When you need to organize a set of intermediate commits into a complete change
Merge Commit
Keep each commit as is + merge nodes
Used when complete process records need to be kept
Rebase
Commits are queued and received at the end of main
The history is a straight line with no merge nodes.
Typical use cases
Feature review
Bug-fix review
Design discussion
Release change
Pull request vs merge request: is there a difference?
They name the same general review-before-merge workflow. GitHub, Bitbucket, and Azure DevOps use Pull Request (PR); GitLab uses Merge Request (MR). Product features still differ.
| Decision point | Pull Request (PR) | Merge Request (MR) |
|---|---|---|
| Core concept | A proposal to review branch changes and discuss code diffs before merging into a target branch. | GitLab's term for proposing, reviewing, and merging changes into a target branch. |
| Primary platform | Standard terminology on GitHub, Bitbucket, and Azure DevOps. | Standard terminology on GitLab and GitLab CE/EE. |
| Product details | Review rules, checks, and merge options depend on the hosting product and repository settings. | Review rules, pipelines, and merge options depend on GitLab's edition and project settings. |
Recommended tool
Web fine-tuning tool · Selector Pro
Select page elements for precise AI edits
Click a button, text, or card, note the change, then copy its exact location to AI.
Open Selector Pro website↗Further reading
Quick check