GIT is a piece of software for source control - tracking versions and branches (different variants of the code). Github is a public repository using GIT for people who don't want to host and manage their own. You can use it for a place that you and your friends can all work on the same code if you wish.
There are numerous different programs for controlling source / version control. SVN is another very popular one. It is much less popular today, but much simpler to understand. SVN works like a library with files as the books. People can check out (copy) the files and make changes and then put them back and SVN tracks every change made so that you can revert a change if someone does something stupid (which is what programmers do). If two people have both made changes, then what happens next is called a "merge" where you combine two people's changes. If they've both changed the same lines in a file, you get what is called a "conflict" and someone will have to sort that out by hand and decide what the right solution should be. Anyway, the metaphorical library in this case is called a "repository" and it lives on a server somewhere.
I started this explanation with SVN because it's reasonably simple to grasp. A central directory and some software to track when those files change.
GIT is more complex. It's popular because it can do some very clever things, but people can get in one Hell of a mess with it.
http://xkcd.com/1597/
Try to avoid getting sucked into the more advanced aspects of it. If you're just learning to program, you should really only need to learn a few things - how to "clone" a repository (i.e. getting a new copy of everything on your local machine to work on), how to "stage" files. This is something you do after making some changes locally and it's the preliminary step before you "commit" files. Committing changes is where you tell GIT that you're making a new version of the code. So if you fixed a bug, you'll "commit" your fix with a little message saying "bug blah has been fixed". Then you can see the history of all the commits and their messages in the log and do things like revert those commits if you find a mistake was made.
The final thing you need to understand to get the very basics down, is "pushing" and "pulling". You will have a clone of the repository on your local machine that you work on. When you have committed changes, they're still only on your local machine even though you committed them. To share them with your friends you'll need to "push" your changes back to the origin repository. Similarly, if someone else has pushed their changes up, they don't magically appear on your machine. You have to "pull" from the repository to get them. Which you'll want to do frequently to avoid everybody drifting too far apart and making conflicts more likely.
I've simplified a lot here. GIT confuses the Hell out of many people. So for example I've just told you to do a "pull" when really a "pull" is a shorthand for two separate commands ("fetch" to get the files and "merge" to combine the changes with your own) and sometimes people want to do these separately for various reasons. And I haven't really touched on Conflicts. But I've simplified for good reason. Learn to create repositories, learn to stage, commit and then push your changes, and that should be enough to get you started. The aim is to learn programming, not get into a frustrating experience with GIT. Learn about rebasing, stashing, reverting pushed merges, etc. later on.
If you're just all trying to work on a single powershell script or something, just email it around. You'll lose a day just working out how to use GIT, what front-ends you prefer to work with it (or command line), etc. and it's a hassle you can do without. If you're writing more significant software, then by all means, create a repository on github and get stuck in.
Hope that helps.
