: How can I create a git repo that contains several other git repos? Lets say that I want the create a new website and use git to track my revisions. Now I want to include several helpful

@Shelley277

While the use of dependencies manager is really encouraged, because they do so much more than simply including remote repositories (minimum / maximum versions requirements, dependencies downloading, incompatibilities...), it exists several other solutions to include git repositories inside a main git repository.

Each solution may be adequate depending on the way you want to include and work with the remote sources:

>> git submodule

With git submodule, the code and the history remain in each repository. The use of submodule can become cumbersome when branching and some developers shared their tips or their hate working with submodules.


A submodule allows you to keep another Git repository in a subdirectory of your repository. The other repository has its own history, which does not interfere with the history of the current repository. This can be used to have external dependencies such as third party libraries for example.

When cloning or pulling a repository containing submodules however, these will not be checked out by default; the init and update subcommands will maintain submodules checked out and at appropriate revision in your working tree.


>> git subtree

With git subtree, the code and the history are merged in the top-level git repository. Git subtree has a much more simpler approach to include remote git repositories and has other advantages over submodules. However, it becomes much complex to use if a lot of code changes should be done and send in the included repositories.


Subtrees allow subprojects to be included within a subdirectory
of the main project, optionally including the subproject's
entire history.

For example, you could include the source code for a library
as a subdirectory of your application.

Subtrees are not to be confused with submodules, which are meant for
the same task. Unlike submodules, subtrees do not need any special
constructions (like .gitmodule files or gitlinks) be present in
your repository, and do not force end-users of your
repository to do anything special or to understand how subtrees
work. A subtree is just a subdirectory that can be
committed to, branched, and merged along with your project in
any way you want.


>> git slave

Git slave can be useful if your workflow need to perform same git operations on multiple project related repositories.


Gitslave creates a group of related repositories—a superproject repository and a number of slave repositories—all of which are concurrently developed on and on which all git operations should normally operate; so when you branch, each repository in the project is branched in turn. Similarly when you commit, push, pull, merge, tag, checkout, status, log, etc; each git command will run on the superproject and all slave repositories in turn. This sort of activity may be very familiar to CVS and (to a lesser extent) Subversion users. Gitslave's design is for simplicity for normal git operations.


>> google repo

Repo is a tool written by Google on top of Git to help them manage the 17Gb of the Android source code in interaction with tehir continuous integration system. It can be useful when dealing with very large set of git repositories, it uses a manifest XML file to describe the repositories to get and where to put them in the project tree. Repo supports multithread git cloning, snapshots, shell operations on multiple repositories...


Repo is a tool that we (Google) built on top of Git. Repo helps us manage the many Git repositories, does the uploads to our revision control system, and automates parts of the Android development workflow. Repo is not meant to replace Git, only to make it easier to work with Git in the context of Android. The repo command is an executable Python script that you can put anywhere in your path.


>> gr

Gr is a far less know project and does not provide the ability to include git repositories inside another one. However, it helps so much when dealing with multiple git repositories by assigning tags to them and perform git operations on selected (or all) git repositories in one command. Really useful to get all updates of remotes, or be sure to have commit or push all our work.



Tag all the things! gr @work foo will run the command foo in all the paths tagged @work .
Auto-discovery of git repositories for easy setup and tag management.
gr does not reinvent any git operations: instead, it passes through and runs any unknown commands. All your git-fu will still work! e.g. gr @work git fetch is the same as running git fetch in each all the paths tagged @work .
Built-in commands for common pain points:
status for one-line summaries of repos (modified, behind/ahead, tags)
Extensible via plugins and middleware: REST API/Connect-style request handlers (function(req, res, next) { ... }

Vote Up Vote Down

@Cooney921

What you're describing is basically git submodules. However, submodules have their quirks, would likely be more trouble than they're worth for this use case.

For your Javascript dependencies you'd be better off using something like Bower. (There are some other options in the JS world too.) If you're doing server-side programming there are generally language-specific dependency management tools (e.g. Composer for PHP, Bundler for Rails and so on).

"Automatically get updates" is not always a good idea. These tools allow you to control which versions of your dependencies your project uses, as well as giving you an easy (one command) way of updating them.

Vote Up Vote Down