Pull Requests (PR) are a huge topic on Github and here is a whole “BOOK” about it on github:<\/p>\n
https:\/\/help.github.com\/categories\/collaborating-with-issues-and-pull-requests\/<\/a><\/p>\n Here is a short summary from me.<\/p>\n 1. a developer is forced to create a fork<\/strong> (separate copy) of a public repository (called upstream<\/strong> repo) on github because the repo does not belong to the developer or the developer is not part of the organisation\/team which owns and manages it.<\/p>\n 2. the developer clones the fork (called original<\/strong> repo but not original actually),which is owned by him\/her on github, on to his\/her local development machine. <\/p>\n 3. the developer switches to a (relevant) hotfix<\/strong> branch to work on an issue<\/p>\n 4. the developer modifies code as required and commits the changes with reference to an issue<\/p>\n 5. the developer pushes the committed changes to the fork.<\/p>\n 6. the developer creates a pull request from fork to the upstream<\/p>\n 7. an admin reviews the PR Examples:<\/strong><\/p>\n – https:\/\/github.com\/salesagility\/SuiteCRM\/pulls<\/a><\/p>\n – https:\/\/github.com\/symfony\/symfony\/pulls<\/a><\/p>\n – https:\/\/github.com\/nodejs\/node\/pulls<\/a><\/p>\n – https:\/\/github.com\/facebook\/react\/pulls<\/a><\/p>\n – https:\/\/github.com\/django\/django\/pulls<\/a><\/p>\n
\n7. a. approves the PR and merges them
\n7. b. rejects the PR; the developer has to repeat steps 4, 5, 6
\n7. c. i. the PR is ignored for 2 years!
\n7. c. ii. another admin reviews the PR after 2 years but there are many conflicts now
\n7. c. iii. the community is waiting for the developer, who is now a sherpa<\/strong> in The Himalayas, to update the PR!!! Because he\/she lost the will for coding!<\/p>\n