First of all, read this to gain an understanding of the concepts involved in version control:
http://guides.beanstalkapp.com/version-control/intro-to-version-control.html

Having read the above, you should now understand that Git is s distributed VCS (version control system). You should understand that each project you work on is stored in a repository, and that everyone working on a project will have a copy of the repository (Git calls these clones) on their local computer. There is also a copy of the repository on the GitHub website.

When you begin working on a project you’ll usually use the GitHub website to create a git repository and then CLONE that repository onto your computer. Alternatively you can create a repository and then PUSH it up to the GitHub website.

If you begin working on an existing project you’ll simply CLONE the repository onto your local computer.

Either way, you’ll now have a local repository that you can use to work on the project.

Once you have made changes to files, you need to COMMIT them to your local repository. You should commit often, with a message explaining the changes you’ve made. This’ll be useful should you need to revert a change at a later date as you’ll be able to find the commit easier. It also helps others understand the reasons behind the changes you’ve made.

When you are ready for other people working on the project to see your changes you need to copy them back up to GitHub. Git calls this PUSH. So, in other words you need to PUSH your commits to GitHub.

Once you have PUSHed, others can then copy them from GitHub into their own copy of the repository. This is called PULL.

So, what happens if someone PUSHes changes to a file you’re already working on? Well, when you come to PUSH, Git won’t allow you to do so and will ask you to PULL changes from the server so that your files can be merged together. When you next PULL you’ll be prompted to MERGE the two files and then COMMIT the merge result. You’ll then be able to PUSH to GitHub.

Lastly, if you’re likely to be working on the site for an extended period of time (like a couple of days or weeks) and don’t want your changes to be put onto the example.com site, you should still use the COMMIT and PUSH workflow, but you should create a BRANCH first. This means that your code is still being backed up to a secure location and you won’t lose your work should your computer get stolen or blow up or something. It also means the main line of development (called MASTER) remains untouched until you MERGE your BRANCH.