Pull request and merge

A pull request proposes integrating one Git history into another and gathers the diff, discussion, checks, and policy decisions for that integration. Merge records the accepted histories together.

Hosted Git platforms use pull requests, or merge requests, to compare a source branch with a target branch and collect automated checks, reviews, and change history before integration. The merge can create a merge commit, squash commits, or rebase them depending on repository policy. Opening a request does not merge the histories, but it may trigger preview deployments and automation, so it is not necessarily free of external effects.

Builder example

A pull request is an integration control surface, not proof that a change is correct. Path rules can reject unrelated billing edits, tests can exercise behavior, security scanners can inspect dependencies, and specialists can review ambiguous high-risk logic. Some one-person repositories intentionally commit directly to main; others require pull requests. Follow the repository's delivery contract rather than imposing this workflow on every AI-generated change.

Common confusion: The branch holds commits, the pull request evaluates a proposed integration, and merge changes the target history. Deployment is separate: a host may build pull-request previews, deploy after merge, or follow another rule entirely.