How Managing Multiple Git Repositories?
Managing a Git repository within another repository can be approached in several ways, depending on your specific needs and workflow. Here are some common methods

Git Submodules
This is a common approach for including and managing a repository within another repository. A submodule is essentially a link to a specific commit in another repository. It allows you to keep a separate history for the two repositories but manage them together when necessary. You can add a submodule using git submodule add <repository-url> and update it with git submodule update --remote.
As example let’s go through the steps to add the data-investor-books repository as a submodule to your main project repository,
Step 1: Cloning Your Main Project Repository
If you haven’t already cloned your main project repository to your local machine, do so with the following command:
git clone <repo-url>
cd <repo>This will clone the repository and change your current directory to the cloned repository.
Step 2: Adding the Submodule
To add the data-investor-books repository as a submodule, use the git submodule add command:
git submodule add [email protected]:mazzasaverio/data-investor-books.git path/to/submodule
Replace path/to/submodule with the relative path within your main repository where you want the submodule to reside. This command will:
- Clone the
data-investor-booksrepository to the specified path. - Add a new file,
.gitmodules, to your project, which will track information about the submodule. - Add the new submodule and the
.gitmodulesfile to the staging area.
Step 3: Committing the Changes
After adding the submodule, you’ll need to commit these changes to your repository:
git commit -m "Added data-investor-books submodule"This commits the addition of the submodule to your project’s history.
Step 4: Pushing the Changes
Finally, push the changes to your remote repository:
git push origin masterAssuming you are working on the master branch, this will update your remote repository with the submodule.
Step 5: Cloning the Main Repository with Submodules
If someone needs to clone your main repository (which now includes a submodule), they should use the following commands:
git clone --recurse-submodules <your-repo-url>The --recurse-submodules option ensures that the submodule content is automatically fetched and updated when cloning the main repository.
Step 6: Working with the Submodule
To work within the submodule, just navigate to the submodule directory and work as you would in any Git repository:
cd path/to/submodule
# make changes, git commit, git push, etc.Remember, if you make changes within the submodule, you will need to commit these changes within the submodule directory and then go back to your main project directory to commit the changes there as well.
Step 7: Updating the Submodule
If the external data-investor-books repository has updates, you can pull these changes into your submodule with:
git submodule update --remoteThis updates the submodule to the latest commit available in the remote repository.
Important Notes
- Handling Changes: When you make changes within a submodule, those changes are specific to your main project repository and won’t affect anyone else unless you push those changes back to the submodule’s remote repository and update the reference in the main project.
- Submodule Independence: The submodule is a separate Git repository, so remember to commit and push changes within the submodule directory independently of the main project repository.
By following these steps, you’ll effectively integrate the data-investor-books repository as a submodule into your project.
Git Subtree
This is an alternative to submodules that can be simpler to use. Git subtree allows you to insert any repository as a sub-directory of another repository, essentially merging two repositories. Unlike submodules, subtrees do not require any special configuration for other users who clone the repository. The subtree’s contents are directly added to the main repository, making it easier to manage as one entity.
Workflow
- Adding a Subtree: Use
git subtree add --prefix <path> <repo-url> <branch>to add the repository as a subtree. This command adds the contents of the external repository into the specified path in your project. - Pulling Changes: You can update the subtree with changes from the external repository using
git subtree pull --prefix <path> <repo-url> <branch>. - Pushing Changes: If you have commit rights to the external repository, you can push changes made in your subtree back to the external repository with
git subtree push --prefix <path> <repo-url> <branch>.
Pros and Cons
- Pros: Simpler than submodules for both maintainers and contributors. Changes to the subtree are versioned along with the main project.
- Cons: The subtree’s history becomes part of your project’s history, which can make your repository larger and potentially more cluttered.
Nested Repositories (Not Recommended)
Technically, you can have a Git repository inside another without using submodules or subtrees. However, this is generally not recommended because the parent repository will not track the state of the nested repository. It’s more like having two separate repositories that just happen to be in the same directory structure. This can lead to confusion and difficulty in tracking changes across repositories.
Repository Links (Symbolic Links)
Another method is to use symbolic links in your main repository that point to directories in another repository. This is a more manual approach and has its own set of complications, particularly with different operating systems and when cloning the repository on new machines.
Each of these methods has its own pros and cons:
- Submodules are powerful but can be complex to manage, especially in teams.
- Subtrees are simpler and better for situations where you always want the entire content of the other repository.
- Nested repositories provide more independence between the repositories but lack integrated tracking.
- Symbolic links offer a simple but less robust solution.
The best choice depends on your specific requirements, such as the level of independence you want between the repositories, how often you need to synchronize them, and the complexity you’re willing to manage.
