Introduction

A pull request from a fork is updated by pushing more commits to the same branch that the pull request already uses. You do not create a second pull request for every revision. The main tasks are making the new local changes, keeping your forked branch in sync with the upstream project when needed, and then pushing back to your fork so the existing pull request refreshes automatically.

The Basic Rule: Push to the Same Branch

When you open a pull request from your-fork:feature-branch into upstream:main, the pull request tracks that source branch. Any new commits pushed to feature-branch in your fork appear in the same pull request.

Typical update flow:

1git checkout feature-branch
2git add .
3git commit -m "Address review comments"
4git push origin feature-branch

Once the push completes, the hosting platform updates the pull request automatically.

Make Sure origin and upstream Are Set Correctly

In fork workflows, origin is usually your fork and upstream is the original repository.

Check your remotes:

git remote -v

If upstream is missing, add it:

git remote add upstream https://github.com/original-owner/project.git

This matters because review updates often require pulling recent changes from the original project before you push your next revision.

Sync Your Branch with the Upstream Base

If the upstream project moved forward and your pull request branch is now behind, update your local branch before pushing. There are two common approaches: merge or rebase.

Merge approach:

1git fetch upstream
2git checkout feature-branch
3git merge upstream/main
4git push origin feature-branch

Rebase approach:

1git fetch upstream
2git checkout feature-branch
3git rebase upstream/main
4git push --force-with-lease origin feature-branch

Merge preserves the existing history structure. Rebase creates a cleaner linear history, but because it rewrites commits you usually need --force-with-lease when pushing afterward.

Know When Force Push Is Acceptable

If you only added new commits, use a normal push. If you rebased or amended commits, the branch history changed and a normal push may be rejected.

Safer force push:

git push --force-with-lease origin feature-branch

--force-with-lease is better than plain --force because it refuses to overwrite remote history that you have not seen locally. In collaborative branches, that extra safety matters.

Respond to Review Feedback Cleanly

There are two common review-update styles:

• add follow-up commits such as "Fix review feedback"
• clean up history with rebase and squash before final merge

Which one is better depends on the team. During active review, small follow-up commits are often fine because they make progress visible. Before merge, maintainers may prefer a cleaner history. The important point is to match the project’s contribution style rather than treating every pull request the same way.

Keep the Pull Request Discussion in Sync

Pushing commits updates the code, but it does not explain the intent automatically. If a reviewer asked for a specific change, respond in the pull request conversation so they know what changed. Good fork workflow is not only about Git commands. It is also about making the review process easy to follow.

For example, after pushing a fix you might comment that the branch now includes the requested test or API change. That saves reviewers from guessing whether the issue was handled.

Common Pitfalls

• Opening a second pull request instead of pushing to the existing source branch.
• Forgetting which remote is your fork and which is the upstream project.
• Rebasing the branch and then being surprised that a normal push is rejected.
• Using plain --force without understanding the risk to shared branch history.
• Updating the code but not replying to review comments that asked for the change.

Summary

• To update a pull request from a fork, push new commits to the same branch in your fork.
• 'origin is usually your fork, while upstream is the original repository.'
• Sync with upstream when needed by merging or rebasing onto the base branch.
• Use --force-with-lease only when history was rewritten.
• Keep the pull request conversation updated so reviewers can follow the code changes.