This is part of an ongoing series of articles on the Git version control system.
The “many repository” paradigm has been partly driven by the distributed development paradigm. Git solves the problem of multiple developers working in multiple repositories very well. Because we want to use and customize projects like the Linux kernel, U-boot, and OpenEmbedded in our projects, then we naturally find ourself in the situation where we need to manage multiple repositories. Yes, you can check the Linux kernel into your company Subversion repository, but you are much better off long term if you bite the bullet and implement your own Git infrastructure.
As we consider the product development process, we need to consider the life cycle of a product. Most products live for at least several years, and will go through several software iterations. If we can update the software components we use, then we can add value to the product in the form of new or updated drivers to support new peripherals, new libraries, performance improvements, etc. But, we are dealing with millions of lines of source code, so we must have an efficient way to deal with software projects of this size. The below Figure 2 illustrates how you might organize a typical project. Notice we can pull updates from the U-boot and Kernel source trees at any time in the development process, and merge the changes with our own modifications. We might have an outside team working an application, and we then easily synchronize the repositories when it makes sense.
There are many other design flows possible. Once you have the ability to support multiple branches and repositories easily, it becomes trivial to implement a staging/testing repository for a QA processes, maintenance repositories for supporting old releases, etc.
Even at a personal developer level, Git’s distributed capabilities offers many advantages. Each Git workspace is actually a full Git repository. This means you can check changes in locally, re-organize your changes, be able to track changes when off-line, etc. For this reason, many developers are now using git-svn when they need to work with Subversion repositories. With git-svn, you have all the benefits of using git locally, and yet you can easily synchronize with Subversion repositories. And this leads us to our next topic: cheap branches (coming soon).