Git – Subtree

Git subtree is the most common replacement for Git submodule. A Git subtree is a replica of a Git repository that has been dragged into the main repository. A Git submodule is a reference to a particular commit in a different repository. Git subtrees, which were first introduced in Git 1.7.11, help you make a copy of any repo into a subdirectory of another. 

Advantages of Subtrees

1. Supported by Git’s previous version. It supports versions older than 1.5 as well.
2. Workflow management is simple.
3. After the super-project is completed, there will be an available sub-project code.
4. You don’t need newer Git knowledge.
5. Content modification without the need for a different repo of the dependence.

Disadvantages of Subtrees

1. It’s not immediately obvious that a subtree is used to build the main repo.
2. Your project’s subtrees are difficult to list.
3. You can’t, at least not simply, list the subtrees’ remote repositories.
4. When you change the main repository with subtree commits, then submit the subtree to its main server, and then pull the subtree, the logs can be a little misleading.

It is one of the various methods for injecting and managing project dependencies in Git projects. External dependencies are stored in regular commits. Subtrees in Git give clean integration points, making reverting easy. You won’t see a subtree when you use the GitHub subtrees tutorial to create a .gittrees configuration file in your local directory. Subtrees appear to be general folders, but they are actually copies of the child repositories, making it impossible to distinguish them. git subtree allows you to nest a repository as a subdirectory inside another. It’s one of the various options for managing project dependencies in Git projects. You add a subtree to an existing repository where the subtree is a reference to another repository URL and branch/tag when you wish to utilize it. It’s not simply a reference to a remote repo; this add command adds all the code and files to the main repository locally. 

When you stage and commit files for the primary repository, it will also add all of the remote files. There’s no need to link to another repo to receive the subtree component because the subtree checkout will get all the files in one go. After using git submodules for a while, you’ll notice that git subtree fixes a lot of the issues that the git submodule causes. As with anything related to Git, there is a learning curve to get the most out of the capability. 

Assume you wish to use a single project inside a repository as a child project. Copying the project to the main repo is the standard procedure. To reuse a child project across many parent repositories, it wouldn’t be practical to clone the kid project into each parent and make modifications in each one every time it was updated. This would result in redundancy and inconsistency in the parent repositories, making updating and maintaining the child project difficult. 

Because of the version of Git subtree with the. gittrees config file is not included in the usual Git package, you must download git-subtree from the Git source repository’s /contrib/subtree subdirectory.

You can replicate any repo with subtrees just like any other general repository, however, it will take longer because the parent repository has complete copies of the child repository. To use Git subtrees in your repositories, run the commands below.

Adding a subtree to a parent repository

To bring a new subtree to a parent repository, you first remotely add it, then use the subtree add command, which looks like this:

$ git remote add remote-name <URL to Git repo>
$ git subtree add --prefix=folder/ remote-name <URL to Git repo> subtree-branchname

The commit log of the entire child project gets merged into the main repository.

Pushing and pulling changes to and from the subtree

$ git subtree push-all

or the below command performs the same as follows: 

$ git subtree pull-all

Git submodules have a lesser repository size than Git subtrees since they are only pointers to a specific commit in the child project, whereas Git subtrees hold the complete child project and its history. Submodules in Git must be accessible from a server, while subtrees are not. Component-based development makes use of Git submodules, whereas system-based development makes use of Git subtrees.

A Git subtree is not the same thing as a Git submodule. There are several limitations on where each can be used. If you own an external repository to which you will likely push code, use Git submodule because it is easier to push. Use Git subtree if there is a third-party code that you are doubtful to push to because it is easier to pull. You can add another repository into this repository like this:

• Specify you want to add a subtree.
• Indicate that you want to add a subtree.
• Specify the prefix local directory where you wish the subtree to be pulled.
• Specify the URL of the remote repository [for the subtree being dragged in].
• The remote branch [of the subtree being pulled in] must be specified.
• Specify that you wish to squash all [the subtree’s] logs from the remote repository.

git subtree add –prefix {local directory being pulled into} {remote repo URL} {remote branch} –squash

Example: Peek out 

git subtree add –prefix subtreeDirectory https://github.com/microsoft/hermes-windows master –squash

This will duplicate https://github.com/microsoft/hermes-windows into the directory subtreeDirectory.

Replace add with pull: if we wish to pull in every new contribution to the subtree from the main.

git subtree pull —prefix subtreeDirectory https://github.com/microsoft/hermes-windows master —squash