Lets say that I want the create a new website and use git to track my revisions. Now I want to include several helpful things in my site that come from other people's git repos like:

html5-boilerplate jquery colorbox

Each has its own repo, which I place in various folders on my site. How can I create/update my repo so that it includes these other repos? ...with each repo's scr or code folder located in the correct place in my repository. Example: the html5 boilerplate '/src' folder should be root directory for my website.

Is there a way to automatically get updates? If I make changes to one of the files in the other repo's, how do I keep changes straight??

Can I have one "html5 boilerplate"/"jquery" repo clone on my Debian server and use symbolic links to place it where needed? how?

  • 1
    I'm voting to close this question as off-topic because this is a programming tool issue and not related to webmastering as defined in the Help Center.
    – Rob
    Dec 31 '18 at 13:53
  • I think this question should be re-opened here. Nevertheless, if anyone wants to add anything, here are related questions on Stack Overflow where you can post your answer instead: 1 (best): stackoverflow.com/questions/47008290/…; 2: stackoverflow.com/questions/33406739/…; 3: stackoverflow.com/questions/9674576/… Jun 14 '20 at 4:30
  • Note: if your goal is just to archive a bunch of git repos inside a bigger parent repo or something the simplest brute-force solution is to just rename all nested .git folders to anything else--ex: to ..git. Now, git add -A will add them all just like any other normal folder inside the parent git project. Done. Jun 14 '20 at 4:41

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) { ... }
  • A somewhat good answer, just a shame your markdown is wrong and your missing relevant links. Aug 31 '15 at 10:44
  • 1
    Thanks to upvote my answer, I didn't have enough reputation to provide more thant 2 links. I juste edited the answer and provided the missing links.
    – mperrin
    Aug 31 '15 at 11:09
  • 1
    Yet another alternative is git-subrepo that attempts to address some of the shortcomings of the others. [Added as a comment since this otherwise comprehensive answer has been closed as off-topic]
    – jwd630
    Feb 10 '19 at 17:40

What you're describing is basically git submodules. However, submodules have their quirks, and 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.

  • 1
    I have to agree with Tim's comment on automatically getting updates not always being a good idea. I have seen environments where this has been done manually and repo's (such as jquery, html5boilerplate, etc) where monitored for changes and when a change occured the code was automatically pulled and updated to the main project repo. The issue arose however that changes in the dependencies resulted in code breaking and no record of why the code was breaking as the entire dependency had been imported as one module. Better to use dependency manager as you can enforce the version you know works. Oct 5 '16 at 1:54
  • I'm curious what some of these "quirks" are. Can you give an example of one such issue that comes up ? Dec 30 '18 at 20:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.