SVN迁移Git拆分仓库时，多独立项目共享DLL的处理方案咨询

Hey there! Let's break down the most practical ways to handle sharing that ABC.cs and its corresponding DLL across your newly split Git repositories. I've worked through similar repo split scenarios before, so here are the approaches that tend to work best:

1. 独立共享库仓库 + Git子模块/子树 #

This is the most straightforward approach for keeping shared code in sync while maintaining repo independence:

• First, extract the ABC.cs and its entire project into a standalone Git repository (let's call it ABC.Shared). This way, all changes to the shared logic are centralized here.
• For your two business repos (ExternalCustomerCommunications and InternalUser UI), use either Git Submodules or Git Subtree to include the shared repo:
  • Git Submodules: Great if you want each business repo to lock to a specific version of ABC.Shared. Add it with:

    git submodule add <ABC-Shared-repo-url> ./Shared/ABC
    

    To pull updates from the shared repo later, run:

    git submodule update --remote
    

  • Git Subtree: Ideal if you prefer having the shared code directly merged into your business repo (no separate .gitmodules file to manage). Add it with:

    git subtree add --prefix=Shared/ABC <ABC-Shared-repo-url> main
    

• Pros: Centralized version control for shared code; changes to ABC.Shared can be pulled into dependent repos easily; keeps business repos clean and focused on their core logic.
• Cons: Submodules have a bit of a learning curve for teams new to them; subtree updates require a few extra commands compared to regular repo pulls.

2. 私有包管理（NuGet/对应语言包） #

If you want full decoupling between your repos, packaging the shared component is a rock-solid long-term solution:

• Package the ABC project into a private package (NuGet for .NET, for example) and host it on an internal package repository (like a self-hosted NuGet server, Azure Artifacts, or a private registry).
• Update your two business projects to reference this package via your package manager (just like you would with any third-party library).
• Pros: Complete decoupling—each business repo can choose its own version of the ABC package; no Git-specific overhead; scales well for larger teams with formal release processes.
• Cons: Requires setting up and maintaining a private package source; every change to ABC requires a new package version to be built and published, adding a small extra step to your workflow.

3. 本地文件引用（临时过渡方案） #

Only use this if you need a quick fix while you set up a more permanent solution:

• Keep a copy of the ABC.dll in each business repo, or reference a shared local directory via relative paths.
• Big caveat: This is risky long-term—you’ll almost certainly run into version mismatch issues (e.g., one repo uses an outdated ABC.dll while another uses the latest, leading to hard-to-debug bugs).
• Pros: Zero setup time, works for immediate needs.
• Cons: No version control for the shared component; guarantees consistency issues down the line.

Quick Recommendation #

• If your team is comfortable with Git’s advanced features, go with the independent shared repo + submodules/subtree—it’s the most transparent way to manage shared code.
• If you already have an internal package management system in place, the private package route is the most scalable and clean solution.
• Avoid the local file reference approach unless it’s strictly a short-term band-aid.

内容的提问来源于stack exchange，提问作者jvoigt