Modularization Approaches: Submodules vs Subtrees
Sure, let's look at Git submodules and subtrees, along with their pros and cons, and then discuss some possible alternatives.
Git Submodules:
Git submodules allow you to keep a Git repository as a subdirectory of another Git repository. They are great for including external dependencies in your project that have their own separate Git repository.
Advantages of Git submodules:
- Separation of Projects: Each submodule maintains its own separate history, branches, and commits, making it easier to manage code that should remain separate from the main project.
- Control: You have explicit control over what commit a submodule points to, ensuring that your main project isn't broken by changes to a dependency.
Drawbacks of Git submodules:
- Complexity: Git submodules can be complex and hard to understand, particularly for beginners. This can introduce challenges in managing and maintaining the repository.
- Loose Integration: Because submodules are separate repositories, changes in the submodule aren't automatically included in the parent repo. You have to manually pull changes in the submodule and commit the new state in the main repo.
- Inconvenience: You can't include only certain directories or files from a submodule repository. It's all or nothing.
Git Subtrees:
Git subtrees are an alternative to Git submodules. They allow you to nest one repository inside another as a subdirectory, but they merge the content into the same project tree, keeping only one Git history.
Advantages of Git subtrees:
- Simplicity: They are easier to use and understand compared to Git submodules, and don't require users of your repository to learn anything new or clone submodules separately.
- Flexibility: Unlike submodules, you can select specific directories from a repository to be included as a subtree.
- Integrated History: The commits of the subtree are integrated into the parent repo's history, which can make tracking changes easier in some cases.
Drawbacks of Git subtrees:
- More Merged Histories: While the integrated history can be beneficial, it can also lead to a more convoluted commit history for the parent repository, especially if the subtree is frequently updated.
- Overhead: Frequent subtree merging can create a lot of overhead, making your history harder to understand and work with.
- Lack of Control: The parent repository doesn't have control over the exact commit of the subtree. The subtree is always pointing to the latest commit of the included repository.
Other Options:
There are a few other options you might consider for your project:
Unity Package Manager (UPM) Local Path: Unity supports referencing a package by a local path. This allows you to edit package code on the fly, without the need to publish changes to see their effect in the project that uses them. It is simple and easy, but can create problems if multiple projects need to share the same packages, and these packages are under active development.
Monorepo: A monorepo is a software development strategy where code for many projects is stored in the same repository. With a monorepo, you can manage all your Unity packages in one place, reducing the complexity and improving the efficiency of your workflow. It makes it easy to apply wide-reaching changes across all projects, and simplifies dependency management. However, it can become difficult to manage as the size of the codebase increases, and it might not work well with some tools which are designed with smaller repositories in mind.
Distributed Unity Packages: You can have separate repositories for each Unity package and distribute them via UPM or Asset Store. This allows better separation of concerns and independent versioning. However, it can be cumbersome if you need to frequently modify and test these packages in the context of your project.
Ultimately, the best solution will depend on your specific needs, including how tightly coupled the packages are to your main project, the complexity of your project, your team's familiarity with Git, and your testing requirements.
As of my training data up to September 2021, there is no specific documentation or case studies that I can recall about using Git submodules or subtrees to manage custom package dependencies specifically in Unity.
However, the use of Git submodules and subtrees is a common practice in software development, and Unity developers often face similar problems as developers in other environments. Therefore, the advantages and drawbacks of these techniques generally apply to Unity projects as well.
In the Unity context, the ability to use local paths for package dependencies (through the Unity Package Manager) has often been recommended for ease of use and iteration speed, especially when those packages are under active development. However, this approach lacks the robust version control and separate history benefits that Git submodules and subtrees can provide.
If the packages are more stable or used across multiple Unity projects, some developers choose to use separate Git repositories for each package and distribute them via the Unity Package Manager or Unity Asset Store. This allows better control over versioning and distribution but can be cumbersome if there are frequent updates or dependencies between packages.
If you are looking for more specific experiences or case studies, Unity forums, developer blogs, and GitHub discussions can often provide valuable real-world insights. Remember to consider your project's specific needs and the team's familiarity with these tools when deciding on a management strategy for your package dependencies.