Subtree와 Submodule 비교

Welcome to the final lesson in our Git Subtree mini-course! We've explored what Git Subtree is and how to use it. Now, it's time to compare it with Git Submodules.

Both tools help manage external dependencies within a main repository, but they do so in fundamentally different ways. Understanding these differences is key to choosing the right strategy for your project.

Recall that Git Submodules allow you to embed one Git repository inside another as a subdirectory. The main repository stores a reference to a specific commit in the submodule's repository.

• Separate Histories: Each submodule maintains its own independent Git history.
• Pointers, Not Copies: The parent repository only stores a pointer to the submodule's commit, not its actual content.
• Decentralized Development: Ideal for when you need to contribute directly to the upstream dependency.

Submodules offer distinct advantages, especially in specific scenarios:

• Clear Separation: The dependency's history is completely isolated from the main project's history.
• Upstream Contributions: Easy to make changes to the submodule and push them directly to its original upstream repository.
• Version Pinning: You can pin a submodule to an exact commit, ensuring stability.
• Distributed Ownership: Useful when different teams manage different parts of a larger system.

Despite their benefits, submodules come with a set of complexities that can be tricky, especially for beginners:

• Cloning Complexity: Requires extra steps (git submodule init, git submodule update) after cloning.
• Detached HEAD: Often puts you in a 'detached HEAD' state when working inside a submodule, which can be confusing.
• History Management: Updating submodules means committing a new pointer in the parent, which can lead to frequent updates.
• Branching Issues: Switching branches in the parent repo might require manual submodule updates.

Git Subtree, on the other hand, works differently. It essentially copies the external repository's content into a subdirectory of your main project.

• Integrated History: The dependency's history is merged directly into your main repository's history.
• No Separate Repos: It's just a subdirectory, not a separate Git repository within yours.
• Simplified Workflow: Appears as a regular part of your project, making it easier for new contributors.

Subtree shines when simplicity and a single repository experience are priorities:

• Easier Cloning: No special commands needed; a simple git clone fetches everything.
• Single Repository: All code lives in one repo, simplifying CI/CD and permissions.
• No Detached HEAD: You're always on a branch within the main repository.
• Simpler for Consumers: Developers don't need to learn submodule-specific commands.
• Easier Refactoring: Moving files within the subtree is like moving any other file in your repo.

While simpler in some aspects, Git Subtree has its own set of drawbacks:

• History Clutter: The dependency's history is merged into your main project, potentially making your git log longer and harder to read.
• Complex Updates: Pulling updates from the upstream subtree requires specific git subtree pull commands, which can be less intuitive than a simple git pull.
• Pushing Changes Upstream: Pushing changes made within the subtree back to its original repository also requires a specific git subtree push command, which can be more involved.
• Duplication: The dependency's code is physically copied into your repo, increasing its size.

The most fundamental difference lies in how they manage history:

• Submodules: Maintain a clean separation. Your main repo only records a pointer to a specific commit in the submodule's independent history.
• Subtree: Integrates the dependency's history directly into your main project's history. It's as if you've copied and committed all those changes yourself.

This difference impacts everything from cloning to updating and collaborating on the dependency.

Consider the day-to-day workflow for developers:

• Submodules: More explicit. Developers must be aware they are dealing with a separate Git repository. Commands like git submodule update are essential.
• Subtree: More seamless. Once added, the subtree behaves like any other directory in the main repository. Basic Git commands (add, commit, pull, push) generally work without special considerations for the subtree itself.

Subtree generally offers a lower barrier to entry for team members who just need to use the dependency.

So, which one should you choose?

• Use Submodules when:
  - You need to contribute frequently to the dependency's upstream.
  - The dependency is a distinct, actively developed project.
  - You prefer strict version pinning and isolated histories.
  - Your team is comfortable with Git submodule workflows.
• Use Subtree when:
  - You want a simpler workflow for consumers of the dependency.
  - You rarely need to push changes back to the upstream dependency.
  - The dependency is internal or you just want to vendor code.
  - A single, unified repository history is preferred for simplicity.

Review what you've learned about Git Submodules and Subtree.

In this lesson, we dissected the core differences between Git Submodules and Git Subtree.

• Submodules maintain separate histories and require explicit commands, offering strong isolation and easy upstream contributions.
• Subtree integrates history, simplifies cloning, and provides a unified repository experience, but can make updates and upstream pushes more complex.

Your choice depends on your project's needs, team's comfort level, and the nature of your dependencies. Both are powerful tools when used in the right context!