Version Control – Conceptual Differences Between Git and GitHub

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.

First, if you really want to use git for this, then consider using its Submodule functionality:

Git's submodule support allows a repository to contain, as a subdirectory, a checkout of an external project. Submodules maintain their own identity; the submodule support just stores the submodule repository location and commit ID, so other developers who clone the containing project ("superproject") can easily clone all the submodules at the same revision. Partial checkouts of the superproject are possible: you can tell Git to clone none, some or all of the submodules.

The linked page contains a detailed discussion including examples of how to use it exactly.

That said, I would recommend not to use your version control system for dependency management and rather start using a build tool that can handle these things for you, such as Maven or Ant. There is even a PHP-specific build tool in development called Phing, but I haven't used it myself yet. It is mentioned in an article that discusses your question: Version Control != Dependency Management.

The reason build tools may be a better fit in the long run is because they often also support different repository types, external libraries (and different locations) and extensive checking. If you however just want to integrate these two libraries and don't want any additional hassle, the submodule approach is probably sufficient.