How do I use Git and Git Extensions?
Intro
I've used SVN before, back when I was working as a solo programmer, just to keep an offsite record of what I was doing, so I kind of know about ideas like "repositories" and "commits" and the like, though not much more than that. "Branches", "merges" and "checking out" are, sadly, a mystery to me.
I want to start using Git because we've got a couple of guys who work away from the office and they have complained that they sometimes can't get through to some other version control systems because their IDE integration causes them to sulk and fall over when they get out of contact. Git's idea of "Every working directory is a repository" seems like it should go some way towards solving that.
Anyway, I've downloaded the "Git Extensions" to add The Shiny to the Windows context menus, etc. and I've found that I really have no concept of how I'm supposed to use this to control my versioning. Not finding anything obvious after a google search, I present the following theoretical scenario to Stack Overflow in the hopes that someone will tell me what to do, in small words:
Scenario
I have three projects. One project, ProjectReuse is used by the two other projects (ProjectA and ProjectB). Various people in the organisation will need to edit the code for each project, using Visual Studio 2010.
I have three folders on my desktop, labelled "ProjectReuse", "ProjectA" and "ProjectB". I've got the Git Extenstions window open. A cow, wearing a Santa Claus hat, is staring at me.
Questions
What do I do now to create the repositories in such a way that several people (including those pesky not-always-on-site guys) can access a repository when they need to, on-site or off, with or without a permanent connection to our servers?
When the first guy needs to edit a file, what does he need to do? Check out? Branch? I have to explain this to the other team members and I'm a bit wobbly on these concepts, myself. I've only used version control for my solo projects before.
Wheedling and excuses
The first "how do I set this up?" question is what I'm most interested in, but I figure if I'm going to ask for the idiot's guide, I might as well ask for it to be as useful as possible for the next idiot who stumbles onto this question. I'm not looking for particularly in-depth answers, here; I just haven't got any clear picture in my mind of how a multi-user version control system works. Once I've got that in mind I should be able to put the rest together by myself.
Answer
Ok, let's get the first thing about git straight. Git is distributed. Repeat this to yourself as many times as necessary: there is no central server, central repository or indeed anything central. Completely in contrast to SVN, you are not all accessing one repository (nothing central).
What you do is create a repository somewhere. Then everybody else clones (copies) it. Now everyone has their own copy of the repository and can do with it as they wish. Branch names don't even need to be consistent across repositories although many people do this as it helps.
So, how do you set it up? You init a repository then everyone who wants it clones it. In your case, I'd recommend each project have its own git repository rather than lumping all three together.
But but but how on earth am I supposed to manage a development team, I hear you say? Never fear. I said there was no central repository, but that doesn't stop you designating one of the repositories to be the release repository, and another to be the experimental or whatever.
What you need then is a workflow. Typically, what you do is create said release repository and then say: "everybody pull from the master on here". This represents your latest "stable" release. Now you tell everyone to branch from here and develop their new features. They do this. As these get done, you ask people to merge their changes back into their own master or wherever, then you, the release manager, pull from them (probably into a development branch but you could well do it into your release master because it is trivial to reverse commits). The next person then updates their master and does their merge. They resolve their own merge conflicts etc, and so on until you have all the features you want. You do your testing etc then the release repository really does pull all of that into its master.
In practice you might do many different things. For example, if you have a lot of people you're going to need quite a lot of communication going on, because if lots of people make incompatible changes to your shared project there's going to be a few merge commits. To avoid this, users can pull/merge from each other or use a local "shared" repository.
It does work.