bryface wrote:not sure what you mean by "specific .git files" but any files you might need to keep under version control should be supported by git. you can also create a .gitignore file that specifies files or file types that you _don't_ want to include in the repository (for instance, binaries that you compile from from the source, or other temp files).
https://www.atlassian.com/git/tutorials/ i find is a good no-nonsense tutorial for gleaning the basics.
Ditto what bryface said. I've used git in my projects at school, and it's designed for collaboration with multiple developers. I agree though that it's not very intuitive; I've had to explain it to group members multiple times 
Personally I've used the command line ('git status', 'git pull origin master', 'git add', 'git commit -m', 'git push origin master', etc.) and I've found it pretty straightforward; it may or may not be good for you on XP.
BennVenn wrote:...maybe its more of a change log...
The .git files that are being generated are just what you said: they keep a local record of the changes and incremental "commits" you've made. Whenever you do a "commit" the .git file is updated; syncing with the server ('git push…') brings both local and remote copies up to date. Actually you can use git without an external server (that's all that Github is) to track your changes, but you then don't have a remote record of your previous changes (and of course, other people can't look at what you've done).
Branching is for other (admin) developers working in the same group and repository, either as personal workspaces for each person before changes get dumped into the main perfect version ('master'), or for developing and testing out new features without breaking the current perfect version.
Forking is designed for random outside people who walk up, want to check out your code, and maybe fiddle around with it; it's more of a "hard copy." Later on if they think their changes are awesome and would make the original better, they contact you for a "pull request" to combine their changes with the current perfect version. Then you go through the merge process, by which you decide which changes of theirs to keep, which are redundant or outdated, and which to throw out. It's a good way to collaborate without giving others too much control.
As for collaboration: honestly you'll want to talk with other people you're working with to split up tasks and make sure you're not stepping on toes. Once you've done that, though, git allows you to work separately on the same code base and then come together later to combine your changes and work out any conflicting differences.
Haha sorry for the long post! ^_^ Hopefully that makes sense. If you have any other questions I'd be happy to help. I haven't done GB programming, but at least I can help out with this sort of thing.
