Convert a GitHub Issue Into a Pull Request
A little-known-feature of the GitHub API is the ability to attach changes to an issue, converting it into a pull request. The hub command, a wrapper around git that makes it more GitHub aware, allows you to easily do this.
hub pull-request -i 384 -b bkeepers:master -h bkeepers:branch-name
-iis the GitHub issue number-bis the base, or where you want to send the pull request, withbkeepersbeing the owner of the repository.-his the head, or the branch where your changes live.
Update: in the comments, George Hickman suggests: “as long as you’ve pushed your changes and your local branch is tracking your remote you can exclude the -b and -h options!”. Note that you can set up tracking when pushing with git push -u origin branch-name.
I put together a quick (crappy quality) video showing how this works.
My workflow lately has been something like this:
1. Create a milestone in GitHub Issues for the mini-project I am working on
2. Create Issues for the features I can foresee and begin discussions
3. Work on the code for an issue in a branch
4. Push the branch and convert the issue into a pull request with the command above
This workflow is also great for handling bugs, where someone likely opened an issue to report it, you create the fix in a branch, attach it to the issue, and then close it by merging the pull request.
The biggest caveat with this approach is that it does not work well for experimental code. There is not undo button for converting a pull request back into a plain ol’ issue, nor is there a way to replace the pull request with a different one. So if you convert an issue into a pull request, and then decided you don’t like the implementation, you have to close the issue, burying the discussion around it.
8 Comments
Brandon, as long as you’ve pushed your changes and your local branch is tracking your remote you can exclude the `b` and `h` options!
George: thanks for the suggestion. I updated the post.
I liked this when I first discovered it, but through use I realize don’t like it too much. I would turn issues into pull requests early for feedback, but sometimes an issue is a bit more hairy than first realized, so I then close that pull request and hide the history of that issue. Linking keeps the original issue open, even if it takes a few PRs :)
Mike: Yeah, I generally only use it for pull requets that are really simple and almost done. If I’m working on something big, it is usually associated with multiple issues or a milestone anyway, so it makes more sense to create a separate pull request for it.
I used the method described above,but I am getting this error “Error creating pull request: Forbidden (HTTP 403)” when I am pulling the request,anybody who can help please.Thanks in advance!
I also am getting Error creating pull request: Forbidden (HTTP 403). Days earlier not had problems
It appears that there is something not working with the gem version. One person reported to me that they installed the command line version and it worked fine.
Once an issue is “converted” to a pull–request issuer will show up as if he/she was who created that pull–request (which may not be true in some cases), which is annoying.
If you later decided to “close” the pull–request without merging it in, then you lost your issue report too.
Also, if you have more pull–requests to fix an issue this is not feasible.
I personally also don’t like issue and pull–request URLs redirect one to another silently.
But, it is good to know that it is there for us to use, I am glad though GitHub website won’t allow you do that if not handled all those edge–cases.
Thanks,
Post a Comment