How to update a pull request from forked repo?
Asked Answered
C

5

672

So I first forked a repo and then made a commit to that forked repo. I then opened a pull request. The pull request listed all the changes I wanted.

After reviewing my pull request, there were a number of changes that the repo owner wanted me to make before he accepted it. I have made those changes in my fork, now how do I update the pull request with those changes (or is this not how I should handle it)?

Cthrine answered 20/3, 2012 at 16:4 Comment(3)
possible duplicate of Preferred Github workflow for updating a pull request after code reviewMedicable
@PaulDraper I disagree, that user already knows and presents various methods for updating a pull request, and ask which is best. I on the other hand, did not know of any methods and was asking about their existence. As the popularity of this question shows, this is the case for many other users.Cthrine
I think the popularity is due to the fact that (1) this is a really good, common question and (2) some users wound up here instead of there. If it had been originally identified as a duplicate, they would have found the other question to be the same and answer their question.Medicable
C
661

You have done it correctly. The pull request will automatically update. The process is:

  1. Open pull request
  2. Commit changes based on feedback in your local repo
  3. Push to the relevant branch of your fork

The pull request will automatically add the new commits to the Commits tab of the PR.

Canso answered 20/3, 2012 at 16:9 Comment(10)
nice! I was checking everywhere but the actual pull request. its magic, black magic, I will not question it.Cthrine
This is a good reason to work in branches. If, for instance, you always pushed to master, you could unintentionally add to your previous pull request.Taradiddle
Somehow, the changes aren't being reflected in this pull request the way they should. Actual branch is two commits ahead of the pull request. github.com/akshay2000/XBMCRemoteRT/pull/17Arid
This doesn't appear to be the case anymore, even though it was in the past. Here's an example of a pull request I made (github.com/toopay/bootstrap-markdown/pull/167) compared to the branch itself (github.com/mhuggins/bootstrap-markdown/commits/…). Curious how to do this anymore since the process seems to have changed.Leprechaun
The github UI is a tad confusing in my opinion -- it shows the new pull requests in somewhat of a small font beneath a comment, so it may not be obvious that a pull request did in fact get dispatched a few minutes earlier.Califate
I kept checking the TOP of the pull request, giving up and trying to create a new one. "(ie, it's already there, scroll down!)" saved me. It actually was there - at the bottomEgwan
GitHub actually tells you: "Add more commits by pushing to the SolveWorldHunger branch on ChangeTheWorldProject."Entity
The same here - I don't see changes from forked repo in main repository. Looks like a GitHub bugJunoesque
Seems like a bug indeed, and happens only once in a while. I tried pushing an empty commit to force GH to update my PR, but nothing happend. I reported it to GitHub staff.Jumna
It looks like it is not possible to update a pull request if the fork was deleted: #33884743Sennight
B
83

Updating a pull request in GitHub is as easy as committing the wanted changes into existing branch (that was used with pull request), but often it is also wanted to squash the changes into single commit:

git checkout yourbranch
git rebase -i origin/master

# Edit command names accordingly
  pick   1fc6c95 My pull request
  squash 6b2481b Hack hack - will be discarded
  squash dd1475d Also discarded

git push -f origin yourbranch

...and now the pull request contains only one commit.


Related links about rebasing:

Barrelchested answered 2/7, 2014 at 9:47 Comment(4)
Upvote for mentioning rebase. It helps cut out the noise in revision history.Cthrine
+11 (yes i intended the key rrrrepeating. Using git rebase/pick/squash is working great.Finespun
The downside to this approach is that you are removing you prior commit. That means if in the pull request comments are made they will be lost, and disappear along with the original commit.Fleshly
In Bitbucket you can see comments on "previous versions" of a file in a pull request. Although it would be nice to see something like in Gerrit where you patch commits and can see the entire history with comments. It makes for a neat git history and traceability when you can go back and see the full discussion around any commit.Overwrite
S
39

Just push to the branch that the pull request references. As long as the pull request is still open, it should get updated with any added commits automatically.

Snub answered 20/3, 2012 at 16:8 Comment(0)
H
16

I did it using below steps:

  1. git reset --hard <commit key of the pull request>
  2. Did my changes in code I wanted to do
  3. git add
  4. git commit --amend
  5. git push -f origin <name of the remote branch of pull request>
Harrisonharrod answered 27/7, 2015 at 2:50 Comment(1)
Very good, I prefer this approach! GitHub even hides (but keeps) the outdated sections of code and associated comments. It's good to remember that if the pull request contains several commits and the one that requires fixing is not at the tip of the branch, "git reset --hard" will discard all changes commited after the specified ID. I had a backup that I applied manually. Not very convenient if there is more than one extra commit though...Brahman
S
3

If using GitHub on Windows:

  1. Make changes locally.
  2. Open GitHub, switch to local repositories, double click repository.
  3. Switch the branch(near top of window) to the branch that you created the pull request from(i.e. the branch on your fork side of the compare)
  4. Should see option to enter commit comment on right and commit changes to your local repo.
  5. Click sync on top, which among other things, pushes your commit from local to your remote fork on GitHub.
  6. The pull request will be updated automatically with the additional commits. This is because the pulled request represents a diff with your fork's branch. If you go to the pull request page(the one where you and others can comment on your pull request) then the Commits tab should have your additional commit(s).

This is why, before you start making changes of your own, that you should create a branch for each set of changes you plan to put into a pull request. That way, once you make the pull request, you can then make another branch and continue work on some other task/feature/bugfix without affecting the previous pull request.

Subterranean answered 4/8, 2013 at 7:15 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.