Git – How Best Can I Use Git When My Employer Uses VSS

There's a few things I might be concerned with, as a disinterested third party. So let me toss some questions at you that you'd better be prepared to answer (to your IT department):

• Any version control is better than none. We have plenty to choose from, what's wrong with those?
• Distributed version control? What's that? How do we control that?
• What does it cost? Not just the software, but the servers, licenses, maintenance, etc.
• I don't trust GitHub, or any outsourced hosting. We need to do everything in-house. Why can't we set up our own server?
• Can we run it on Windows? We have to keep it on our current baseline, you know.
• How do we secure the thing? SVN we get, but this scares me.

These are the very first questions that will come up. As to VSS and PVCS you can probably come up with a bunch of reasonably good arguments (like VSS corrupting version history). SVN will be a bit more difficult. I highly recommend focusing on the merge capabilities of GIT, and also recommend keeping an open mind about Mercurial. Every argument for GIT is also an argument for Mercurial--and Mercurial has more mature Windows support.

Security is of paramount importance to financial and government institutions. They will be extremely resistant to externally hosted resources. From a risk management perspective, consider what could happen if someone hacked GitHub and stole the source code, or discovered the security vulnerability documented in the issue tracker. That would be devastating to the company. From a pure management perspective, if the company is legally required to pay you for every hour you work, how can they monitor whether you are working from home when the resources are outside their VPN network? On another note, how can they prevent you from performing some corporate espionage when all the resources are available from outside the company? These are the IT and management arguments against outsourcing the hosting. A large company has to look at things this way. For a small company, you look at the bottom line and how much it would cost to put all those services in place.

It's actually cheaper for the large company to do it in house. They already have the IT resources, they just need to shuffle the responsibilities a bit. And if the solution largely takes care of itself with only periodic maintenance needed (backups and user management), all the more reason to keep it inside corporate doors.

As to Windows hosting, that's an organization by organization issue. Several companies have swallowed the Windows koolaid. Others have swallowed the Linux koolaid. Others consider it on a case by case basis. You'll have to play by the rules the IT department has set for your organization. As long as your solution can be hosted on either, you are golden.

Finally, in such a large organization there are guaranteed to be fiefs all wanting to do things their way. They all have convincing arguments why they chose VSS, PVCS, SVN, or what have you. To IT they are all the same. The only way to consolidate within an organization that large is to have the order come by fiat from above. Such orders are always met with resistance, and it is probably not something your company wants to do unless there are obvious Total Cost of Ownership (TCO) benefits to having a standardized version control system.

With distributed SCMs like git or mercurial (which is what bitbucket uses), branching is still possible but often unnecessary. What you do instead is (basic workflow):

• Set up a repository in a location that is accessible for all developers (a network share, a server that people can ssh into, a third-party service like github or bitbucket). This will be your authoritative repository.
• Clone this repository onto each developer's machine, and do whatever you have to to create a suitable development environment.
• Work on your local copy; commit whenever you want to. Commits are local, so you won't hurt anyone. Be sure to pull from the central repo from time to time, so that your local copy doesn't go out of sync.
• When you have something you think is ready for production, push from your local clone to the central repo.
• On the central repo, whenever you have a version you want to mark as release candidate, tag it. This way, you can update any given clone to that exact version later on.

Since distributed SCMs allow unlimited clones to your repository, and each clone can serve as the master, you can build more complex workflows from this base. For example, you can have several central repositories: one for development, one for QA, one for production. You can use a dedicated clone just for a build server. You can use more than one clone locally; instead of branching, you just create another clone, and if it doesn't work out, you simply delete it.

Another nice benefit is that if the central repository breaks beyond repair, you'll still have several copies around; all you need to do is clone one developer's repo back to the central server and all is good (you do lose uncommitted changes on the central server though, but ideally, nobody should make changes there directly anyway, so the only thing left to do is for everyone to push their latest changes again).

Tracking databases is hard; normally, you want to track the structure, but not the data - data changes a lot, isn't really relevant for the code, and may contain sensitive information you better not make accessible that way. A common approach is to make a script that sets up the database in its current form, and maybe another that populates it with typical test data. Alternatively, you keep track of incremental change scripts - you'll have one script that creates the database as designed on day one, and then a bunch of scripts that, if applies in order, modify the database until you finally end up with the current state of things. Those are less reliable than tracking code changes though, and they require more manual work, so whatever you do, you want to have a good backup / restore plan for your production database.