The git-subrepo command "clones" an external git repo into a subdirectory of your repo. Later on, upstream changes can be pulled in, and local changes can be pushed back - github 
* Tutorial - github
# Benefits
This command is an improvement from git-submodule and git-subtree; two other git commands with similar goals, but various problems.
It assumes there are 3 main roles of people interacting with a repo, and attempts to serve them all well: * owner - The person who authors/owns/maintains a repo. * users - People who are just using/installing the repo. * collaborators - People who commit code to the repo and subrepos.
The git-subrepo command benefits these roles in the following ways: * Simple and intuitive commandline usage. * Users get your repo and all your subrepos just by cloning your repo. * Users do not need to install git-subrepo, ever. * Collaborators do not need to install unless they want to push/pull. * Collaborators know when a subdir is a subrepo (it has a .gitrepo file). * Well named branches and remotes are generated for manual operations. * Owners do not deal with the complications of keeping submodules in sync. * Subrepo repositories can contain subrepos themselves. * Branching with subrepos JustWorks™. * Different branches can have different subrepos in different states, etc. * Moving/renaming/deleting a subrepo subdir JustWorks™. * You can init an existing subdirectory into a subrepo. * Your git history is kept squeaky clean. * Upstream history (clone/pull) is condensed into a single commit. * You can see the subrepo history with git log subrepo/<subdir>/fetch. * Commits pushed back upstream are not condensed. * Trivial to try any subrepo operations and then reset back. * No configuration required. * Does not introduce history that messes up other git commands. * Fixes known rebase failures with git-subtree.