Git/GitHub tip No. 10: Explore GitHub
Many interesting open source projects have repositories on GitHub. Explore GitHub provides a browsing interface to find some of them, but mostly it's easier to type a few letters of the project's name in the search box to find its repos. For example, type
Git/GitHub tip No. 11: Contribute to open source projects
As long as you're browsing open source projects, why not contribute to them? It isn't as hard as you might think, and you'll learn a lot. For example, you could clone the jquery/jquery (jQuery Core) project, and browse through README.MD. Near the top you'll see:
In the spirit of open source software development, jQuery always encourages community code contribution. To help you get started and before you jump into writing code, be sure to read these important contribution guidelines thoroughly...
That's followed by three links. The first of the three will get you started fairly quickly. Not every open source project lays out the plan so clearly, but they all try.
Understand the difference between being a contributor and a committer. A contributor has signed the required agreements and made a contribution available to the project. A committer is empowered to actually commit the proffered contribution to the project repository. Because there will be a delay while a committer tests your contribution and you won't want to tie up your master branch, you should make your changes in another branch (see tip No. 6) before sending out a pull request (see tip No. 16).
Git/GitHub tip No. 12: Use editors and IDEs that "git it"
If you're barreling along on an edit only to discover, when you go to check it in, that someone else has been working on the same code as you have, you're likely to become frustrated. You can avoid or at least minimize that frustration by using an editor or IDE that integrates Git and actually tells you that the code you're viewing has new commits that you should pull, and what the new commits are supposed to accomplish.
Git/GitHub tip No. 13: Fork a repo
Forking a repository means creating your own writable server copy of a repo -- that is, creating a fork in the road. Recall that we clone a repo (see tip No. 1) to make our own client copy of it. If it's a public repo for which we do not have commit privileges (see tip No. 11), then the easiest way to contribute our changes is to first commit them to our own fork of the repo on the server via the fork button on the original GitHub project. Then we can issue a pull request (see tip No. 16) to the owners of the forked repo so that they can test and possibly use our contribution. It's confusing at first, but it gets easier. See, for instance, this book section on contributing to a small public project.
Git/GitHub tip No. 14: Watch projects
When you fork a project, you'll most likely want to know what's happening in the upstream project. If so, watch the repo. If the update chatter annoys you, unwatch it. If you notice changes that affect you, fetch and merge the upstream commits.