2
  • I just have a local and remote master branch forked from project.
  • I committed and pushed a fix
  • I then did pull request to get it into the original project.
  • I then committed and pushed a fix for a different issue.
  • I tried to create another pull request

But it seems to have just added my latest commit to the same pull request, so now I have one pull request for two different issues ?

And I cannot see how to cancel the pull request either.

Paul Taylor
  • 13,411
  • 42
  • 184
  • 351
  • Did you create a new branch for the new issue? Ideally for two issues, you would need to create two new branches (apart from the `master`) and then push to your forked repo, and then send a pull request. – gravetii Jun 21 '14 at 05:49
  • @gravetti no I just have one branch, trouble is I want to work with latest codebase, i.e I fix issue 1, then I cant fix and test issue 2 if my branch doesnt contain issue 1 because that problem caused it to fall over before the code that needs fixing for issue 2# – Paul Taylor Jun 21 '14 at 06:09
  • Note sure what my answer was downvoted: when fix1 is accepted on upstream repo, then you can rebase your second branch and make fix2: I have edited the answer to better explain why it is the right approach. – VonC Jun 21 '14 at 06:19
  • VonC whas that me, if so apologies I didnt mean to but it is rather early here. – Paul Taylor Jun 21 '14 at 06:22

2 Answers2

1

Any modification to a branch from which you did a pull request will update that pull request.

That is what allows you to rebase a branch on top of upstream/branch (the branch from the original repo) and force push that branch to your fork, while updating automatically the pull request you did from that same branch.

As a result, a best practice is to always make a specific branch for a fix you intent to propose as a pull request.
If you have two fixes, make two branches and two pull requests.

Each of those branches can be rebased on top of upstream/master, with upstream being the name of the remote original repo.

See more at "couple of tips for pull requests"

fork

The OP adds:

The trouble is I want to work with latest codebase, i.e I fix issue 1, then I can't fix and test issue 2 if my branch doesn't contain fix for issue 1 because that problem caused it to fall over before the code that needs fixing for issue 2.

Nothing prevent you to test fix2 on top of fix1 (by rebasing fix2 on fix1 branch in your local repo)

But you will have to wait for fix1 pull request to be accepted before making a PR for fix2 branch (that you will have rebased on top of upstream/master, since fix1 will have been merged in the original repo master branch).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • thats not very good if I have to wait I thought the whole point of this distributed stuff was I just get on with my stuff without being held up by others. Can I do this instead, create a branch do my fix, push and pull request, then update my local master with changes in branch, now create new branch from master do fix2, push and pull request, then update my local master branch from fix 2 and so on .... – Paul Taylor Jun 21 '14 at 06:30
  • @PaulTaylor you can do that if fix2 doesn't depend on fix1. You can even do that if fix2 depends on fix1, but you will have to update fix2 branch by rebasing it on upstream/master once fix1 has been accepted. – VonC Jun 21 '14 at 06:33
  • Before or after I submit PR because the branch is purely for submitting the PR once thats done I can delete it because no use to me – Paul Taylor Jun 21 '14 at 06:41
  • @paul you can submit both PR immediately, but if the second one depends on the first one being accepted, you will have to update the second PR with the rebase I mentioned. – VonC Jun 21 '14 at 06:45
  • in my 'Pragmatic Guide to Git' book it says you should only rebase if you have not shared the code, from what Ive read my situation seems to be unusual yet in my experience I have found it quite rare to be able to fix issues in complete isolation from other changes. – Paul Taylor Jun 21 '14 at 07:07
  • @paul see my tips link I mention in my answer: for a PR, you are *supposed* to rebase as many time as you want. Then force the push: the PR will be updated accordingly. Don't worry: rebase is expected in this workflow. – VonC Jun 21 '14 at 07:11
0

You've probably pushed the commits on the same branch, so they've gone into your existing pull request. Create a new branch if the issues your fixing aren't related.

To cancel a pull request on GitHub:

  1. In any repository's right sidebar, click Pull Requests.
  2. In the "Pull Requests" list, click the pull request you'd like to close.
  3. At the bottom of the pull request, below the comment box, click **Close pull reques**t.

You can also just delete the branch on GitHub which will take the pull request with it.

More information can be found on the GitHub help page here: https://help.github.com/articles/closing-a-pull-request

Luke Peterson
  • 8,584
  • 8
  • 45
  • 46