A branch becomes a proposal. Check the destination, explain the change and review the diff.
A pull request is a conversation about a change
A pull request proposes merging one branch into another on GitHub. It shows commits, a diff, checks and discussion. It is not the same operation as git pull, and opening it does not automatically merge or deploy anything.
Base receives. Head supplies.
Base: main
The branch you want to update.
Head: feature/greeting
The branch containing your proposed changes.
Repository
Check the owner too. A fork can have the same branch names in a different repository.
Build the proposal
Commit and test the change on a branch.
Push that branch to a repository where you have access, or to your fork.
Open GitHub's Pull requests page and choose New pull request.
Check the base repository and branch, then the head repository and compare branch.
Read the entire diff. Remove accidental files or secrets before publishing.
Write a clear title, explain what changed and how you tested it. Use a draft when work is not ready.
This is a documentation-based walkthrough, not screenshots of a live repository. Exact button placement can change.
Try a useful PR description
Your private practice draft appears here. Nothing is sent.
Review is more than a green button
Check correctness, unintended files, tests, accessibility and the destination. Respond to feedback with commits on the same head branch; the PR updates. Passing automated checks is evidence, not proof that the change is right.
Merge only when the repository's review and branch rules allow it. Merge commit, squash and rebase merge preserve history differently. Do not pick a method just because a button is visible. Deployment behavior belongs to that repository's configuration.
If you cannot open or merge it
Check access, whether the branches actually differ, and repository rules. A contributor may be allowed to propose work but not merge it. Ask a maintainer rather than bypassing protected-branch rules.