Introduction

A pull request is a request to merge changes from one branch into another branch in a GitHub repository. It gives a team a shared place to inspect the proposed changes, discuss implementation details, run automated checks, and decide whether the work is ready to merge. A pull request does not automatically change the target branch. The changes remain separate until someone with the required permission merges them.

A typical workflow starts when a contributor creates a feature branch from an up-to-date base branch, such as main. The contributor edits files, commits the work, pushes the branch to GitHub, and opens a pull request. Other contributors then review the difference between the feature branch and the base branch. This process makes collaboration safer because review happens before the shared branch receives the new code.

The branch names and permissions depend on the repository. In a small personal repository, one person may create, review, and merge the request. In a team repository, contributors may be required to use pull requests, pass continuous integration checks, and receive approval from designated reviewers before merging.

Prepare the Contribution

Before opening a pull request, start with a branch that has a focused purpose. A branch such as fix-login-timeout communicates more than a generic branch such as changes. First update the local base branch, then create the feature branch from it. The following commands illustrate the local part of this workflow.

git switch main
git pull origin main
git switch -c fix-login-timeout

The input is the branch name and the remote name origin. The expected result is that Git switches to main, downloads and integrates the latest commits from origin/main, and creates a new branch named fix-login-timeout. If Git reports that local changes would be overwritten, inspect the working tree with git status. Commit, stash, or otherwise handle those changes before switching branches. Do not ignore this error, because it protects uncommitted work.

After editing and testing the files, inspect the exact changes before committing. A focused commit makes the pull request easier to understand and easier to correct later. Then push the branch and set its upstream tracking branch so later pushes can use the shorter command.

git status
git diff
git add path/to/changed-file
git commit -m "Fix login timeout handling"
git push -u origin fix-login-timeout

The push command creates or updates the remote branch. A common error is pushing to the wrong branch, especially when a contributor is still on main. Running git branch --show-current before committing or pushing confirms the current branch. Another frequent error is an empty commit attempt. Git reports that there is nothing to commit when the files have not changed or the changes were already committed; inspect git status and git log before taking further action.

Open a Clear Pull Request

After the branch is pushed, GitHub usually displays an option to open a pull request for the recently pushed branch. Choose the correct base repository and base branch, then choose the feature branch as the compare branch. The direction matters: the feature branch should provide the changes, while the base branch should receive them. Check the displayed file and commit differences before creating the request.

Use a title that describes the outcome rather than the activity. Fix login timeout handling is more useful than Update code. In the description, explain the problem, the change made, and the expected behavior after merging. Include relevant context such as an issue reference, design decision, migration note, or limitation. A reviewer should be able to understand why the change exists without reconstructing the entire conversation.

The description should also state how the change was tested. For example, explain which command was run, which manual scenario was checked, or why a particular test could not be run. If the repository uses a pull request template, complete every relevant section instead of deleting the template. A useful request is specific about scope: it tells reviewers what to inspect and identifies changes that are intentionally outside the request.

A pull request can be opened as a draft when the work is not ready for final review. Draft status signals that the author wants early discussion but does not yet claim the change is complete. Convert it to ready for review only after the implementation, description, and basic checks are prepared. Keep the request focused. Combining an authentication fix, a formatting rewrite, and an unrelated dependency update makes review slower and increases the chance that an important defect is missed.

Review Contributions

A reviewer should read the description first, then inspect the changed files and the surrounding code. The goal is not merely to confirm that the code looks familiar. The reviewer should ask whether the change solves the stated problem, preserves existing behavior, handles relevant failure cases, and includes adequate tests. The commit list and the complete diff can provide different kinds of context, so use both when the history is meaningful.

Review comments should identify a concrete concern and explain its impact. A comment such as This is wrong does not tell the author what behavior is expected. A more useful comment identifies the input or scenario that fails, explains why the current result is unsafe or confusing, and suggests a direction when appropriate. Keep style preferences separate from correctness issues, and use the repository's conventions when deciding whether a comment is necessary.

GitHub supports comments on specific lines as well as general pull request comments. A line comment should refer to code that is visible in the proposed diff and should remain understandable when read by itself. Reviewers may submit an approval, request changes, or leave comments without a formal approval. Automated checks may also report test failures, lint errors, security findings, or other repository-defined conditions. Passing checks are useful evidence, but they do not replace human review of requirements and maintainability.

Reviewers should distinguish blocking feedback from optional suggestions. If a problem can cause data loss, incorrect behavior, a failing build, or a security issue, explain that it must be addressed before merge. For a non-blocking improvement, make the status clear so the author can prioritize correctly. The final decision should follow repository rules, including required approvals and branch protection settings.

Respond to Feedback

The author should treat review as a technical discussion about the proposed change, not as a replacement for ownership of the work. Read every comment, ask for clarification when the expected behavior is unclear, and respond when a concern has been addressed. A short reply such as Updated in commit abc123 is useful when it points the reviewer to the relevant change. If the author disagrees, explain the requirement or tradeoff with evidence and invite a decision based on the project context.

When changes are requested, make the edits on the same feature branch. Commit the new work and push it to the same remote branch. GitHub automatically updates the open pull request with the new commits, so a second pull request is usually unnecessary.

git add path/to/changed-file
git commit -m "Handle reviewer feedback on timeout errors"
git push

The input is the revised file and a commit message; the output is a new commit on the branch already connected to the pull request. If git push reports that the branch has no upstream, repeat the original push with -u and the remote branch name. If the remote branch contains commits that are missing locally, fetch the latest state and integrate it according to the repository policy. Do not force-push casually, because rewriting a shared review branch can remove commits or invalidate review context.

After pushing, recheck the diff, test results, and unresolved conversations. A reviewer may ask for changes in one comment while another check fails for an unrelated reason. Address each issue explicitly, and avoid marking a discussion resolved unless the underlying concern is actually handled. Once the required changes are complete, request another review if the platform or team process expects it.

Merge and Follow Up

A pull request is ready to merge when the implementation is complete, the relevant checks pass, required reviewers approve it, and no blocking discussion remains. The available merge method depends on repository policy. A merge commit preserves the branch history, squash merging combines the request into one commit, and rebase merging applies the commits without creating a merge commit. Choose the method required by the project rather than treating one method as universally correct.

Before merging, confirm the base branch one final time. Merging into the wrong branch can release unfinished work or bypass the intended release process. If the pull request reports merge conflicts, update the feature branch with the latest base branch and resolve the conflicts carefully. Read each conflict in context, run the relevant tests, and push the resolution. Never accept conflict markers such as <<<<<<< or >>>>>>> as valid source content.

After a successful merge, the feature branch may be deleted according to the team's cleanup policy. The local repository can then be synchronized with the updated base branch. If the request changes documentation, configuration, database behavior, or deployment steps, complete the associated follow-up work rather than assuming that merging code finishes the entire task.

The essential habit is to keep the request understandable from beginning to end. A focused branch, a precise description, evidence from testing, specific review comments, and explicit responses create a reliable record of the decision. Pull requests are therefore both a delivery mechanism and a durable communication tool for the project.