How do I create and/or send a pull request to another repository hosted on GitHub?
To learn how to make a pull request I just followed two separate help pages on Github (linked below as bullet points). The following command line commands are for Part 1. Part 2, the actual pull request, is done entirely on Github's website.
$ git clone https://github.com/tim-peterson/dwolla-php.git $ cd dwolla-php $ git remote add upstream https://github.com/Dwolla/dwolla-php.git $ git fetch upstream // make your changes to this newly cloned, local repo $ git add . $ git commit -m '1st commit to dwolla' $ git push origin master
Part 1: fork someone's repo: https://help.github.com/articles/fork-a-repo
- click the 'fork' button on the repo you want to contribute to, in this case: Dwolla's PHP repo (Dwolla/dwolla-php)
- get the URL for your newly created fork, in this case: https://github.com/tim-peterson/dwolla-php.git (tim-peterson/dwolla-php)
- type the
git clone->cd dwolla-php->git remote->git fetchsequence above to clone your fork somewhere in your computer (i.e., "copy/paste" it to, in this case:
third_party TimPeterson$) and sync it with the master repo (Dwolla/dwolla-php)
- make your changes to your local repo
- type the
git add->git commit->git pushsequence above to push your changes to the remote repo, i.e., your fork on Github (tim-peterson/dwolla-php)
Part 2: make pull-request: https://help.github.com/articles/using-pull-requests
- go to your fork's webpage on Github (https://github.com/tim-peterson/dwolla-php)
- click 'pull-request' button
- give pull-request a name, fill in details of what changes you made, click submit button.
- you're done!!
Submodules are indeed a good fit, as your repo will only record a gitlink (special entry mode
160000) to record the commit of the submodule repo you are using.
Don't forget that this submodule is a git repo of its own, which means:
- you can make commits in it (see "true nature of submodules")
- you can make it follow the latest commits of branch (see "git submodule update")
- you can add remotes to it (like a remote to the original repo you have forked, in order to fetch updates from said original repo, see "What is the difference between origin and upstream in github")
Even though they are called exactly the same thing, a GitHub pull request and a 'git request-pull' are completely different.
The git request-pull is for generating a summary of pending changes to be sent to a mailing list. It has no integration by default with GitHub.
The GitHub Pull Requests is a fully featured function of GitHub only. It allows for merging and integration of code from a different branch/fork. You can resolve merge conflicts, do code reviews, or add additional comments to a GitHub pull request.
Unfortunately the git command is named similarly to GitHub functionality which makes it sound like they should be doing the same thing.
It is a communication problem, more than a Git issue.
I prefer making separate PR, as their intent and scope differs.
But, in the PR message, one must clearly states if that PR is suppose to supersede another PR.
That way, the original repo project manager can try those different PR separately, gauging their effects, and select the appropriate one.
He can then ask initial contributors to redo their PR (on their same branch) based on the work of the PR he or she finally selected.
You probably want to look at this GitHub help page. It says:
You can use any of the following keywords to close an issue via commit message:
So "Fixes #123" or "Resolved #456" will work. All pull requests are mapped as issues, so this will works for pull requests too.
Note: you'll see a message about unmerged commits because you amended the pull request. So looking at the pull request, it won't be immediately obvious that the PR was incorporated (versus just plain closed) unless you put something meaningful in the first line of the commit message so you can see the message in the pull request.