Hopefully this helps:
1) You 'clone' the repository so you get all the files, and more importantly, you get the complete history of the project (and all of its development branches) along with it. You can place the project back to any prior state all the way back to the beginning.
2) You make a change to the project, and then commit your change. A commit is a description of what you changed, along with any text description you care to add to describe what/why you did what you did.
3) A 'pull request' is a way of sharing your commit with others. It lets them a) see what you did, and b) temporarily merge your change into their own local copy of the project (combining with any changes they have in flight but aren't yet part of the 'official' branch of the repository). Then anyone can comment / suggest changes / freely complain without disturbing anyones lines of development.
4) If the maintainers agree with what you've done, they can merge the change into the repository so it's then available to anyone who subsequently clones/syncs their local copy. I think in GitHub, the pull request results in a 'git merge' once accepted by the maintainers.
It's just like providing feedback on a book: you buy ('clone') your own copy (or an editor sends you a copy), you mark it up with a pen correcting spelling, punctuation, or content ('commit'), then you send the marked up book back to the editor ('pull request'). If the editor agrees with you, they change the master version of the book with your edits ('merge'), and then the whole process can begin again with a new version of the book that everyone has agreed is correct (at least up to that point).
These are GitHub terms: pure git uses 'commit' to describe a change, a 'pull' allows you to retrieve all of the changes and branches from a remote repository to 'sync' your local copy (in other words, it 'fetches' and 'merges'), and a 'push' allows you to send your changes from your local repository to a remote.
