问题
I opened a pull request to rails repo on github by using Fork & Edit this file file button.
Now, After getting feedback on my PR, I wanted to add some more commits. so here is what I ended by doing
$ git clone git@github.com:gaurish/rails.git #my forked repo
$ git rebase -i 785a2e5 #commit hash of my commit using which PR was opened
$ git checkout patch-3 #branch name I had to send my commits under to be shown in that PR
$ git commit -am "Changes done as per feedback"
$ git push origin patch-3
This worked fine but seems quite a complex workflow. Maybe I am wrong something wrong here?
my question is: Am I doing this the correct way? if not, then what is the proper way to do this?
回答1:
Since you're using GitHub's tools and just changing one file, you could also browse to the file on GitHub, select the proper branch from the upper left corner under the "tree:" dropdown (patch-3 in your case), and now choose "Edit this file". Now your changes will be committed to this branch and will show up in your pull request
回答2:
I just recently blogged on this topic:
How do we keep this feature branch up to date? Merging the newest upstream commits is easy, but you want to avoid creating a merge commit, as that won’t be appreciated when pushed to upstream: you are then effectively re-committing upstream changes, and those upstream commits will get a new hash (as they get a new parent). This is especially important, as those merged commits would be reflected in your Github pull request when you push those updates to your personal github feature branch (even if you do that after you issued the pull request.)
That’s why we need to rebase instead of merging:
git co devel #devel is ansible's HEAD aka "master" branch
git pull --rebase upstream devel
git co user-non-unique
git rebase devel
Both the rebase option and rebase command to git will keep your tree clean, and avoid having merge commits. But keep in mind that those areyour first commits (with whom you issued your first pull request) that are being rebased, and which now have a new commit hash, which is different from the original hashes that are still in your remote github repo branch.
Now, pushing those updates out to your personal Github feature branch will fail here, as both branches differ: the local branch tree and the remote branch tree are “out of sync”, because of those different commit hashes. Git will tell you to first git pull --rebase, then push again, but this won’t be a simple fast-forward push, as your history got rewritten. Don’t do that!
The problem here is that you would again fetch your first changed commits as they were originally, and those will get merged on top of your local branch. Because of the out of sync state, this pull does not apply cleanly. You’ll get a b0rken history where your commits appear two times. When you would push all of this to your github feature branch, those changes will get reflected on the original pull request, which will get very, very ugly.
AFAIK, there is actually no totally clean solution to this. The best solution I found is to force push your local branch to your github branch (actually forcing a non-fast-orward update):
As per git-push(1):
Update the origin repository’s remote branch with local branch, allowing non-fast-forward updates. This can leave unreferenced commits dangling in the origin repository.
So don’t pull, just force push like this:
git push svg +user-non-unique
or:
git push svg user-non-unique --force
This will actually plainly overwrite your remote branch, with everything in your local branch. The commits which are in the remote stream (and caused the failure) will remain there, but will be dangling commit, which would eventually get deleted by git-gc(1). No big deal.
As I said, this is AFAICS the cleanest solution. The downside of this, is that your PR will be updated with those newest commits, which will get a later date, and could appear out of sync in the comment history of the PR. No big problem, but could potentially be confusing.
回答3:
You could also create a new pull request which is bound to master instead of a specific abc1234 revision.
That way, any new commit/push to your repository will be added to the pull request.
来源：https://stackoverflow.com/questions/10147445/github-adding-commits-to-existing-pull-request