It maintains a history of every "commit" that you do, and you can move around these commits.
Say you are 1 month in and you want to back track a week. Find a commit from then and jump back to it.
Want to add some new strange thing and not mess with your master/live copy? Branch it, make a seperate stream from the main that can be commited to independently. Changes here won't effect the main branch. This can be used either for new features and what not, or just to split the dev work into parts, or bug fixes blah blah.
New feature is great? You've reached v0.1? Merging can bring in these branches and combine them. So you can merge the new feature into the main branch so its part of the main copy now.
Thats like the worlds shortest description, checkout the free manual here, its really good.
Now for your questions:
1) Should be able to. Git works by tracking any files you tell it to. Just point it to the files you want it to track and it does. Usually, there is no point tracking compiled files. ie, track the .java files, but not the .class files. Basically, if you can make a file from another, don't bother tracking it as you can just make it again. Checkout .gitignore files for ignoring stuff.
2) Actually not sure about this part of it, It doesn't necessarily run of a server, you can just do it locally, but if its on a server its useful for groups. Person 1 edits, commits and pushes to the server. People 2-5 just pull and get all your updates copied down. You could host, or you could look into someone else to do it for you. GitHub and GitLab is what I've used, with GitLab offering free "private" repositories. Private just means that its hidden and password protected, if thats not needed just make it public.
3) Download/Install git. Setup the basic user settings, (ie name, email , chosen editor) Its all covered in chapter 1 of that manual. After that, initialise a folder to be tracked, set the files to be tracked, setup the server and push up to it. From there, any one else can clone the server copy and get an exact copy. From there its just a case of working like normal, and once you are done with a feature/significant enough change to update everyone, you commit it, push it up and everyone can then pull it down.
Terminology is a bit annoying for git. I've only used it for like 1 year, but I'm okay enough with it now.
It is very valuable, even if git itself is a bit awkward to learn. I can easily work on my Uni projects with my team members.
I've used it for a 12 week project for uni, and it would have been awful to work without it. The teams that have used it clumsily are the ones who are struggling. Setting it up properly does pay off. Groups who didn't get issues with conflicting files that don't need tracking and more.
Oh, and If you use GitHub or Lab, try using some of the other built in parts. Wiki is nice to store info in, the issue tracker has an obvious helpful feature, Milestones and more.
Sorry that got so long, but I hope it helps in some form.
