Just push more commits on to the branch the request is for. The pull request will pick this up then.

Example:

If you want to have b merged into master

1. You push c1,c2,c3 to b
2. then you make a new request for b
3. it gets reviewed and you need more commits
4. You push c11,c21,c31 to b
5. The pull request now shows all 6 six commits

I just had one commit in a pull request, and I used git commit --amend to update it. I then did a force push with git push -f so my amended commit replaced the original one. The pull request automatically picked up the new commit. (It actually showed both commits, but when I reloaded the page the old commit had gone.)

So while a forced push is generally not recommended, it can be useful for pull requests. It's not recommended because if someone bases a commit on top of yours then they will have to do a rebase after your change. But since nobody should be basing their work on an under-review pull request, it should be pretty safe in this situation.

If you continue to make changes and keep pushing to the same branch, the refined commits will be added to the same pull request (unless your pull request has been merged). This could make the history very cluttered.

An alternate solution and a technique that I use is as follows:

1. Create a new branch (fixes) from the repository(upstream) and branch (develop) to which you intend to send the pull request by doing:

   git branch fixes upstream/develop

2. Add your refined commits directly to this newly created branch.

   git commit -m "your message"

3. Push this branch to your own forked remote (could be named origin).

4. Compare and send in a new pull request with clean commit history.
5. Also, it is a good idea to delete your branch after the pull request has been merged.
6. And you can comment and close your earlier pull requests.